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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
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
