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