Open Stack

Excerpts from Monty Taylor's message of 2014-02-05 14:57:33 -0800:
> On 01/27/2014 11:02 AM, Day, Phil wrote:
> >> -----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
> >> want.
> >>>>
> >>>
> >>> 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
> >> services.
> >>>   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.
> 
> That sounds like an integration issue we should fix. (regardless of 
> whether it makes Justin's life any better) If we can't use heat in some 
> situations because neutron doesn't know how to securely proxy to its 
> metadata service ... that's kinda yuck.
> 

Indeed that is a known problem with Heat and one that has several
solutions. One simple solution is for Heat to simply update the nova
userdata, and for in-instance tools to just query ec2 metadata. The only
obstacle to that is that ec2 metadata is visible to non-privileged users
on the box without extra restrictions being applied.