Open Stack

Interesting, I guess I just don't see the point of introducing additional complexities for gain I don't yet see. 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.

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.

Brian

-----Original Message-----
From: "Justin Santa Barbara" <justin at fathomdb.com>
Sent: Monday, February 28, 2011 6:59pm
To: "Brian Lamar" <brian.lamar at 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.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
>