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