[openstack-dev] [Nova] bp proposal: discovery of peer instances through metadata service
philip.day at hp.com
Mon Jan 27 11:02:17 UTC 2014
> -----Original Message-----
> From: Clint Byrum [mailto:clint at fewbar.com]
> Sent: 24 January 2014 21:09
> To: openstack-dev
> Subject: Re: [openstack-dev] [Nova] bp proposal: discovery of peer instances
> through metadata service
> Excerpts from Justin Santa Barbara's message of 2014-01-24 12:29:49 -0800:
> > Clint Byrum <clint at fewbar.com> wrote:
> > >
> > > Heat has been working hard to be able to do per-instance limited
> > > access in Keystone for a while. A trust might work just fine for what you
> > >
> > I wasn't actually aware of the progress on trusts. It would be
> > helpful except (1) it is more work to have to create a separate trust
> > (it is even more painful to do so with IAM) and (2) it doesn't look
> > like we can yet lock-down these delegations as much as people would
> > probably want. I think IAM is the end-game in terms of the model that
> > people actually want, and it ends up being incredibly complex.
> > Delegation is very useful (particularly because clusters could
> > auto-scale themselves), but I'd love to get an easier solution for the
> > peer discovery problem than where delegation ends up.
> > Are you hesitant to just use Heat? This is exactly what it is supposed
> > > to do.. make a bunch of API calls and expose the results to
> > > instances for use in configuration.
> > > If you're just hesitant to use a declarative templating language, I
> > > totally understand. The auto-scaling minded people are also feeling
> > > this way. You could join them in the quest to create an imperative
> > > cluster-making API for Heat.
> > >
> > I don't want to _depend_ on Heat. My hope is that we can just launch
> > 3 instances with the Cassandra image, and get a Cassandra cluster. It
> > might be that we want Heat to auto-scale that cluster, Ceilometer to
> > figure out when to scale it, Neutron to isolate it, etc but I think we
> > can solve the basic discovery problem cleanly without tying in all the other
> > Heat's value-add doesn't come from solving this problem!
> I suppose we disagree on this fundamental point then.
> Heat's value-add really does come from solving this exact problem. It
> provides a layer above all of the other services to facilitate expression of
> higher level concepts. Nova exposes a primitive API, where as Heat is meant
> to have a more logical expression of the user's intentions. That includes
> exposure of details of one resource to another (not just compute, swift
> containers, load balancers, volumes, images, etc).
The main problem I see with using heat is that seems to depend on all instances having network access to the heat server, and I'm not sure how that would work for Neutron VPN network. This is already solved for the Metadata server because the Neturon proxy already provides secure access.
More information about the OpenStack-dev