Re: [openstack-dev] [nova] [placement] *future* topics in resource providers/placement api

[Yingxin Cheng]

Hi Chris,

Thanks for the update, it's very clear about what we are going to achieve
in Newton release.


2016-07-29 0:09 GMT+08:00 Sylvain Bauza :

>
> So we had a discussion in Hillsboro about that with no consensus yet, if
> you remember.
> I heard different opinions on how nova-scheduler would integrate with the
> placement API in Ocata, and I was concerned by this service doing an HTTP
> call to an external API. My idea was rather to integrate the new placement
> tables into the existing HostManager, so that instead of getting a full
> list of compute nodes, we would provide to the filters a list of resource
> providers matching the query.
>
>
I agree to use HostManager to encapsulate the implementation about how
scheduler build up host states (or scheduler caches). It is flexible to
achieve multiple strategies, the HostManager may: 1) continue to reload the
full list of host states in the existing filter scheduler; 2) reload all
caches every configured seconds in caching scheduler; 3) get a partial list
pre-filtered by placement engine; 4) switch to an eventually consistent
solution that rarely reload caches and minimizes pressure to database.
Quantitative related filters can be unconfigured if we use the 3rd
HostManager.

-- Yingxin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [placement] *future* topics in resource providers/placement api

[Ed Leafe]

On Jul 28, 2016, at 1:19 PM, Chris Dent  wrote:

>> How about we do a query in two steps:
>> 
>> 1) take a list of compute nodes (== resource providers) and apply all
>> the filters which *can not* (or *are not* at some point) be
>> implemented in placement-api
>> 
>> 2) POST a launch request passing the *pre-filtered* list of resource
>> providers.  placement api will pick one of those RP, *claim* its
>> resources and return the claim info
> 
> While I think the ordering you describe might be useful in the use case
> that Ed has described in his message, I think for the general case it is
> backwards. We should use the placement API _first_ to winnow out those
> hosts that physically cannot satisfy the basic requirements for
> inventory of the standard resource classes and then pass that simplified
> list to the filters. That ought to be efficient and also provides a path
> for easy migration of those filters that can be implemented cleanly in
> the placement engine.

I can see several use cases where the different approaches result in different 
efficiencies. Let’s take the Watcher example, as this was the use case that 
started us down this road.

Watcher monitors a data center, and can be configured to migrate VMs to achieve 
different strategies. One such strategy is packing so that hosts that are not 
needed can be turned off, saving energy and cooling costs. In this case, 
Watcher will identify VMs that should be moved, and have a few target hosts 
that would result in better packing. In a large DC with thousands of hosts, 
having the placement API go through all those hosts when Watcher only cares 
about a handful or less is terribly inefficient. In that case, the question 
that Watcher is asking the placement API is “I need instance X migrated to one 
of these N hosts. Which of these hosts (if any) are acceptable?”.

There are many other scenarios where the opposite would be true, so I wouldn’t 
want to have it work only one way. IOW, we could change the ‘get_all_hosts’ to 
‘get_all_hosts_unless_I_already_have_some_hosts”. :)


-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] [placement] *future* topics in resource providers/placement api

[Chris Dent]

Note: I've changed the subject to make it clear that this thread is
about topics related to resource providers and the placement API
that are not relevant to newton. Ideas that we need to be chewing on
but not things that need to solved now.

On Thu, 28 Jul 2016, Roman Podoliaka wrote:

I'd personally prefer the latter. I don't think placement api will be
able to implement all the filters we currently have in
FilterScheduler.

How about we do a query in two steps:

1) take a list of compute nodes (== resource providers) and apply all
the filters which *can not* (or *are not* at some point) be
implemented in placement-api

2) POST a launch request passing the *pre-filtered* list of resource
providers.  placement api will pick one of those RP, *claim* its
resources and return the claim info


While I think the ordering you describe might be useful in the use case
that Ed has described in his message, I think for the general case it is
backwards. We should use the placement API _first_ to winnow out those
hosts that physically cannot satisfy the basic requirements for
inventory of the standard resource classes and then pass that simplified
list to the filters. That ought to be efficient and also provides a path
for easy migration of those filters that can be implemented cleanly in
the placement engine.

--
Chris Dent   ┬─┬ノ( º _ ºノ) http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev