Filter nodes by owner

This is from the Massachusetts Open Cloud project:

https://github.com/CCI-MOC/esi/blob/master/docs/upstream-features.md#nova-baremetal-filters-that-are-aware-of-ironic-multi-tenancy

Nova interacts with Ironic as a user with administrative privileges, which means it is able to provision any available baremetal node. Nova needs to be aware of Ironic's multi-tenant features so that it only attempt to use baremetal nodes that belong to the tenant initiating the provisioning request with Nova.

Ironic nodes have an optional "owner" field which can be a project ID. This blueprint would use that owner field to filter nodes based on owner.

There are a couple of ways to do this in nova:

1. (Traditional scheduler filter) The nova-compute service would report the owner value on the ComputeNode object which would then be used by a new scheduler filter that filters the node based on owner using the RequestSpec.project_id field. The upside of this is it could be relatively simple to implement or potentially already possible with something like the ComputeCapabilitiesFilter or JsonFilter. The downside is it could perform poorly in a large deployment.

2. (Placement pre-filter) The nova-compute service and the Ironic driver's update_provider_tree method could be used to report a custom trait named like CUSTOM_OWNER_<node.owner> if the node.owner field has a value. A configurable placement pre-filter would be added which if enabled would translate the RequestSpec.project_id to a required trait that matches the node owner and then that would be used to filter the allocation candidates nova gets back from placement.

Option 2 is likely ideal from a performance and simplicity perspective though there might be some push-back on the concept of using custom traits this way (more like metadata than qualitative information about a node).

[mriedem 20191204] The functional test added here https://review.opendev.org/#/c/697187/2/nova/tests/functional/test_scheduler.py shows that option 2 with using provider traits is not feasible since it causes the scheduler to incorrectly filter out nodes that it shouldn't and we don't have enough context in the request filter to prevent that. So we likely need to go with option 1 and use a traditional filter.

Known issues:

a) If the node.owner is changed in ironic there would be a delay on when nova can properly filter on the trait since the trait will not be updated until the next update_available_resource periodic.

b) There would need to be discussion about whether or not the owner of a node can be changed while it's provisioned to a nova VM instance - likely that should be blocked otherwise nova could be running an instance with a node that the original owner no longer actually owns. http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011385.html

c) If the server create request is coming from an admin it should be able to use any node even if the node owner and requesting project ID do not match. There is nothing today in the RequestSpec object that says if the request is coming from an admin so something would have to be worked out there - perhaps with a new field or hacking in a scheduler hint under the covers via the RequestSpec.

d) What happens if the node has no owner and thus does not report the trait? In that case the pre-filter would filter out those nodes, but maybe that is the desired behavior.