openstack team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

The main reason I was proposing full location/zone of objects is to
allow this type of 'near' scheduling to happen without understanding
what the actual object is. For example, imagine we want to start an
instance near a particular swift object. We could query the swift
object and in the metadata there could be a 'zone' tag (well, three,
one for each copy). For example:

get swift-12345: zone=rack12.room2.dc1.dfw.rackspace.com

I can now use that zone name to:

create_instance: openstack:near=rack12.room2.dc1.dfw.rackspace.com

The deployment can decide what 'near' is (perhaps a measure of link
speed or latency). This way a particular deployment that uses the
same URI/zone names across projects can account for locality without
knowing what objects from different services are. If it were just
'near=swift-12345', it would need to understand what a swift object
was and perform that lookup to find out where it is.

So you can still grab a zone tag from a volume you created:

get vol-000001: rack4.room2.dc1.dfw.rackspace.com

and use the zone to launch an instance with:

create_instance: openstack:near=rack4.room2.dc1.dfw.rackspace.com

We can also write schedulers/tools for a particular deployment
that understands the zones to just say 'always prefer in
dc1.dfw.rackspace.com', because power is cheaper there right now, or
'test.dc1.dfw.rackspace.com' because that is my test zone (perhaps
only enabled for certain accounts in the scheduler too).

-Eric

On Thu, Feb 10, 2011 at 03:38:42PM -0800, Justin Santa Barbara wrote:
>    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
>        Wiki: 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=*.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
>        Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>        Unsubscribe : https://launchpad.net/~openstack
>        More help   : https://help.launchpad.net/ListHelp

> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp