[Openstack] server affinity

Brian Lamar brian.lamar at rackspace.com
Mon Feb 28 23:49:25 UTC 2011


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
>






More information about the Openstack mailing list