rger" ,
openstack@lists.launchpad.net
Sent: Friday, April 15, 2011 2:24:21 PM
Subject: Re: [Openstack] distributed and heterogeneous schedulers
Each update from the services are atomic updates ... fully self contained.
Why does this need to be in a persistent store?
-S
_
April 15, 2011 2:24:21 PM
Subject: Re: [Openstack] distributed and heterogeneous schedulers
Each update from the services are atomic updates ... fully self contained.
Why does this need to be in a persistent store?
-S
From: Jay Pipes [jaypi...@gmail.com]
> you
aunchpad.net
Subject: Re: [Openstack] distributed and heterogeneous schedulers
Each update from the services are atomic updates ... fully self contained.
Why does this need to be in a persistent store?
-S
From: Jay Pipes [jaypi...@gmail.com]
> you still
ubject: Re: [Openstack] distributed and heterogeneous schedulers
Each update from the services are atomic updates ... fully self contained.
Why does this need to be in a persistent store?
-S
From: Jay Pipes [jaypi...@gmail.com]
> you still need a persistent d
Each update from the services are atomic updates ... fully self contained.
Why does this need to be in a persistent store?
-S
From: Jay Pipes [jaypi...@gmail.com]
> you still need a persistent data store for attributes of the host. Just
> because you
> s
On Apr 15, 2011, at 12:02 PM, Jay Pipes wrote:
> This is getting totally off-track :)
Of course! Don't all email threads do that? :)
> My point was that if you are going to put data in a database table,
> the attributes that go into the main table should be the attributes
> that are com
This is getting totally off-track :)
My point was that if you are going to put data in a database table,
the attributes that go into the main table should be the attributes
that are common to all types of an entity, otherwise, use the table
that stores the custom key/value pairs.
-jay
On Fri, Ap
On Apr 15, 2011, at 11:43 AM, Jay Pipes wrote:
> Yes, I'm aware of how the Zone Manager works. But, you still need a
> persistent data store for attributes of the host. Just because you
> store a cached in-memory copy of instance attributes, doesn't mean you
> don't need a persistent data store. Y
On Fri, Apr 15, 2011 at 11:19 AM, Ed Leafe wrote:
> On Apr 15, 2011, at 10:37 AM, Jay Pipes wrote:
>
>> The extra data would be more for the compute_nodes table I think, or
>> is it called hosts now?
>
>
> I'm not sure how useful the compute_nodes table is anymore, at least
> not for sched
On Apr 15, 2011, at 10:37 AM, Jay Pipes wrote:
> The extra data would be more for the compute_nodes table I think, or
> is it called hosts now?
I'm not sure how useful the compute_nodes table is anymore, at least
not for scheduler. Currently only libvirt seems to populate it. I know it'
l 15, 2011 11:37 AM
> To: Sandy Walsh
> Cc: Mark Washenberger; openstack@lists.launchpad.net
> Subject: Re: [Openstack] distributed and heterogeneous schedulers
>
> The extra data would be more for the compute_nodes table I think, or
> is it called hosts now?
>
> -jay
>
>
1 11:37 AM
To: Sandy Walsh
Cc: Mark Washenberger; openstack@lists.launchpad.net
Subject: Re: [Openstack] distributed and heterogeneous schedulers
The extra data would be more for the compute_nodes table I think, or
is it called hosts now?
-jay
On Fri, Apr 15, 2011 at 10:06 AM, Sandy Walsh wrote:
>
The extra data would be more for the compute_nodes table I think, or
is it called hosts now?
-jay
On Fri, Apr 15, 2011 at 10:06 AM, Sandy Walsh wrote:
> Hey guys,
>
> I don't understand how adding more data to the *instances* table will be used
> for scheduling?
>
> Perhaps what you're talking
Hey guys,
I don't understand how adding more data to the *instances* table will be used
for scheduling?
Perhaps what you're talking about is metadata in Glance on the source images?
If so, that data would simply be added to the required-capabilities that get
passed into the scheduler during t
that Jay's suggestion of adding is_user_added column is reasonable and
a quick solution.
Thanks,
Joseph
- Original Message -
From: "Jay Pipes"
To: "Mark Washenberger"
Cc: openstack@lists.launchpad.net
Sent: Thursday, April 14, 2011 11:29:27 AM
Subject: Re: [Opens
Pipes [jaypi...@gmail.com]
Sent: Thursday, April 14, 2011 12:29 PM
To: Mark Washenberger
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] distributed and heterogeneous schedulers
This is an excellent point, Mark, I'd forgotten about the quota system
for user-defined (and nova-ignore
This is an excellent point, Mark, I'd forgotten about the quota system
for user-defined (and nova-ignored) "metadata" items. That does throw
a bit of a wrench into the mix. Perhaps a small edit to the
instance_metadata table to add a column for is_user_added that can be
used to segregate metadata i
2011/4/14 Ed Leafe :
>> It seems to me that the current load only affects the time it will
>> take to spin up the new instance, and as such says nothing about its
>> long term (or even medium or short term!) suitability as the new
>> instance's home.
> Such a consideration would not be the primary
On Apr 14, 2011, at 9:40 AM, Soren Hansen wrote:
>> When scheduling, the instance has not been created yet. We have to make
>> decisions on where the instance will ultimately reside on a number of
>> factors:
>>
>> 1. the capabilities of the host hypervisor (the Compute node)
>> 2. the current
> From: Soren Hansen [so...@openstack.org]
>> 2. the current load the host is under
>
> I still question the usefulness of nr. 2. A host that is almost
> completely idle right now might be under tremendous pressure a minute
> from now and vice versa. Even if we had useful statistics (and trend
> a
> 1) Continue to add fields to the instances table (or compute_nodes
> table) for these main attributes like cpu_arch, etc.
> 2) Use the custom key/value table (instance_metadata) to store these
> attribute names and their values
> 3) Do both 1) and 2)
I've no particular preference here, but if we
2011/4/14 Sandy Walsh :
> Let's not confuse instance metadata with Compute Node Capabilities.
>
> When scheduling, the instance has not been created yet. We have to make
> decisions on where the instance will ultimately reside on a number of factors:
>
> 1. the capabilities of the host hypervisor
Let's not confuse instance metadata with Compute Node Capabilities.
When scheduling, the instance has not been created yet. We have to make
decisions on where the instance will ultimately reside on a number of factors:
1. the capabilities of the host hypervisor (the Compute node)
2. the current
chott
> Sent: Thursday, April 14, 2011 7:14 AM
> To: Jay Pipes
> Cc: openstack@lists.launchpad.net
> Subject: Re: [Openstack] distributed and heterogeneous schedulers
>
> Jay,
>
> > :( I've brought this up before as well. The term metadata is used
> > incorrectly to
chott
> Sent: Thursday, April 14, 2011 7:14 AM
> To: Jay Pipes
> Cc: openstack@lists.launchpad.net
> Subject: Re: [Openstack] distributed and heterogeneous schedulers
>
> Jay,
>
> > :( I've brought this up before as well. The term metadata is used
> > incorrectly to
Jay,
> :( I've brought this up before as well. The term metadata is used
> incorrectly to refer to custom key/value attributes of something
> instead of referring to data about the data (for instance, the type
> and length constraints of a data field).
We could move the cpu_info, xpu_info, and ne
On Apr 12, 2011, at 12:34 PM, Brian Schott wrote:
> - Will your capabilities scheduler, constraint scheduler, and/or distributed
> schedulers understand different available hardware resources on compute nodes?
The distributed scheduler has the concept of 'capabilities', and would
be ab
Hi Brian, comments inline :)
On Tue, Apr 12, 2011 at 12:34 PM, Brian Schott wrote:
>
> I'm trying to understand how best to implement our architecture-aware
> scheduler for Diablo:
> https://blueprints.launchpad.net/nova/+spec/schedule-instances-on-heterogeneous-architectures
>
> Right now our s
I'm trying to understand how best to implement our architecture-aware scheduler
for Diablo:
https://blueprints.launchpad.net/nova/+spec/schedule-instances-on-heterogeneous-architectures
Right now our scheduler is similar in approach to SimpleScheduler with a few
extra filters on instances and c
29 matches
Mail list logo
