Open Stack

On 01/04/2018 01:38 PM, Eric Fried wrote:
> Matt, et al-
> 
>> * Nested resource providers: I'm going to need someone closer to this
>> work like Jay or Eric to provide an update on where things are at in the
>> series of changes and what absolutely needs to get done. I have
>> personally found it hard to track what the main focus items are for the
>> nested resource providers / traits / granular resource provider request
>> changes so I need someone to summarize and lay out the review goals for
>> the next two weeks.
> 
> 
> Overall goals for nested resource providers in Queens:
> (A) Virt drivers should be able to start expressing resource inventory
> as a hierarchy, including traits, and have that understood by the
> resource tracker and scheduler.
> (B) Ops should be able to create flavors requesting resources with
> traits, including e.g. same-class resources with different traits.
> 
> Whereas many big pieces of the framework are merged:
> 
> - Placement-side API changes giving providers parents/roots, allowing
> tree representation and querying.
> - A rudimentary ProviderTree class on the compute side for
> representation of tree structure and inventory; and basic usage thereof
> by the report client.
> - Traits affordance in the placement API.
> 
> ...we're still missing the following pieces that actually enable those
> goals:
> 
> - NRP affordance in GET /allocation_candidates
>    . PATCHES: -
>    . STATUS: Not proposed
>    . PRIORITY: Critical
>    . OWNER: jaypipes
>    . DESCRIPTION: In the current master branch, the placement API will
> report allocation candidates from [(a single non-sharing provider) and
> (sharing providers associated via aggregate with that non-sharing
> provider)].  It needs to be enhanced to report allocation candidates
> from [(non-sharing providers in a tree) and (sharing providers
> associated via aggregate with any of those non-sharing providers)].
> This is critical for two reasons: 1) Without it, NRP doesn't provide any
> interesting use cases; and 2) It is prerequisite to the remainder of the
> Queens NRP work, listed below.
>    . ACTION: Jay to sling some code

Just as an aside... while I'm currently starting this work, until the 
virt drivers and eventually the generic device manager or PCI device 
manager is populating parent/child information for resource providers, 
there's nothing that will be returned in the GET /allocation_candidates 
response w.r.t. nested providers.

So, yes, it's kind of a prerequisite, but until inventory records are 
being populated from the compute nodes, the allocation candidates work 
is going to be all academic/tests.

Best,
-jay

> - Granular Resource Requests
>    . PATCHES:
> 	Placement side: https://review.openstack.org/#/c/517757/
> 	Report client side: https://review.openstack.org/#/c/515811/
>    . STATUS: WIP, blocked on the above
>    . PRIORITY: High
>    . OWNER: efried
>    . DESCRIPTION: Ability to request separate groupings of resources from
> GET /allocation_candidates via flavor extra specs.  The groundwork
> (ability to parse flavors, construct querystrings, parse querystrings,
> etc.) has already merged.  The remaining patches need to do the
> appropriate join-fu in a new placement microversion; and flip the switch
> to send flavor-parsed request groupings from report client.  The former
> needs to be able to make use of NRP affordance in GET
> /allocation_candidates, so is blocked on the above work item.  The
> latter subsumes parsing of traits from flavors (the non-granular part of
> which actually got a separate blueprint, request-traits-in-nova).
>    . ACTION: Wait for the above
> 
> - ComputeDriver.update_provider_tree()
>    . PATCHES: Series starting at https://review.openstack.org/#/c/521685/
>    . STATUS: Bottom ready for core reviews; top WIP.
>    . PRIORITY: ?
>    . OWNER: efried
>    . DESCRIPTION: This is the next phase in the evolution of compute
> driver inventory reporting (get_available_resource => get_inventory =>
> update_provider_tree).  The series includes a bunch of enabling
> groundwork in SchedulerReportClient and ProviderTree.
>    . ACTION: Reviews on the bottom (core reviewers); address
> comments/issues in the middle (efried); finish WIPs on top (efried).
> Also write up a mini-spec describing this piece in more detail (efried).
> 
> Thanks,
> Eric (efried)
> .
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>