On 06/19/2017 01:59 PM, Edward Leafe wrote:
While we discussed the fact that there may be a lot of entries, we did
not say we'd immediately support a paging mechanism.
OK, thanks for clarifying that. When we discussed returning 1.5K per
compute host instead of a couple of hundred bytes, there was discussion
that paging would be necessary.
Not sure where you're getting the whole 1.5K per compute host thing from.
Here's a paste with the before and after of what we're talking about:
http://paste.openstack.org/show/613129/
Note that I'm using a situation with shared storage and two compute
nodes providing VCPU and MEMORY. In the current situation, the shared
storage provider isn't returned, as you know.
The before is 231 bytes. The after (again, with three providers, not 1)
is 1651 bytes.
gzipping the after contents results in 358 bytes.
So, honestly I'm not concerned.
Again, operators have insisted on keeping the flexibility currently in
the Nova scheduler to weigh/sort compute nodes by things like thermal
metrics and kinds of data that the Placement API will never be
responsible for.
The scheduler will need to merge information from the
"provider_summaries" part of the HTTP response with information it has
already in its HostState objects (gotten from
ComputeNodeList.get_all_by_uuid() and AggregateMetadataList).
OK, that’s informative, too. Is there anything decided on how much host
info will be in the response from placement, and how much will be in
HostState? Or how the reporting of resources by the compute nodes will
have to change to feed this information to placement? Or how the two
sources of information will be combined so that the filters and weighers
can process it? Or is that still to be worked out?
I'm currently working on a patch that integrates the REST API into the
scheduler.
The merging of data will essentially start with the resource amounts
that the host state objects contain (stuff like total_usable_ram etc)
with the accurate data from the provider_summaries section.
Best,
-jay
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
