/2013 01:22 AM
Subject:Re: [openstack-dev] [Nova] support for multiple active
scheduler policies/drivers
On Wed, Jul 24, 2013 at 6:18 PM, Alex Glikson GLIKSON at il.ibm.com wrote:
Russell Bryant rbryant at redhat.com wrote on 24/07/2013 07:14:27 PM:
I really like your point
for multiple active
scheduler policies/drivers
From: Joe Gordon [mailto:joe.gord...@gmail.com]
Sent: 26 July 2013 23:16
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Nova] support for multiple active
scheduler policies/drivers
On Wed, Jul 24, 2013 at 6:18 PM
From: Joe Gordon [mailto:joe.gord...@gmail.com]
Sent: 26 July 2013 23:16
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Nova] support for multiple active scheduler
policies/drivers
On Wed, Jul 24, 2013 at 6:18 PM, Alex Glikson glik...@il.ibm.com wrote:
Russell
: [openstack-dev] [Nova] support for multiple active scheduler
policies/drivers
On 07/23/2013 04:24 PM, Alex Glikson wrote:
Russell Bryant rbry...@redhat.com wrote on 23/07/2013 07:19:48 PM:
I understand the use case, but can't it just be achieved with 2
flavors and without this new
On 07/24/2013 05:39 AM, Day, Phil wrote:
Hi Alex,
I'm inclined to agree with others that I'm not sure you need the complexity
that this BP brings to the system.If you want to provide a user with a
choice about how much overcommit they will be exposed to then doing that in
flavours
Subject: Re: [openstack-dev] [Nova] support for multiple active
scheduler
policies/drivers
On 07/23/2013 04:24 PM, Alex Glikson wrote:
Russell Bryant rbry...@redhat.com wrote on 23/07/2013 07:19:48 PM:
I understand the use case, but can't it just be achieved with 2
flavors
Russell Bryant rbry...@redhat.com wrote on 24/07/2013 07:14:27 PM:
I really like your point about not needing to set things up via a config
file. That's fairly limiting since you can't change it on the fly via
the API.
True. As I pointed out in another response, the ultimate goal would be
On 07/23/2013 12:24 AM, Alex Glikson wrote:
Russell Bryant rbry...@redhat.com wrote on 23/07/2013 01:04:24 AM:
[1]
https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers
[2] https://wiki.openstack.org/wiki/Nova/MultipleSchedulerPolicies
[3]
Russell Bryant rbry...@redhat.com wrote on 23/07/2013 05:35:18 PM:
#1 - policy associated with a host aggregate
This seems very odd to me. Scheduling policy is what chooses hosts,
so
having a subset of hosts specify which policy to use seems backwards.
This is not what we had in
On 07/23/2013 12:02 PM, Alex Glikson wrote:
Russell Bryant rbry...@redhat.com wrote on 23/07/2013 05:35:18 PM:
#1 - policy associated with a host aggregate
This seems very odd to me. Scheduling policy is what chooses hosts, so
having a subset of hosts specify which policy to use seems
Russell Bryant rbry...@redhat.com wrote on 23/07/2013 07:19:48 PM:
I understand the use case, but can't it just be achieved with 2 flavors
and without this new aggreagte-policy mapping?
flavor 1 with extra specs to say aggregate A and policy Y
flavor 2 with extra specs to say aggregate B
On 07/23/2013 04:24 PM, Alex Glikson wrote:
Russell Bryant rbry...@redhat.com wrote on 23/07/2013 07:19:48 PM:
I understand the use case, but can't it just be achieved with 2 flavors
and without this new aggreagte-policy mapping?
flavor 1 with extra specs to say aggregate A and policy Y
Dear all,
Following the initial discussions at the last design summit, we have
published the design [2] and the first take on the implementation [3] of
the blueprint adding support for multiple active scheduler
policies/drivers [1].
In a nutshell, the idea is to allow overriding the 'default'
On 07/22/2013 05:15 PM, Alex Glikson wrote:
Dear all,
Following the initial discussions at the last design summit, we have
published the design [2] and the first take on the implementation [3] of
the blueprint adding support for multiple active scheduler
policies/drivers [1].
In a
On Mon, Jul 22, 2013 at 3:04 PM, Russell Bryant rbry...@redhat.com wrote:
On 07/22/2013 05:15 PM, Alex Glikson wrote:
Dear all,
Following the initial discussions at the last design summit, we have
published the design [2] and the first take on the implementation [3] of
the blueprint
15 matches
Mail list logo
