We have to keep in mind, that any additions to ec2_api will by definition be a hack. We should attempt to support it as best we can, but consider how we would like things to work on a grander scale.
We are currently discussing two different sets of tags: 1. the type of instance to create. (local storage gb, gpu enabled, architecture, etc.) 2. where to create the image (near object x, in a certain zone, on a specific host, etc.) I think both of these items are valuable, and perhaps in the os api they could be passed in all together. From the ec2 perspective, I think that the "best" option would be to put type-related tags into the -t field, and location related flags into the -z field. In any case, we need to be able to specify whether the tag is required or a suggestion (as in should the request fail if the tag cannot be fulfilled) Vish On Feb 11, 2011, at 11:42 AM, Brian Schott 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 > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
