On Tue, Apr 3, 2012 at 7:10 PM, Vishvananda Ishaya
wrote:
>
> On Apr 3, 2012, at 6:45 AM, Day, Phil wrote:
>
> Hi John,
>
> Maybe the problem with host aggregates is that it too quickly became
> something that was linked to hypervisor capability, rather than being the
> more general mechanism of w
Ishaya
Sent: Tuesday, April 03, 2012 1:11 PM
To: Day, Phil
Cc: openstack@lists.launchpad.net; John Garbutt
Subject: Re: [Openstack] Limit flavors to specific hosts
On Apr 3, 2012, at 6:45 AM, Day, Phil wrote:
Hi John,
Maybe the problem with host aggregates is that it too quickly became
...@gmail.com]
Sent: 03 April 2012 19:11
To: Day, Phil
Cc: John Garbutt; Jan Drake; Lorin Hochstein; openstack@lists.launchpad.net
Subject: Re: [Openstack] Limit flavors to specific hosts
On Apr 3, 2012, at 6:45 AM, Day, Phil wrote:
Hi John,
Maybe the problem with host aggregates is that it too
On Apr 3, 2012, at 6:45 AM, Day, Phil wrote:
> Hi John,
>
> Maybe the problem with host aggregates is that it too quickly became
> something that was linked to hypervisor capability, rather than being the
> more general mechanism of which one form of aggregate could be linked to
> hypervisor
: [Openstack] Limit flavors to specific hosts
If I understand this correctly, the motivation is to be able to provide a hint
to schedulers on host-level appropriateness based on information external to
that found in the hyperviser.
Right/Wrong/Close?
It would help to have a real-world example of
Jan:
Here are two use cases from when I was at ISI. In both cases, we wanted access
to a machine with customized hardware to improve performance of certain
applications:
1. GPUs. We wanted the users to be able to specify request a host that had GPU
cards so they could run GPU-accelarated apps
If I understand this correctly, the motivation is to be able to provide a hint
to schedulers on host-level appropriateness based on information external to
that found in the hyperviser.
Right/Wrong/Close?
It would help to have a real-world example of where basic host resource
evalution for s
Just created a blueprint for this:
https://blueprints.launchpad.net/nova/+spec/host-capabilities-api
Take care,
Lorin
--
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com
On Apr 2, 2012, at 3:29 PM, Jay Pipes wrote:
> Can I add a feature request
+1
-Original Message-
From: openstack-bounces+ed_conzel=dell@lists.launchpad.net
[mailto:openstack-bounces+ed_conzel=dell@lists.launchpad.net] On Behalf Of
Jay Pipes
Sent: Monday, April 02, 2012 2:29 PM
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] Limit flavors to
Can I add a feature request to the below thoughtstream? Can we make it
so that the management of these things can be done outside of config
files? i.e. via a REST API with some simple middleware exposing the
particular scheduler nodes' understanding of which capabilities/filters
it is using to
Phil:
I don't know of a way to do this in Essex. However, when I was working at ISI,
we added a configuration option called "extra_node_capabilities" that allows
you to specify the capabilities of a particular host in the
/etc/nova/nova.conf, and these capabilities are checked against the
extr
I have some plans for being able to set arbitrary "capabilities" for hosts via
nova.conf that you can use to build scheduler filters.
Right now, there are capabilities, but I believe we're only creating these from
hypervisor stats. You can filter on those today. What I'm planning on adding
is
Hi Folks,
I'm looking for a capability to limit some flavours to some hosts. I want the
mapping to be as flexible as possible, and work within a zone/cell (I don't
want to add zones just to get this mapping).For example I want to express
something like:
Host_1 supports flavours A, C
Host
13 matches
Mail list logo
