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! :) 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. Justin
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev