yahoo-eng-team team mailing list archive

[Matt Riedemann <mriedem.os@xxxxxxxxx>]

FYI, this applies all the way back to Ocata:

https://review.openstack.org/#/q/I7b8622b178d5043ed1556d7bdceaf60f47e5ac80

** Also affects: nova/ocata
   Importance: Undecided
       Status: New

** Also affects: nova/queens
   Importance: Undecided
       Status: New

** Also affects: nova/rocky
   Importance: Undecided
       Status: New

** Also affects: nova/pike
   Importance: Undecided
       Status: New

** Changed in: nova/ocata
       Status: New => Confirmed

** Changed in: nova/queens
       Status: New => Confirmed

** Changed in: nova/pike
       Status: New => Confirmed

** Changed in: nova/rocky
       Status: New => Confirmed

** Summary changed:

- Deleting compute service only deletes "first" ironic node from placement
+ Deleting compute service only deletes "first" ironic node resource provider from placement

** Changed in: nova
   Importance: Medium => Low

** Changed in: nova/pike
   Importance: Undecided => Low

** Changed in: nova/rocky
   Importance: Undecided => Low

** Changed in: nova/ocata
   Importance: Undecided => Low

-- 
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 resource
  provider from placement

Status in OpenStack Compute (nova):
  Triaged
Status in OpenStack Compute (nova) ocata series:
  Confirmed
Status in OpenStack Compute (nova) pike series:
  Confirmed
Status in OpenStack Compute (nova) queens series:
  Confirmed
Status in OpenStack Compute (nova) rocky series:
  Confirmed

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