openstack team mailing list archive

[Brian Schott <bschott@xxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>