On 01/11/2017 01:11 PM, Chris Dent wrote:
On Fri, 6 Jan 2017, Chris Dent wrote:
## can_host, aggregates in filtering
There's still some confusion (from at least me) on whether the
can_host field is relevant when making queries to filter resource
providers. Similarly, when requesting resource providers to satisfy a
set of resources, we don't (unless I've completely missed it) return
resource providers (as compute nodes) that are associated with other
resource providers (by aggregate) that can satisfy a resource
requirement. Feels like we need to work backwards from a test or use
case and see what's missing.
At several points throughout the day I've been talking with edleafe
about this to see whether "knowing about aggregates (or can_host)" when
making a request to `GET /resource_providers?resources=<some resources>`
needs to be dealt with on a scale of now, soon, later.
After much confusion I think we've established that for now we don't
need to. But we need to confirm so I said I'd write something down.
The basis for this conclusion is from three assumptions:
* The value of 'local_gb' on the compute_node object is any disk the
compute_node can see/use and the concept of associating with shared
disk by aggregates is not something that is real yet[0].
Yes.
* Any query for resources from the scheduler client is going to
include a VCPU requirement of at least one (meaning that every
resource provider returned will be a compute node[1]).
Meh, we *could* do that, but for now it's unnecessary since the only
provider records being currently created by the resource tracker
(scheduler report client) are compute node provider records.
* Claiming the consumption of some of that local_gb by the resource
tracker is the resource tracker's problem and not something we're
talking about here[2].
Yes.
If all that's true, then we're getting pretty close for near term
joy on limiting the number of hosts the filter scheduler needs to
filter[3].
Yes, and the joy merged. So, we're in full joy mode.
If it's not true (for the near term), can someone explain why not
and what need to do to fix it?
In the longer term:
Presumably the resource tracker will start reporting inventory
without DISK_GB when using shared disk, and shared disk will be
managed via aggregate associations. When that happens, the query
to GET /resource_providers will need a way to say "only give me
compute nodes that can either satisfy this resource request
directly or via associated stuff". Something tidier than:
GET
/resource_providers?resources:<something>&I_only_want_capable_or_associated_compute_nodes=True
The request from the scheduler will not change at all. The user is
requesting some resources; where those resources live is not a concern
of the user.
The techniques to do that, if I understand correctly, are in an
email from Jay that some of us received a while go with a subject of
"Some attachments to help with resource providers querying".
Butterfly joins and such like.
Yes, indeed. The can_host field -- probably better named as "is_shared"
or something like that -- can simplify some of the more complex join
conditions that querying with associated shared resource pools brings
into play. But it's more of an optimization (server side) than anything
else. Thus, I'd prefer if we keep can_host out of any REST API interfacers.
Best,
-jay
Thoughts, questions, clarifications?
[0] This is different from the issue with allocations not needing to
be recorded when the instance has non-local disk (is volume backed):
https://review.openstack.org/#/c/407180/ . Here we are talking about
recording compute node inventory.
[1] This ignores for the moment that unless someone has been playing
around there are no resource providers being created in the
placement API that are not compute nodes.
[2] But for reference will presumably come from the work started
here https://review.openstack.org/#/c/407309/ .
[3] That work starts here: https://review.openstack.org/#/c/392569/
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
