Cool! Glad to hear we're on the right path. Yes, we're using rabbit to send the 
metrics to the schedulers since they're largely ephemeral.

We'll be using the existing scheduler.host_filter:HostFilter code to fill out 
the filter_hosts() method. Other groups will be making more drivers for that 
component as well. The overall plan is in our Zones101 summit presentation 
available here: http://dl.dropbox.com/u/166877/Zones-101.pdf

We're not working on KVM ourselves ... hoping for the community to jump in 
there.

Hope it helps,
-S

________________________________
From: Lorin Hochstein [[email protected]]
Sent: Thursday, May 12, 2011 12:26 AM
To: Sandy Walsh
Cc: Openstack; [email protected]
Subject: Re: [Openstack] Zones / distributed scheduler question

Sandy:

I took a quick look at see how capabilities are represented and how the 
information flows from the ComputeManager to the ZoneManager, it looks great. I 
see you're using the message queue (RPC call) instead of storing the capability 
info in the database. Anxiously awaiting for this code to make it to the trunk

I also see that there's a complete-looking implementation of the 
XenAPIConnection.get_host_stats method, but LibvirtConnection.get_host_stats is 
a no-op. Do you plan on implementing similar functionality for KVM (e.g., 
reporting memory and disk free), or will that be up to other people to get that 
code in there?

Take care,

Lorin
--
Lorin Hochstein, Computer Scientist
USC Information Sciences Institute
703.812.3710
http://www.east.isi.edu/~lorin

On May 11, 2011, at 8:12 PM, Sandy Walsh wrote:

Hey again!

dabo, sirp and myself have been working on the Distributed Scheduler branch, 
which does all this.

It's a large branch, so while Ed (dabo) continues on getting things functional, 
myself and Rick (sirp) have started pulling chunks of code from the branch and 
getting smaller merge-props in.

Expect to see the first to land, hopefully, tomorrow. This will give you a good 
idea of the capabilities functionality and the extension points. You can have a 
sneak peak at lp:~sandy-walsh/nova/dist-sched-1

Cheers,
-S

________________________________
From: Lorin Hochstein [[email protected]]
Sent: Wednesday, May 11, 2011 1:47 PM
To: Sandy Walsh
Cc: Openstack
Subject: Re: [Openstack] Zones / distributed scheduler question

Hi Sandy:

Do you know if there are there any nova branches floating out there that 
implement Capabilities? I've seen the following related wiki pages and 
blueprints, but I haven't found any implementations out there yet.

https://blueprints.launchpad.net/nova/+spec/extra-data
https://blueprints.launchpad.net/nova/+spec/use-metadata-tags-for-capabilities
http://wiki.openstack.org/RequestCapabilities

The zone scheduler slides mention capabilities as well, but those are at the 
"zone" level, and we're potentially interested in compute nodes with different 
capabilities within the same zone.

(Note that for our use case, we'll probably be using flavors to specify 
different capabilities, so we don't (yet) need the users to be able to send 
arbitrary strings using the API).

Lorin
--
Lorin Hochstein, Computer Scientist
USC Information Sciences Institute
703.812.3710
http://www.east.isi.edu/~lorin

On May 11, 2011, at 11:54 AM, Sandy Walsh wrote:

Hi Lorin,

Zones can have multiple parents. Child Zones don't know their parents ... 
parents only know about children.

Sharing services across Zones isn't permitted (since they would need to share a 
DB and AMQP).

You could solve the problem by using the Capabilities to determine where 
instances are created (GPU only or not) or create smaller sub-zones for 
GPU/not-GPU and let the parent zones select between them.

-S


________________________________
From: 
[email protected]<mailto:[email protected]>
 [[email protected]] on behalf of 
Lorin Hochstein [[email protected]]
Sent: Wednesday, May 11, 2011 12:06 PM
To: Openstack
Subject: [Openstack] Zones / distributed scheduler question

All:

For the proposed zones / distributed scheduler functionality 
<https://blueprints.launchpad.net/nova/+spec/zones101>, can we defines  zones 
that overlap without being nested?

Consider the scenario where:

* We have two datacenters: one in Arlington, Virginia (ARL), and one in Marina 
del Rey, California (MDR).
* At each datacenter, we have both conventional x86 nodes and  nodes with GPUs

Can we define our zones such that:

* We have a zone for each datacenter (ARL, MDR)
* We have a zone for GPU nodes  (GPU)

In this case, the GPU zone would both overlap the ARL and MDR zones, but ARL 
and MDR would not be fully nested within GPU.


Lorin
--
Lorin Hochstein, Computer Scientist
USC Information Sciences Institute
703.812.3710
http://www.east.isi.edu/~lorin


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at [email protected]<mailto:[email protected]>, and delete the original 
message.
Your cooperation is appreciated.



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at [email protected]<mailto:[email protected]>, and delete the original 
message.
Your cooperation is appreciated.




Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace. 
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at [email protected], and delete the original message. 
Your cooperation is appreciated.

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to