openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

And what about for volumes? We need a similar "tagging" ability for
volumes, too. Is there an equalivent?

-jay

On Fri, Feb 11, 2011 at 2:42 PM, Brian Schott <bschott@xxxxxxx> wrote:
> On Feb 11, 2011, at 2:12 PM, Jay Pipes wrote:
>
>> Hehe, sounds like something to chat about over a beer at the next
>> design summit ;)
>
> Looking forward to it... I enjoyed the last one.
>
>> The issue isn't necessarily how to pass instance type, but how to pass
>> *arbitrary* client request parameters, so I thought that user_data in
>> the EC2 API was a good place for those, and was wondering (kinda out
>> loud ;) ) what the best "field" or "place" would be on the OpenStack
>> API side of things for that kind of arbitrary client request
>> attribute..
>
> For the EC2 API, I think that we're safer appending key-value pairs to instance_type field.  euca2ools just takes the string verbatim.  The problem with user_data is it is interpreted by existing images in all sorts of ways.  Like if "#!" is the first 2 characters, Ubuntu processes it as a bash shell script.  Very handy, bad to break.  Lots of cloud users depend on it working.  Most cloud development frameworks depend on unmolested user_data, since it is the only way to pass configuration data down to instances easily.  I can't think of any other field that makes sense from the EC2-centric perspective.
>
> Also want to stress to think about flavors/instance_types as "advertised" configurations, but that deployments might want to allow even these to be overridden.
>
> ---
> Brian Schott, Project Leader
> USC Information Sciences Institute
> http://www.east.isi.edu/~bschott
> ph: 703-812-3722 fx: 703-812-3712
>
>
>
>