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 is already reserved by AWS in their API, so we'll probably need to reserve it in ours as well or face future incompatibility.
I'm in favor of the 'openstack:' prefix for simplicity. I do agree that 'image type' could be one of these 'meaningful tags' also, except for legacy-compatibility reasons. Irrespective of the API, I think it's nice to think about things this way. Justin On Mon, Feb 28, 2011 at 3:49 PM, Brian Lamar <[email protected]>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 > *doing* something. > > I was under the (perhaps false) impression that metadata could be added by > end-users and was a way to describe associated data about an object which > didn't impact it's being. For example, we don't set the image type with > metadata, instances are created by providing an image type. Perhaps the two > aren't analogous because if "openstack:near" changes the instance would > migrate to another location? Or if "volume-000001" was moved, does the > instance move too? > > -Brian > > > > -----Original Message----- > From: "Justin Santa Barbara" <[email protected]> > Sent: Monday, February 28, 2011 6:28pm > To: [email protected] > Subject: Re: [Openstack] server affinity > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > Yes - the use case I'm working towards is to use metadata to specify > "openstack:near=volume-000001" 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 > metadata approach should be core OpenStack or not, but I figure I'll > contribute it and then we can debate exactly where we want to put it. > > I see this as complementary to Eric's proposal, which also makes sense to > me. Hopefully my code will be re-usable here also (or if Eric commits > first, hopefully I can use his!) > > Gabe: Can you give us more details on your use cases? Would my proposal > work for you? Would Eric's? Any caveats with either? > > Justin > > > > On Mon, Feb 28, 2011 at 3:01 PM, Vishvananda Ishaya > <[email protected]>wrote: > > > 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 chose a poor word there, this is actually referring to > > something smaller than the multicluster zones that Sandy has been working > > on. For example, in case for some performance reasons you wanted two > > servers with as few network hops as possible. If that still lines up > with > > what you are talking about, great. > > > > > > Sorry about that! > > > > > > Gabe > > > > > > On Monday, February 28, 2011 4:57pm, "Eric Day" <[email protected]> > > said: > > > > > >> 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. :) > > >> > > >> -Eric > > >> > > >> On Mon, Feb 28, 2011 at 04:48:25PM -0500, Gabe Westmaas wrote: > > >>> 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 get returned to you > > when you > > >>> create the server, and you can use that ID to add additional servers > in > > close > > >>> proximity to the first. > > >>> > > >>> What do you think? Is this useful enough outside Rackspace to be in > > core? > > >>> Alternatively, we can write it as an extension so as not to clutter > > core. > > >>> > > >>> Gabe > > >>> > > >>> > > >>> _______________________________________________ > > >>> Mailing list: https://launchpad.net/~openstack > > >>> Post to : [email protected] > > >>> Unsubscribe : https://launchpad.net/~openstack > > >>> More help : https://help.launchpad.net/ListHelp > > >> > > > > > > > > > > > > _______________________________________________ > > > Mailing list: https://launchpad.net/~openstack > > > Post to : [email protected] > > > Unsubscribe : https://launchpad.net/~openstack > > > More help : https://help.launchpad.net/ListHelp > > > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~openstack > > Post to : [email protected] > > Unsubscribe : https://launchpad.net/~openstack > > More help : https://help.launchpad.net/ListHelp > > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
