Open Stack

Metadata in the OpenStack Compute/Cloud Servers  API is meant to describe user defined properties.  That's it.  So in that case, I agree with Brian that we shouldn't be overloading that functionality by performing some action based on user-defined metadata.

Speaking more generally though, any attribute that you associate with a resource can be thought of as metadata as well.  Isn't the name of an instance metadata about the instance?  Should operators be able to define arbitrary metadata and then be able to act on it in some way?  I think so, that's a very powerful feature. That said,  I would be cautious about exposing this as an arbitrary set of name value pairs because it provides a means by which you can bypass the contract and that will cause grief for our clients.  Additionally, there's the possibility of clashing metadata names between deployments.  The idea behind extensions is that you can define arbitrary metadata about a resource, while maintaining a contract and while avoiding conflicts with other operators/deployments/implementations.  I should note that the approach really isn't that different from AWS in that essentially as an operator you use a prefix to separate your metadata from customer metadata...the prefix is simply defined by the extension and  you can present your metadata in a separate attribute or element in the message.

Given that, I'm still a little fuzzy about whether we've reached a decision as to whether affinity id:

1) Should be part of the core Compute API
2) Should be a more general concept that may span different services, as Eric Day proposes 
3) Should be introduced as an extension, which can later be promoted to the core...or not :-)

As Erik Carlin noted, instances with the same affinity id will likely be placed in the same public subnet in Rackspace. Other operators may interpret affinity id differently. Is that concept general enough to be in the core?  I'd rather not introduce something in the core and then have to take it out.

-jOrGe W.


On Mar 1, 2011, at 11:26 AM, Mark Washenberger wrote:

> Are we using the name metadata to describe a different feature than the one that exists in the CloudServers api?
> 
> It seems like a different feature for the user-properties metadata to have meaning to the api other than "store this information so I can read it later".
> 
> "Justin Santa Barbara" <justin at fathomdb.com> said:
> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> We decided in the merge to call it Metadata, despite being fully aware of
>> the semantic issues, because that's what the CloudServers / OpenStack API
>> uses.
>> 
>> There are many better terms, but for the sake of avoiding a Tower of Babel,
>> let's just call it Metadata.
>> 
>> 
>> 
>> On Tue, Mar 1, 2011 at 6:56 AM, Sandy Walsh <sandy.walsh at rackspace.com>wrote:
>> 
>>> Was just speaking with dabo about this and we agree that metadata is a bad
>>> name for this capability.
>>> 
>>> I don't really care about what we call it, but metadata has some
>>> preconceived notions/meanings. Perhaps Criteria?
>>> 
>>> Currently we have *some* criteria for creating a new instance on the
>>> Openstack API side: flavors and operating system. But I think the OS API
>>> payload allows for additional "criteria" to be passed in with the request
>>> (not sure).
>>> 
>>> Eventually all this stuff will have to make it to the Scheduler for
>>> Server-Best-Match/Zone-Best-Match. That's somewhere on our task list for
>>> Cactus :/
>>> 
>>> $0.02
>>> 
>>> -S
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Confidentiality Notice: This e-mail message (including any attached or
>>> embedded documents) is intended for the exclusive and confidential use of
>>> the
>>> individual or entity to which this message is addressed, and unless
>>> otherwise
>>> expressly indicated, is confidential and privileged information of
>>> Rackspace.
>>> Any dissemination, distribution or copying of the enclosed material is
>>> prohibited.
>>> If you receive this transmission in error, please notify us immediately by
>>> e-mail
>>> at abuse at rackspace.com, and delete the original message.
>>> Your cooperation is appreciated.
>>> 
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack at lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp