device tagging support is not checked during move operations

Bug #1817927 reported by Matt Riedemann
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)

Bug Description

When creating a server with bdm or port tags, the compute service (which the scheduler picked) checks to see if the underlying virt driver supports device tags and if not, the build is aborted (not rescheduled to an alternate host):

However, that same type of check is not performed for any other move operation, like cold/live migration, evacuate or unshelve.

So for example, I could have two compute hosts A and B where A supports device tagging but B does not. I create a server with device tags on host A and then shelve offload the server. In the meantime, host A is unavailable (either it's at capacity or down for maintenance) when I unshelve my instance and it goes to host B which does not support device tags. Now my guest will be unable to get device tag metadata via config drive or the metadata API because the virt driver is not providing that information, but the unshelve operation did not fail.

This was always a gap in the initial device tag support anyway since there is no filtering in the scheduler to pick a host that supports device tagging, nor is there any policy rule in the API for disallowing device tagging if the cloud does not support it, e.g. if the cloud is only running with the vcenter or ironic drivers.

The solution probably relies on adding a placement request filter that builds on this change:

Which exposes compute driver capabilities as traits to placement so then we could pass the required traits via the RequestSpec to a placement request filter which would add those required traits to the GET /allocation_candidates call made in the scheduler. In the case of device tags, we'd require a compute node with the "COMPUTE_DEVICE_TAGGING" trait.

Tags: scheduler
Changed in nova:
status: New → Confirmed
importance: Undecided → Low
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.