Open Stack

>
> 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" <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
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110228/30a02ffc/attachment.html>