Open Stack

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