Public bug reported: Currently when deleting a nova-compute service via the API, we will delete the service and compute_node records in the DB, but the placement resource provider and host mapping records will be orphaned.
The orphaned resource provider records have been found to cause scheduler failures if you re-create the compute node with the same name (but a different UUID). It has been theorized that the stale host mapping records could end up pointing at the wrong cell. In discussions on IRC (http://eavesdrop.openstack.org/irclogs /%23openstack-nova/%23openstack- nova.2018-03-15.log.html#t2018-03-15T19:30:13) it was proposed that we should 1. delete the RP in placement 2. delete the host mapping 3. delete the service/node Optionally we could delete the compute node prior to deleting the service to make it explicit and because the ordering is slightly more logical, but this is not a requirement since it will be done implicitly as part of deleting the service. ** Affects: nova Importance: Medium Status: Triaged ** Affects: nova/pike Importance: Undecided Status: New ** Affects: nova/queens Importance: Undecided Status: New ** Tags: api cells placement ** Summary changed: - deleting a nova-compute service leaves orphaned records in placement + deleting a nova-compute service leaves orphaned records in placement and host mapping -- 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/1756179 Title: deleting a nova-compute service leaves orphaned records in placement and host mapping Status in OpenStack Compute (nova): Triaged Status in OpenStack Compute (nova) pike series: New Status in OpenStack Compute (nova) queens series: New Bug description: Currently when deleting a nova-compute service via the API, we will delete the service and compute_node records in the DB, but the placement resource provider and host mapping records will be orphaned. The orphaned resource provider records have been found to cause scheduler failures if you re-create the compute node with the same name (but a different UUID). It has been theorized that the stale host mapping records could end up pointing at the wrong cell. In discussions on IRC (http://eavesdrop.openstack.org/irclogs /%23openstack-nova/%23openstack- nova.2018-03-15.log.html#t2018-03-15T19:30:13) it was proposed that we should 1. delete the RP in placement 2. delete the host mapping 3. delete the service/node Optionally we could delete the compute node prior to deleting the service to make it explicit and because the ordering is slightly more logical, but this is not a requirement since it will be done implicitly as part of deleting the service. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1756179/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
