Open Stack

Agreed.

Ed Leafe (dabo) is slated to work on the scheduler plugins that make the decisions for which zone to use.

https://blueprints.launchpad.net/nova/+spec/bexar-distributed-scheduler

<https://blueprints.launchpad.net/nova/+spec/bexar-distributed-scheduler>You might want to review that one as well.

-S

________________________________
From: openstack-bounces+sandy.walsh=rackspace.com at lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace.com at lists.launchpad.net] on behalf of Justin Santa Barbara [justin at fathomdb.com]
Sent: Thursday, February 10, 2011 7:38 PM
To: Devin Carlen
Cc: openstack at lists.launchpad.net
Subject: Re: [Openstack] Allowing clients to pass capability requests through tags?

I think the blueprint was largely complementary to the multi-zone stuff; this is more about how the client _requests_ a particular location/capability through the API.  The multi-zone blueprint seems to be more about how nova would satisfy those requests (in a non-trivial zone structure.)

The root motivator is indeed getting a 'good' connection to a storage volume.  I'm thinking of iSCSI SAN storage here, so in my case this probably means the SAN device with the least number of switches in between.  There could well be SAN devices in each rack (e.g. Solaris volume nodes), or the devices could even be running on the host nodes, and I don't believe that zones in the EC2 sense are sufficient here.

But I guess that if the zone hierarchy went all the way down to the rack (or machine), that would work.  So I could create a volume and it would come back with a location of "rack4.room2.dc1.dfw.rackspace.com<http://rack4.room2.dc1.dfw.rackspace.com>" and I could then request allocation of machines in that same rack?  Is that the vision of the nested zones?

I do have a concern that long-term if we _only_ use zones, that's trying to multiplex a lot of information into the zone hierarchy, and we can really only put one attribute in there.  I also like the flexibility of the 'openstack:near=vol-000001' request, because then the cloud can decide how near to place the instance based on its knowledge of the topology, and the clients can be oblivious to the storage system and arrangement.  But, my immediate requirement would indeed be satisfied if the zones went down to the rack/machine level.

An alternative way to look at zones and instance-types is that they're actually just fail-if-not-satisfiable tags of the creation request (openstack:+zone=us-east-1a and openstack:+instancetype=m1.large)  They're only distinguished attributes because AWS doesn't have an extensibility mechanism, which this blueprint would give us.

Justin




On Thu, Feb 10, 2011 at 3:12 PM, Devin Carlen <devcamcar at me.com<mailto:devcamcar at me.com>> wrote:
I haven't totally digested this blueprint yet but it seems like there is some overlap with what is being discussed with the multi zone metadata stuff.  One approach might be to handle this awt the scheduler level though and try to ensure things are always in the same zone when appropriate.

I think the bigger question you raise is how to request local volumes when possible, yes?

Devin

On Feb 10, 2011, at 3:37 PM, Justin Santa Barbara <justin at fathomdb.com<mailto:justin at fathomdb.com>> wrote:

Does anyone have any thoughts/objections on the blueprint I posted for allowing clients to pass capability-requests through tags?  I'm planning on starting implementation soon, so if people think this is a bad idea I'd rather know before I start coding!

Blueprint: <https://blueprints.launchpad.net/nova/+spec/use-metadata-tags-for-capabilities> https://blueprints.launchpad.net/nova/+spec/use-metadata-tags-for-capabilities
<https://blueprints.launchpad.net/nova/+spec/use-metadata-tags-for-capabilities>Wiki: <https://blueprints.launchpad.net/nova/+spec/use-metadata-tags-for-capabilities> https://blueprints.launchpad.net/nova/+spec/use-metadata-tags-for-capabilities

<https://blueprints.launchpad.net/nova/+spec/use-metadata-tags-for-capabilities>And a quick TLDR:
API clients need a way to request e.g. placement of machines near each other / near volumes, or that a volume be created with a particular RAID level, or that a machine be created in a HIPAA compliant environment.  (This is complementary to the work on hierarchical zones & URL naming, I believe)

I propose using the instance tags for this, e.g. specifying openstack:near=vol-000001 when creating an instance to request locating the instance 'close to' that volume.

By default these requests would be best-effort and ignored-if-unknown; if the client wants to specify that something is required and should fail if not understood or not satisfiable, they could use a "+" e.g. openstack:+location=*.<http://dc1.north.rackspace.com>dc1.north.rackspace.com<http://dc1.north.rackspace.com>

Controversially (?), this would not be supported for clients using the AWS API, because tags can only be specified once the instance has already been created.


Feedback appreciated!

Justin



_______________________________________________
Mailing list: <https://launchpad.net/~openstack> https://launchpad.net/~openstack
Post to     : <mailto:openstack at lists.launchpad.net> openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
Unsubscribe : <https://launchpad.net/~openstack> https://launchpad.net/~openstack
More help   : <https://help.launchpad.net/ListHelp> https://help.launchpad.net/ListHelp



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 abuse at rackspace.com, and delete the original message.
Your cooperation is appreciated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110210/ef1ccbaf/attachment.html>