openstack team mailing list archive

[Justin Santa Barbara <justin@xxxxxxxxxxxx>]

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" 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@xxxxxx> 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@xxxxxxxxxxxx>
> 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
>
> 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     : <openstack@xxxxxxxxxxxxxxxxxxx>openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : <https://launchpad.net/~openstack>
> https://launchpad.net/~openstack
> More help   : <https://help.launchpad.net/ListHelp>
> https://help.launchpad.net/ListHelp
>
>