Race on delete between OS::Neutron::Subnet and OS::Nova::Server->networks->uuid

Bug #1243992 reported by Steve Baker
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Heat
Fix Released
High
Steve Baker

Bug Description

When OS::Nova::Server specifies a networks uuid, an implicit dependency is created with the subnet of that network.

A similar fix is required as for OS::Neutron::Port add_dependencies

Changed in heat:
assignee: nobody → Steve Baker (steve-stevebaker)
importance: Undecided → High
milestone: none → icehouse-1
status: New → Triaged
tags: added: havana-backport-potential
Changed in heat:
milestone: icehouse-1 → icehouse-2
Changed in heat:
milestone: icehouse-2 → icehouse-3
Thierry Carrez (ttx)
Changed in heat:
milestone: icehouse-3 → icehouse-rc1
Changed in heat:
assignee: Steve Baker (steve-stevebaker) → nobody
Changed in heat:
assignee: nobody → Steve Baker (steve-stevebaker)
Revision history for this message
Zane Bitter (zaneb) wrote :

Why aren't Server and Port referencing a Subnet as opposed to a Network anyway? Don't you want to control which Subnet your server ends up in? Why would you create different Subnets with Routers between them and then assign machines to them at random? Am I completely misunderstanding what a "Network" and a "Subnet" are in Neutron terms?

Revision history for this message
Steve Baker (steve-stevebaker) wrote :

As a datapoint, I just created a server which referenced a network that happened to have two subnets. The server ended up with a port on one of the subnets, the selection criteria was not obvious.

My guess is that being able to specify a network on nova-create is a nova-networking thing, and this interface was mapped to a neutron network for nova-network/neutron compatibility reasons, which seems entirely reasonable.

If you launch a server with a port resource then you can specify the subnet.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to heat (master)

Fix proposed to branch: master
Review: https://review.openstack.org/81976

Changed in heat:
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Fix proposed to branch: master
Review: https://review.openstack.org/82394

Revision history for this message
Zane Bitter (zaneb) wrote :

Is there any way we can force users to do it the correct way (i.e. specify a Subnet)? At least when we know they're using Neutron instead of Nova-network?

Revision history for this message
Steve Baker (steve-stevebaker) wrote :

We can document that we strongly recommend they use the port property if they have neutron.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to heat (master)

Reviewed: https://review.openstack.org/82394
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=9d6055922544b9349ec32c5226ff4685a6705eae
Submitter: Jenkins
Branch: master

commit 9d6055922544b9349ec32c5226ff4685a6705eae
Author: Steve Baker <email address hidden>
Date: Mon Mar 24 11:46:26 2014 +1300

    OS::Nova::Server depend on subnets related to nets

    Nova supports creating network interfaces by network ID however
    if the network and the subnet are part of the same stack as this
    server then a race occurs between the creation of the subnet and
    the creation of the server. Likewise for delete the subnet cannot
    be deleted until all ports are removed from it.

    This change adds the same add_dependencies workaround to
    OS::Nova::Server that OS::Neutron::Port and OS::Neutron::RouterGateway
    have.

    The confirmation that this change fixes the race will be confirmed
    by tempest test NeutronResourcesTestJSON once
    https://review.openstack.org/#/c/82393/ lands.

    Change-Id: I626b976446cda709d96823c9de331eafc29d3c68
    Closes-Bug: #1243992

Changed in heat:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in heat:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in heat:
milestone: icehouse-rc1 → 2014.1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.