Open Stack

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.lamar at 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" <justin at fathomdb.com>
> Sent: Monday, February 28, 2011 6:28pm
> To: openstack at lists.launchpad.net
> Subject: Re: [Openstack] server affinity
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at 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
> <vishvananda at 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" <eday at 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 at lists.launchpad.net
> > >>> Unsubscribe : https://launchpad.net/~openstack
> > >>> More help   : https://help.launchpad.net/ListHelp
> > >>
> > >
> > >
> > >
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~openstack
> > > Post to     : openstack at lists.launchpad.net
> > > Unsubscribe : https://launchpad.net/~openstack
> > > More help   : https://help.launchpad.net/ListHelp
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110228/094037aa/attachment.html>