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

Jay Pipes jaypipes at gmail.com
Tue Jun 20 12:02:08 UTC 2017


On 06/19/2017 09:26 PM, Boris Pavlovic wrote:
> Hi,
> 
> Does this look too complicated and and a bit over designed.

Is that a question?

> For example, why we can't store all data in memory of single python 
> application with simple REST API and have
> simple mechanism for plugins that are filtering. Basically there is no 
> any kind of problems with storing it on single host.

You mean how things currently work minus the REST API?

> If we even have 100k hosts and every host has about 10KB -> 1GB of RAM 
> (I can just use phone)
> 
> There are easy ways to copy the state across different instance (sharing 
> updates)

We already do this. It isn't as easy as you think. It's introduced a 
number of race conditions that we're attempting to address by doing 
claims in the scheduler.

> And I thought that Placement project is going to be such centralized 
> small simple APP for collecting all
> resource information and doing this very very simple and easy placement 
> selection...

1) Placement doesn't collect anything.
2) Placement is indeed a simple small app with a global view of resources
3) Placement doesn't do the sorting/weighing of destinations. The 
scheduler does that. See this thread for reasons why this is the case 
(operators didn't want to give up their complexity/flexibility in how 
they tweak selection decisions)
4) Placement simply tells the scheduler which providers have enough 
capacity for a requested set of resource amounts and required 
qualitative traits. It actually is pretty simple.

Best,
-jay

> Best regards,
> Boris Pavlovic
> 
> On Mon, Jun 19, 2017 at 5:05 PM, Edward Leafe <ed at leafe.com 
> <mailto:ed at leafe.com>> wrote:
> 
>     On Jun 19, 2017, at 5:27 PM, Jay Pipes <jaypipes at gmail.com
>     <mailto:jaypipes at gmail.com>> wrote:
>>
>>>     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.
>>
>>     It was the "per compute host" that I objected to.
> 
>     I guess it would have helped to see an example of the data returned
>     for multiple compute nodes. The straw man example was for a single
>     compute node with SR-IOV, NUMA and shared storage. There was no
>     indication how multiple hosts meeting the requested resources would
>     be returned.
> 
>     -- Ed Leafe
> 
> 
> 
> 
> 
> 
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list