Open Stack

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