<meta http-equiv="content-type" content="text/html; charset=utf-8"><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">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.<div>
<br></div><div>I'm in favor of the 'openstack:' prefix for simplicity.<div><div><br><div>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.</div>
</div></div></div><div><br></div><div>Justin</div></span><br>
<br><br><div class="gmail_quote">On Mon, Feb 28, 2011 at 3:49 PM, Brian Lamar <span dir="ltr"><<a href="mailto:brian.lamar@rackspace.com">brian.lamar@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br>
<br>
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?<br>
<font color="#888888"><br>
-Brian<br>
</font><div><div></div><div class="h5"><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 a<br>
scheduler that will take that information and will assign you a machine e.g.<br>
in the same rack as the volume storage. It's unclear right now whether 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 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 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 request<br>
> placement<br>
> >>> in the same zone as another server. I am trying to figure out if 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 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>
</div></div></blockquote></div><br>