[openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

Edward Leafe ed at leafe.com
Mon Jun 19 21:24:15 UTC 2017


On Jun 19, 2017, at 1:34 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> 
>> 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.

It was from the straw man example. Replacing the $FOO_UUID with UUIDs, and then stripping out all whitespace resulted in about 1500 bytes. Your example, with whitespace included, is 1600 bytes. 

> Here's a paste with the before and after of what we're talking about:
> 
> http://paste.openstack.org/show/613129/ <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.

So in the basic non-shared, non-nested case, if there are, let’s say, 200 compute nodes that can satisfy the request, will there be 1 “allocation_requests” key returned, with 200 “allocations” sub-keys? And one “provider_summaries” key, with 200 sub-keys on the compute node UUID?

> gzipping the after contents results in 358 bytes.
> 
> So, honestly I'm not concerned.

Ok, just wanted to be clear.

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


So in the near-term, we will be using provider_summaries to update the corresponding HostState objects with those values. Is the long-term plan to have most of the HostState information moved to placement?


-- Ed Leafe





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170619/b49cba4e/attachment.html>


More information about the OpenStack-dev mailing list