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
- 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
