Open Stack

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).

> :) We are on the same page. I really think Heat is where higher level
> > information sharing of this type belongs. I do think it might make sense
> > for Heat to push things into user-data post-boot, rather than only expose
> > them via its own metadata service. However, even without that, you can
> > achieve what you're talking about right now with Heat's separate metadata.
> >
> ...
> 
> > N instances in one API call is something Heat does well, and it does
> > auto scaling too, so I feel like your idea is mostly just asking for a
> > simpler way to use Heat, which I think everyone would agree would be
> > good for all Heat users. :)
> 
> 
> I have a personal design goal of solving the discovery problem in a way
> that works even on non-clouds.  So I can write a clustered service, and it
> will run everywhere.  The way I see it is that:
> 
>    - If we're on physical, the instance will use multicast & broadcast to
>    find peers on the network.
>    - If we're on OpenStack, the instance will use this blueprint to find
>    its peers.  The instance may be launched through Nova, or Heat, or
>    Puppet/Chef/Salt/etc.  I would like to see people use Heat, but I don't
>    want to force people to use Heat.  If Heat starts putting a more accurate
>    list of peers into metadata, I will check that first.  But if I can't find
>    that list of peers that Heat provides, I will fall-back to whatever I can
>    get from Nova so that I can cope with people not on Heat.
>    - If we're on EC2, the user must configure an IAM role and assign it to
>    their instances, and then we will query the list of instances.
> 
> It gives me great pleasure that EC2 will end up needing the most
> undifferentiated lifting from the user.
> 

Heat is meant to be a facility for exactly what you want. If you don't
want to ask people to use it, you're just duplicating Heat functionality
in Nova. Using Heat means no query/filter for the instances you want:
you have the exact addresses in your cluster.

My suggestion would be that if you want to hide all of the complexity
of Heat from users, you add a simplified API to Heat that enables your
use case. In many ways that is exactly what Savanna, Trove, et.al are:
domain specific cluster API's backed by orchestration.