Having location-related flags in the -z field is fine with me. I believe the same ec2_api hack would work on -z. How about relational placement directives "pack them together" versus "spread them apart".
euca-run-instances -t "small;!local_gb=2048" -z "any;near_volume='v1234'" euca-run-instances -t "small;!local_gb=2048" -z "any;topolgy='cluster'" euca-run-instances -t "small;!local_gb=2048" -z "any;topolgy='spreadout'" I don't care about the syntax, but a ! flag or something to indicate "fail if not met"? The openstack api can be more elegant about it. Brian --- Brian Schott, Project Leader USC Information Sciences Institute http://www.east.isi.edu/~bschott ph: 703-812-3722 fx: 703-812-3712 On Feb 11, 2011, at 2:56 PM, Vishvananda Ishaya wrote: > 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
