Excerpts from Justin Santa Barbara's message of 2014-01-24 12:29:49 -0800: > Clint Byrum <cl...@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev