<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Interesting, I guess I just don't see the point of introducing additional complexities for gain I don't yet see. </blockquote>
<div><br></div><div>We can defer discussion until the patch lands, when you can see the gains (or not!) :-)</div><div> </div><meta http-equiv="content-type" content="text/html; charset=utf-8"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br>
</blockquote><div><br></div><div>I agree - they should all be in the metadata area :-)  Sadly, AWS screwed that up.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

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.<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div>Justin</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
-----Original Message-----<br>
From: "Justin Santa Barbara" <<a href="mailto:justin@fathomdb.com">justin@fathomdb.com</a>><br>
</div><div><div></div><div class="h5">Sent: Monday, February 28, 2011 6:59pm<br>
To: "Brian Lamar" <<a href="mailto:brian.lamar@rackspace.com">brian.lamar@rackspace.com</a>><br>
Subject: Re: [Openstack] server affinity<br>
<br>
It's an open question whether 'meaningful tags' are treated as metadata with<br>
a system-reserved prefix (e.g. "openstack:"), or whether they end up in a<br>
separate area of the API.  The "aws:" prefix is already reserved by AWS in<br>
their API, so we'll probably need to reserve it in ours as well or face<br>
future incompatibility.<br>
<br>
I'm in favor of the 'openstack:' prefix for simplicity.<br>
<br>
I do agree that 'image type' could be one of these 'meaningful tags' also,<br>
except for legacy-compatibility reasons.  Irrespective of the API, I think<br>
it's nice to think about things this way.<br>
<br>
Justin<br>
<br>
<br>
<br>
On Mon, Feb 28, 2011 at 3:49 PM, Brian Lamar <<a href="mailto:brian.lamar@rackspace.com">brian.lamar@rackspace.com</a>>wrote:<br>
<br>
> Just because I can't help but asking, when does data specified during<br>
> instance creation stop being data and start being metadata? While it seems<br>
> like a silly question I'm wrestling with the idea of metadata actually<br>
> *doing* something.<br>
><br>
> I was under the (perhaps false) impression that metadata could be added by<br>
> end-users and was a way to describe associated data about an object which<br>
> didn't impact it's being. For example, we don't set the image type with<br>
> metadata, instances are created by providing an image type. Perhaps the two<br>
> aren't analogous because if "openstack:near" changes the instance would<br>
> migrate to another location? Or if "volume-000001" was moved, does the<br>
> instance move too?<br>
><br>
> -Brian<br>
><br>
><br>
><br>
> -----Original Message-----<br>
> From: "Justin Santa Barbara" <<a href="mailto:justin@fathomdb.com">justin@fathomdb.com</a>><br>
> Sent: Monday, February 28, 2011 6:28pm<br>
> To: <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> Subject: Re: [Openstack] server affinity<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>
> Yes - the use case I'm working towards is to use metadata to specify<br>
> "openstack:near=volume-000001" when creating a machine, and I will provide<br>
> a<br>
> scheduler that will take that information and will assign you a machine<br>
> e.g.<br>
> in the same rack as the volume storage.  It's unclear right now whether<br>
> this<br>
> metadata approach should be core OpenStack or not, but I figure I'll<br>
> contribute it and then we can debate exactly where we want to put it.<br>
><br>
> I see this as complementary to Eric's proposal, which also makes sense to<br>
> me.  Hopefully my code will be re-usable here also (or if Eric commits<br>
> first, hopefully I can use his!)<br>
><br>
> Gabe: Can you give us more details on your use cases?  Would my proposal<br>
> work for you?  Would Eric's?  Any caveats with either?<br>
><br>
> Justin<br>
><br>
><br>
><br>
> On Mon, Feb 28, 2011 at 3:01 PM, Vishvananda Ishaya<br>
> <<a href="mailto:vishvananda@gmail.com">vishvananda@gmail.com</a>>wrote:<br>
><br>
> > This seems to overlap heavily with justin's metadata stuff.  The idea was<br>
> > that you could pass in metadata on instance launch saying near:<br>
> > other-object.  I think that is far more useful than an opaque affinity<br>
> id.<br>
> ><br>
> > Vish<br>
> ><br>
> > On Feb 28, 2011, at 2:53 PM, Gabe Westmaas wrote:<br>
> ><br>
> > > Hi Eric,<br>
> > ><br>
> > > I probably chose a poor word there, this is actually referring to<br>
> > something smaller than the multicluster zones that Sandy has been working<br>
> > on.  For example, in case for some performance reasons you wanted two<br>
> > servers with as few network hops as possible.  If that still lines up<br>
> with<br>
> > what you are talking about, great.<br>
> > ><br>
> > > Sorry about that!<br>
> > ><br>
> > > Gabe<br>
> > ><br>
> > > On Monday, February 28, 2011 4:57pm, "Eric Day" <<a href="mailto:eday@oddments.org">eday@oddments.org</a>><br>
> > said:<br>
> > ><br>
> > >> Hi Gabe,<br>
> > >><br>
> > >> There has been a lot of discussion about this, along with zone naming,<br>
> > >> structure, and so forth. I was propsing we not only make it part of<br>
> > >> Nova, but suggest all projects use the same locality zone names/tags<br>
> > >> to ensure cross-project locality.<br>
> > >><br>
> > >> So, "yes", and don't make it nova-specific. :)<br>
> > >><br>
> > >> -Eric<br>
> > >><br>
> > >> On Mon, Feb 28, 2011 at 04:48:25PM -0500, Gabe Westmaas wrote:<br>
> > >>> Hey All,<br>
> > >>><br>
> > >>> For various reasons, Rackspace has a need to allow customers to<br>
> request<br>
> > placement<br>
> > >>> in the same zone as another server.  I am trying to figure out if<br>
> this<br>
> > is<br>
> > >>> generically useful, or something that should be outside of core.  The<br>
> > idea is<br>
> > >>> that if you don't specify an affinity ID one will get returned to you<br>
> > when you<br>
> > >>> create the server, and you can use that ID to add additional servers<br>
> in<br>
> > close<br>
> > >>> proximity to the first.<br>
> > >>><br>
> > >>> What do you think?  Is this useful enough outside Rackspace to be in<br>
> > core?<br>
> > >>> Alternatively, we can write it as an extension so as not to clutter<br>
> > core.<br>
> > >>><br>
> > >>> Gabe<br>
> > >>><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>
> > >><br>
> > ><br>
> > ><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>
> ><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>
> ><br>
><br>
><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>
><br>
<br>
<br>
</div></div></blockquote></div><br>