Thanks Eric: +1, and I appreciate the peace-brokering :-)<div><br></div><div>I'm not wedded to the idea of putting "service metadata" into the same collection as "user metadata"; it just seems like a reasonable approach to me.  But it's more important to me that we agree on something, than that we agree on the "best" thing!</div>
<div><br></div><div>My votes:</div><div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">> Do we need to support variable service metadata?</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">+1  We saw a few people pop up on the list with their own use cases (e.g. GPUs) when I proposed this originally.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">> If so, where should it go?</span></div>
<div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div>
</div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">+1 for re-using the same "Metadata" collection, with an "openstack:" prefix.  Like it or not, we really have no choice but to reserve the "aws:" prefix, and to be compatible with anything AWS decides to use this for in future.<br>
<br>> If in a key/value list, should existing instance properties be moved into this format as well?</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br>
-1 (for now): We'd still have to support the separate properties for the front end APIs.  We'd probably not want to refactor the database schema.  However, the code can internally harmonize all the properties into a single collection, which might make routing & processing requests easier.  We could also support passing e.g. the instance types through the key/value collection instead of the 'legacy' explicit parameter method in the OpenStack API. However, I don't think we should change anything here yet, until we have a clear rationale for doing so.  (Though this rationale might arise quickly, e.g. multi-cluster-in-a-region)</span></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">> </span></font><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">If in a key/value list, should it just be a prefix in a general metadata list (and user metadata has a 'user' prefix)?</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">+1, but I don't think that we should require user metadata to be prefixed (at least externally!)  We should reserve the "aws:" and "openstack:" prefixes asap.  I'm going to propose a doc change to reserve the "aws:" prefix - I think we have no choice in the matter, and I haven't seen any objections.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font></div><div><div>Justin<br><br><br><br><br>
<br><br><div class="gmail_quote">On Wed, Mar 2, 2011 at 9:43 AM, Eric Day <span dir="ltr"><<a href="mailto:eday@oddments.org">eday@oddments.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Well said Jorge. I think we're all in agreement that we need a way<br>
to add both user-defined metadata and service-specific metadata (and<br>
possibly deployment-specific metadata). I think Justin was working<br>
on the metadata mechanisms assuming it would support both based on<br>
prefix. If we don't want to overload metadata and use prefixes to<br>
differentiate between users, providers, and so forth, we should add<br>
another collection to resources. For example:<br>
<br>
metadata = [<br>
  "user:comment": "This is Eric's dev server"<br>
  "openstack:affinity_id": "<a href="http://rack4.dc2.east.rackspace.com" target="_blank">rack4.dc2.east.rackspace.com</a>"]<br>
<br>
Would become:<br>
<br>
user_metadata = ["comment": "This is Eric's dev server"]<br>
service_metadata = ["openstack:affinity_id": "<a href="http://rack4.dc2.east.rackspace.com" target="_blank">rack4.dc2.east.rackspace.com</a>"]<br>
<br>
Or don't use metadata for service metadata at all and put directly<br>
in the instance object/record:<br>
<br>
<a href="http://instance.id" target="_blank">instance.id</a> = 100<br>
instance.network = 42<br>
instance.affinity_id = <a href="http://rack4.dc2.east.rackspace.com" target="_blank">rack4.dc2.east.rackspace.com</a><br>
# instance.metadata is user-defined metadata only.<br>
instance.metadata = ["comment": "This is Eric's dev server"]<br>
<br>
Now the arguments stated by many folks is that "service_metadata"<br>
is really instance properties or instance attributes and should<br>
instead be part of the instance object/record directly (like size,<br>
flavor id, etc. are). I don't disagree, but unfortunately there is<br>
a little more overhead since we're using a structured data store,<br>
and this requires an alter table for every change at this point. It's<br>
more difficult to introduce, test, and remove service attributes. If<br>
we want deployments to be able to define service-specific metadata<br>
and use that in pluggable schedulers, a DB schema change is not a<br>
very elegant way to support this.<br>
<br>
So the questions are:<br>
<br>
Do we need to support variable service metadata? If so, where should<br>
it go?<br>
<br>
If in a key/value list, should existing instance properties be moved<br>
into this format as well?<br>
<br>
If in a key/value list, should it just be a prefix in a general<br>
metadata list (and user metadata has a 'user' prefix)?<br>
<font color="#888888"><br>
-Eric<br>
</font><div><div></div><div class="h5"><br>
On Wed, Mar 02, 2011 at 08:59:09AM -0500, Mark Washenberger wrote:<br>
> > [W]e<br>
> > shouldn't be overloading that functionality by performing some action based on<br>
> > user-defined metadata.<br>
><br>
> That is exactly what I've been trying to say, but you have stated it much more succinctly. Thanks!<br>
><br>
> My specific concern is with quotas. If the current osapi metadata is overloaded with api functionality, then it muddies the concept of quotas. Admins who run nova probably don't want the server affinity feature to count against the general metadata quota.<br>

><br>
> Because of this, I don't think server affinity should be part of the metadata (specifically defined as the metadata attribute in nova.compute.api.API::create).<br>
><br>
> This doesn't really have any effect on which of Jorge's options we choose, though, so /unhijack.<br>
><br>
> "Jorge Williams" <<a href="mailto:jorge.williams@rackspace.com">jorge.williams@rackspace.com</a>> said:<br>
><br>
> > Metadata in the OpenStack Compute/Cloud Servers  API is meant to describe user<br>
> > defined properties.  That's it.  So in that case, I agree with Brian that we<br>
> > shouldn't be overloading that functionality by performing some action based on<br>
> > user-defined metadata.<br>
> ><br>
> > Speaking more generally though, any attribute that you associate with a resource<br>
> > can be thought of as metadata as well.  Isn't the name of an instance metadata<br>
> > about the instance?  Should operators be able to define arbitrary metadata and<br>
> > then be able to act on it in some way?  I think so, that's a very powerful<br>
> > feature. That said,  I would be cautious about exposing this as an arbitrary set<br>
> > of name value pairs because it provides a means by which you can bypass the<br>
> > contract and that will cause grief for our clients.  Additionally, there's the<br>
> > possibility of clashing metadata names between deployments.  The idea behind<br>
> > extensions is that you can define arbitrary metadata about a resource, while<br>
> > maintaining a contract and while avoiding conflicts with other<br>
> > operators/deployments/implementations.  I should note that the approach really<br>
> > isn't that different from AWS in that essentially as an operator you use a prefix<br>
> > to separate your metadata from customer metadata...the prefix is simply defined by<br>
> > the extension and  you can present your metadata in a separate attribute or<br>
> > element in the message.<br>
> ><br>
> > Given that, I'm still a little fuzzy about whether we've reached a decision as to<br>
> > whether affinity id:<br>
> ><br>
> > 1) Should be part of the core Compute API<br>
> > 2) Should be a more general concept that may span different services, as Eric Day<br>
> > proposes<br>
> > 3) Should be introduced as an extension, which can later be promoted to the<br>
> > core...or not :-)<br>
> ><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>
_______________________________________________<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>
</div></div></blockquote></div><br></div></div>