<div dir="ltr"><div class="gmail_extra"><div><br></div><div class="gmail_quote">Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
</div>Heat has been working hard to be able to do per-instance limited access<br>
in Keystone for a while. A trust might work just fine for what you want.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)">Are you hesitant to just use Heat? This is exactly what it is supposed</span><br></div>
to do.. make a bunch of API calls and expose the results to instances<br>
for use in configuration.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If you're just hesitant to use a declarative templating language, I<br>
totally understand. The auto-scaling minded people are also feeling<br>
this way. You could join them in the quest to create an imperative<br>
cluster-making API for Heat.<br></blockquote><div><br></div><div>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!<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5"><span style="color:rgb(34,34,34)">:) We are on the same page. I really think Heat is where higher level</span><br></div></div>
information sharing of this type belongs. I do think it might make sense<br>
for Heat to push things into user-data post-boot, rather than only expose<br>
them via its own metadata service. However, even without that, you can<br>
achieve what you're talking about right now with Heat's separate metadata.<br></blockquote><div>... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">

</div>N instances in one API call is something Heat does well, and it does<br>
auto scaling too, so I feel like your idea is mostly just asking for a<br>
simpler way to use Heat, which I think everyone would agree would be<br>
good for all Heat users. :)</blockquote><div><br></div><div>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:</div>
<div><ul><li>If we're on physical, the instance will use multicast & broadcast to find peers on the network.<br></li><li>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.<br>
</li><li>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.</li></ul></div><div>It gives me great pleasure that EC2 will end up needing the most undifferentiated lifting from the user.</div>
<div><br></div><div>Justin</div></div></div></div>