> > Interesting, I guess I just don't see the point of introducing additional > complexities for gain I don't yet see.
We can defer discussion until the patch lands, when you can see the gains (or not!) :-) > My example about 'image type' was meant to act as a deterrent against using > metadata for "OpenStack meaningful" values. Instances, in my opinion, > should be created explicitly with properties such as name, image type, size, > affinity group, etc. because all of this data is of the same fiber...that is > to say unless there is an explicit functional difference between how the > properties behave, they should be defined in the same place. > I agree - they should all be in the metadata area :-) Sadly, AWS screwed that up. > Is this the sort of data that is stored in AWS's instance metadata? I > haven't extensively used their service so I'm not familiar with how they > distinguish between the function of a property defined at creation and > metadata ("aws:") properties. > I don't know how/whether AWS actually uses their reserved prefix publicly at the moment (?). However, we have no choice but to reserve the "aws:" prefix or be incompatible down the road. And if "aws" has a prefix in our API, probably "openstack" shouldn't be the only API without a prefix, otherwise it would be unhAPI. Justin > -----Original Message----- > From: "Justin Santa Barbara" <jus...@fathomdb.com> > Sent: Monday, 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 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 <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 > > *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" <jus...@fathomdb.com> > > 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/~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 > > <vishvana...@gmail.com>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" <e...@oddments.org> > > > 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 : openstack@lists.launchpad.net > > > >>> Unsubscribe : https://launchpad.net/~openstack > > > >>> More help : https://help.launchpad.net/ListHelp > > > >> > > > > > > > > > > > > > > > > _______________________________________________ > > > > Mailing list: https://launchpad.net/~openstack > > > > Post to : openstack@lists.launchpad.net > > > > Unsubscribe : https://launchpad.net/~openstack > > > > More help : https://help.launchpad.net/ListHelp > > > > > > > > > _______________________________________________ > > > Mailing list: https://launchpad.net/~openstack > > > Post to : openstack@lists.launchpad.net > > > Unsubscribe : https://launchpad.net/~openstack > > > More help : https://help.launchpad.net/ListHelp > > > > > > > > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~openstack > > Post to : openstack@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~openstack > > More help : https://help.launchpad.net/ListHelp > > > > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp