yahoo-eng-team team mailing list archive

[Eric Fried <efried@xxxxxxxxxx>]

Public bug reported:

NB: This comes from code inspection, not observed behavior.

When the compute service is deleted, we attempt to delete from placement
the resource provider associated with the compute node associated with
the service [1].

But ironic deployments can have multiple compute nodes. In this case,
the compute node associated with the service is the "first" such node
[2].

What happens then is the compute node records are deleted, leaving the
remaining N-1 nodes' provider records orphaned. Those get cleaned up (I
think?) by update_available_resource when the service is recreated [3].

So we're deleting and recreating the ironic node resource providers, but
in a weird order. We should probably either fix the code at [1] to
delete all of them, or none of them (and let the orphan handling code do
all the work).

[1] https://github.com/openstack/nova/blob/da98f4ba4554139b3901103aa0d26876b11e1d9a/nova/api/openstack/compute/services.py#L244-L247
[2] https://github.com/openstack/nova/blob/da98f4ba4554139b3901103aa0d26876b11e1d9a/nova/objects/service.py#L308-L311
[3] https://github.com/openstack/nova/blob/da98f4ba4554139b3901103aa0d26876b11e1d9a/nova/compute/manager.py#L7757-L7771

** Affects: nova
     Importance: Undecided
         Status: New


** Tags: api compute ironic placement

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1811726

Title:
  Deleting compute service only deletes "first" ironic node from
  placement

Status in OpenStack Compute (nova):
  New

Bug description:
  NB: This comes from code inspection, not observed behavior.

  When the compute service is deleted, we attempt to delete from
  placement the resource provider associated with the compute node
  associated with the service [1].

  But ironic deployments can have multiple compute nodes. In this case,
  the compute node associated with the service is the "first" such node
  [2].

  What happens then is the compute node records are deleted, leaving the
  remaining N-1 nodes' provider records orphaned. Those get cleaned up
  (I think?) by update_available_resource when the service is recreated
  [3].

  So we're deleting and recreating the ironic node resource providers,
  but in a weird order. We should probably either fix the code at [1] to
  delete all of them, or none of them (and let the orphan handling code
  do all the work).

  [1] https://github.com/openstack/nova/blob/da98f4ba4554139b3901103aa0d26876b11e1d9a/nova/api/openstack/compute/services.py#L244-L247
  [2] https://github.com/openstack/nova/blob/da98f4ba4554139b3901103aa0d26876b11e1d9a/nova/objects/service.py#L308-L311
  [3] https://github.com/openstack/nova/blob/da98f4ba4554139b3901103aa0d26876b11e1d9a/nova/compute/manager.py#L7757-L7771

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1811726/+subscriptions