Thanks Brian - that's a great suggestion for how to get round the limitations of the EC2 API.  I've added it to the wiki page for the blueprint:<div><span class="Apple-style-span" style="font-family: sans-serif; font-size: 14px; color: rgb(83, 83, 83); line-height: 18px; "><i>We could also stuff this information into another supported field; for example instance-type (e.g. euca-run-instance --instance-type m1.small;openstack:near=volume-000001)</i></span></div>
<div><font class="Apple-style-span" color="#535353" face="sans-serif"><span class="Apple-style-span" style="font-size: 14px; line-height: 18px;"><br clear="all"></span></font>Justin<br><br><br><br>
<br><br><div class="gmail_quote">On Thu, Feb 10, 2011 at 4:21 PM, Brian Schott <span dir="ltr"><<a href="mailto:bfschott@gmail.com">bfschott@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Justin,<br>
<br>
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.<br>

<font color="#888888"><br>
Brian Schott<br>
<a href="mailto:bfschott@gmail.com">bfschott@gmail.com</a><br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
On Feb 10, 2011, at 4:37 PM, Justin Santa Barbara wrote:<br>
<br>
> Does anyone have any thoughts/objections on the blueprint I posted for allowing clients to pass capability-requests through tags?  I'm planning on starting implementation soon, so if people think this is a bad idea I'd rather know before I start coding!<br>

><br>
> Blueprint: <a href="https://blueprints.launchpad.net/nova/+spec/use-metadata-tags-for-capabilities" target="_blank">https://blueprints.launchpad.net/nova/+spec/use-metadata-tags-for-capabilities</a><br>
> Wiki: <a href="https://blueprints.launchpad.net/nova/+spec/use-metadata-tags-for-capabilities" target="_blank">https://blueprints.launchpad.net/nova/+spec/use-metadata-tags-for-capabilities</a><br>
><br>
> And a quick TLDR:<br>
> API clients need a way to request e.g. placement of machines near each other / near volumes, or that a volume be created with a particular RAID level, or that a machine be created in a HIPAA compliant environment.  (This is complementary to the work on hierarchical zones & URL naming, I believe)<br>

><br>
> I propose using the instance tags for this, e.g. specifying openstack:near=vol-000001 when creating an instance to request locating the instance 'close to' that volume.<br>
><br>
> By default these requests would be best-effort and ignored-if-unknown; if the client wants to specify that something is required and should fail if not understood or not satisfiable, they could use a "+" e.g. openstack:+location=*.<a href="http://dc1.north.rackspace.com" target="_blank">dc1.north.rackspace.com</a><br>

><br>
> Controversially (?), this would not be supported for clients using the AWS API, because tags can only be specified once the instance has already been created.<br>
><br>
><br>
> Feedback appreciated!<br>
><br>
> Justin<br>
><br>
><br>
><br>
</div></div><div><div></div><div class="h5">> _______________________________________________<br>
> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br>
</div></div></blockquote></div><br></div>