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
I think these additional/optional request parameters (aka metadata) should just
be part of the context that is created when a command is issued and passed
around for all services to use as needed.
So I guess that would be a vote for #2
-S
From: Jorge
[W]e
shouldn't be overloading that functionality by performing some action based on
user-defined metadata.
That is exactly what I've been trying to say, but you have stated it much more
succinctly. Thanks!
My specific concern is with quotas. If the current osapi metadata is overloaded
with
Well said Jorge. I think we're all in agreement that we need a way
to add both user-defined metadata and service-specific metadata (and
possibly deployment-specific metadata). I think Justin was working
on the metadata mechanisms assuming it would support both based on
prefix. If we don't want to
Thanks Eric: +1, and I appreciate the peace-brokering :-)
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
, March 2, 2011 12:43pm
To: Mark Washenberger mark.washenber...@rackspace.com
Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net
Subject: Re: [Openstack] server affinity
Well said Jorge. I think we're all in agreement that we need a way
to add both user-defined metadata
On Wed, Mar 02, 2011 at 10:27:33AM -0800, Justin Santa Barbara wrote:
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
On Mar 2, 2011, at 11:43 AM, Eric Day wrote:
Now the arguments stated by many folks is that service_metadata
is really instance properties or instance attributes and should
instead be part of the instance object/record directly (like size,
flavor id, etc. are). I don't disagree, but
On Mar 2, 2011, at 3:54 PM, Eric Day wrote:
On Wed, Mar 02, 2011 at 09:48:27PM +, Jorge Williams wrote:
On Mar 2, 2011, at 11:43 AM, Eric Day wrote:
Now the arguments stated by many folks is that service_metadata
is really instance properties or instance attributes and should
instead be
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
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,
Hey All,
For various reasons, Rackspace has a need to allow customers to request
placement in the same zone as another server. I am trying to figure out if
this is generically useful, or something that should be outside of core. The
idea is that if you don't specify an affinity ID one will
Hi Gabe,
There has been a lot of discussion about this, along with zone naming,
structure, and so forth. I was propsing we not only make it part of
Nova, but suggest all projects use the same locality zone names/tags
to ensure cross-project locality.
So, yes, and don't make it nova-specific. :)
This seems to overlap heavily with justin's metadata stuff. The idea was that
you could pass in metadata on instance launch saying near: other-object. I
think that is far more useful than an opaque affinity id.
Vish
On Feb 28, 2011, at 2:53 PM, Gabe Westmaas wrote:
Hi Eric,
I probably
Yes - the use case I'm working towards is to use metadata to specify
openstack:near=volume-01 when creating a machine, and I will provide a
scheduler that will take that information and will assign you a machine e.g.
in the same rack as the volume storage. It's unclear right now whether this
Yup, Sandy's zone stuff, Justin's metadata stuff, and this is all
pretty much the same (or at least very closely related). First off,
lets move away from the term zone and define location as an arbitrary
grouping of one or more resources, not the traditional availability
zones. Thinking in terms
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] server affinity
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net
, February 28, 2011 6:59pm
To: Brian Lamar brian.la...@rackspace.com
Subject: Re: [Openstack] server affinity
It's an open question whether 'meaningful tags' are treated as metadata with
a system-reserved prefix (e.g. openstack:), or whether they end up in a
separate area of the API. The aws: prefix
Sent: Monday, February 28, 2011 6:28pm
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] server affinity
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net
On Mon, Feb 28, 2011 at 6:49 PM, Brian Lamar brian.la...@rackspace.com wrote:
Just because I can't help but asking, when does data specified during
instance creation stop being data and start being metadata? While it seems
like a silly question I'm wrestling with the idea of metadata actually
On Mon, Feb 28, 2011 at 10:45 PM, Jay Pipes jaypi...@gmail.com wrote:
for those of a like-minded curiosity about these things. From the
wikipedia article on this same subject:
The term Metadata is an ambiguous term which is used for two
fundamentally different concepts (Types). Although a
This is great stuff. It sounds like there is a real distinction to be made
between the data central to the apis and the user-defined properties. Also, as
time and compatibility allow, we should probably change what we were calling
metadata to be called properties or somesuch.
Jay Pipes
22 matches
Mail list logo
