Following the discussion on IRC, here's what I think you need to do:
- Assuming the set of traits from your new image is called image_traits...
- Use GET /allocations/{instance_uuid} and pull out the set of all RP
UUIDs. Let's call this instance_rp_uuids.
- Use the SchedulerReportClient.get_provider_tree_and_ensure_root method
[1] to populate and return the ProviderTree for the host. (If we're
uncomfortable about the `ensure_root` bit, we can factor that away.)
Call this ptree.
- Collect all the traits in the RPs you've got allocated to your instance:
traits_in_instance_rps = set()
for rp_uuid in instance_rp_uuids:
traits_in_instance_rps.update(ptree.data(rp_uuid).traits)
- See if any of your image traits are *not* in those RPs.
missing_traits = image_traits - traits_in_instance_rps
- If there were any, it's a no go.
if missing_traits:
FAIL(_("The following traits were in the image but not in the
instance's RPs: %s") % ', '.join(missing_traits))
[1]
https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L986
On 04/23/2018 03:47 PM, Matt Riedemann wrote:
> On 4/23/2018 3:26 PM, Eric Fried wrote:
>> No, the question you're really asking in this case is, "Do the resource
>> providers in this tree contain (or not contain) these traits?" Which to
>> me, translates directly to:
>>
>> GET /resource_providers?in_tree=$rp_uuid&required={$TRAIT|!$TRAIT, ...}
>>
>> ...which we already support. The answer is a list of providers. Compare
>> that to the providers from which resources are already allocated, and
>> Bob's your uncle.
>
> OK and that will include filtering the required traits on nested
> providers in that tree rather than just against the root provider? If
> so, then yeah that sounds like an improvement on option 2 or 3 in my
> original email and resolves the issue without having to call (or change)
> "GET /allocation_candidates". I still think it should happen from within
> ImagePropertiesFilter, but that's an implementation detail.
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
