Ask Your Question

# Revision history [back]

### race condition assigning port IP for DHCP in Heat

It seems https://wiki.openstack.org/wiki/Neutron/enable-to-set-dhcp-port-attributes might anticipate this problem.

I have a problem, I have a heat template that creates a set of instances using a ResourceGroup, the number being set by a parameter.

When the # created is high (e.g. > 10), it seems there is a race condition that is sometimes hit. When this hits, one of the instances is allocated the IP of the DHCP server, and this fails (and all others fail).

e.g.

  ctrl_net:
properties:
name:
str_replace:
params:
$stack_name: {get_param: 'OS::stack_name'} template:$stack_name-ctrl-net
type: OS::Neutron::Net
ctrl_subnet:
properties:
allocation_pools:
- {end: 172.16.0.254, start: 172.16.0.20}
cidr: 172.16.0/24
enable_dhcp: true
name:
str_replace:
params:
$stack_name: {get_param: 'OS::stack_name'} template:$stack_name-ctrl-subnet
network_id: {get_resource: ctrl_net}
type: OS::Neutron::Subnet


server_group: properties: count: {get_param: server_num} resource_def: properties: config_drive: 'true' flavor: m1.small image: {get_param: server_image} key_name: {get_param: server_key} name: str_replace: params: $stack_name: {get_param: 'OS::stack_name'} template:$stack_name-srv-%index% networks: - network: {get_resource: ctrl_net}

So what happens is that, in the failure case, instance-1 gets 172.16.0.20, DHCP gets 172.16.0.21, and the next instance wants 172.16.0.21 but fails.

This seems also related to https://bugs.launchpad.net/neutron/+bug/1219795

Does anybody else see this? Is there any work-around? I cannot manually override the DHCP port IP address (so e.g. i would like to make it 172.16.0.19 in the above so its not in the allocation range).

### race condition assigning port IP for DHCP in Heat

It seems https://wiki.openstack.org/wiki/Neutron/enable-to-set-dhcp-port-attributes might anticipate this problem.

I have a problem, I have a heat template that creates a set of instances using a ResourceGroup, the number being set by a parameter.

When the # created is high (e.g. > 10), it seems there is a race condition that is sometimes hit. When this hits, one of the instances is allocated the IP of the DHCP server, and this fails (and all others fail).

e.g.

  ctrl_net:
properties:
name:
str_replace:
params:
$stack_name: {get_param: 'OS::stack_name'} template:$stack_name-ctrl-net
type: OS::Neutron::Net
ctrl_subnet:
properties:
allocation_pools:
- {end: 172.16.0.254, start: 172.16.0.20}
cidr: 172.16.0/24
enable_dhcp: true
name:
str_replace:
params:
$stack_name: {get_param: 'OS::stack_name'} template:$stack_name-ctrl-subnet
network_id: {get_resource: ctrl_net}
type: OS::Neutron::Subnet


server_group: properties: count: {get_param: server_num} resource_def: properties: config_drive: 'true' flavor: m1.small image: {get_param: server_image} key_name: {get_param: server_key} name: str_replace: params: $stack_name: {get_param: 'OS::stack_name'} template:$stack_name-srv-%index% networks: - network: {get_resource: ctrl_net}

ctrl_net}

So what happens is that, in the failure case, instance-1 gets 172.16.0.20, DHCP gets 172.16.0.21, and the next instance wants 172.16.0.21 but fails.

This seems also related to https://bugs.launchpad.net/neutron/+bug/1219795

Does anybody else see this? Is there any work-around? I cannot manually override the DHCP port IP address (so e.g. i would like to make it 172.16.0.19 in the above so its not in the allocation range).