openstack team mailing list archive

[Justin Santa Barbara <justin@xxxxxxxxxxxx>]

Can I try to summarize towards reaching a consensus:


On Metadata for influencing schedulers / drivers:

* I think people agree that it would be useful to be able to pass
metadata in the request.  e.g. for location, or to get specific
hardware functionality (GPU or RAID), and for other things in future
* My personal use case is to get volumes near compute nodes; others
have their own use cases (e.g. HPC)
* We can't predict all these use cases today, and nor do we want the
API to explode in size as we discover them all.
* There are some additional blueprints which deal with how we'll
actually satisfy those requests (distributed schedulers, hierarchical
zones, URI zone naming)
* Some of the location requirements could also be satisfied through
URI zone naming.  We can see zones as another metadata key (though a
special one from the point of view of hierarchical zones)
* There is also some overlap with instance-types.  Instance types
could also be defined including extensible metadata, and we could also
take the instance-type as defining a set of metadata which is merged
into the request.  This could avoid an explosion of instance types.
* If we support openstack:near=vol-00001, this lets the client be
oblivious to the internal architecture of the cloud.
* We can _also_ support URI naming;
openstack:location=rack4.room2.dfw.rackspace.com; this will let us
work with external systems (like Swift)
* By making all requests best-effort unless preceded with a + sign, I
think we avoid a lot of the deeper problems here with everyone's
scenario being different (as with the openstack:near vs
openstack:location debate)
* There are some existing efforts at USC ISI which we should work with

On how to fit this into the API:

* The CloudServers API (and hence the OpenStack API) supports passing
keys at instance create time.  We might need to add support for
metadata for volumes.  This is OK, because the framework is there, and
this API is under our control.
* The EC2 API doesn't support this and is not under our control
(unless Eucalyptus works with us here).  By overloading the zone or
instance_type fields we can hack around this problem.  This is purely
a hack: the zone would be appended with a magic string, which would
presumably be stripped out at the API layer and converted to a richer
request.  By using the zone instead of the instance_type, we can pass
this metadata on volumes also.   This would probably look like
--availability-zone=friend-zone;openstack:gpu=nvidia
* We can reserve the openstack: prefix to avoid collisions; AWS
reserves the aws: prefix.



Justin






On Fri, Feb 11, 2011 at 11:31 AM, Soren Hansen <soren@xxxxxxxxxx> wrote:
>
> 2011/2/11 Jay Pipes <jaypipes@xxxxxxxxx>:
> > On Thu, Feb 10, 2011 at 7:21 PM, Brian Schott <bfschott@xxxxxxxxx> wrote:
> >> Justin,
> >>
> >> Our USC-ISI team is very interested in this.  We are implementing different architecture types beyond x86_64.  We are also interested in suggesting switch topology for MPI cluster jobs, passing in requests for GPU accelerators, etc.  Currently, our approach has been to specify these through instance_types. What you describe is more flexible, but I wonder if for EC2 api we could stretch the -t flag.
> >
> > Just to make something clear, the EC2 API has nothing to do with the
> > -t flag.
>
> Sorry, what? It's passed verbatim in the EC2 RunInstances API call:
>
>   http://docs.amazonwebservices.com/AWSEC2/latest/APIReference/index.html?ApiReference-query-RunInstances.html
>
> ..so it's certainly part of the API.
>
> > That is specific to the eucatools (or ec2 CLI tools).  The
> > request that goes through to the EC2 API controller (in nova, this is
> > nova.api.ec2.cloud.CloudController), passing to the controller an XML
> > packet that has a variety of fields that the controller then looks for
> > in populating the database with information about the instance to spin
> > up.
>
> This doesn't sound familiar at all. Can you provide a reference to any of this?
>
> > Tacking on something to the -t flag would be a total hack that
> > wouldn't be particularly future-proof.
>
> Actually, given the limitations the EC2 imposes, I think it's actually a pretty
> good idea. I can't think of a better way to attempt to expose this in
> the EC2 API.
>
> > I think that perhaps the user_data field in the XML might be a better
> > choice, since this has a more free-form capacity than a very specific
> > instance_type code that the EC2 API controller looks for.
>
> The user-data field is used by the user to pass information through to
> the instance. It's typically used for post-boot configuration of sorts
> for the VM's. If we steal it for this purpose, we lose the ability to
> pass stuff this way.
>
> --
> Soren Hansen
> Ubuntu Developer    http://www.ubuntu.com/
> OpenStack Developer http://www.openstack.org/
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp