[openstack-dev] [Heat] rough draft of Heat autoscaling API
zbitter at redhat.com
Wed Nov 20 20:07:14 UTC 2013
On 20/11/13 16:07, Christopher Armstrong wrote:
> On Tue, Nov 19, 2013 at 4:27 PM, Zane Bitter <zbitter at redhat.com
> <mailto:zbitter at redhat.com>> wrote:
> On 19/11/13 19:14, Christopher Armstrong wrote:
> There are a number of advantages to including the whole template,
> rather than a resource snippet:
> - Templates are versioned!
> - Templates accept parameters
> - Templates can provide outputs - we'll need these when we go to
> do notifications (e.g. to load balancers).
> The obvious downside is there's a lot of fiddly stuff to include in
> the template (hooking up the parameters and outputs), but this is
> almost entirely mitigated by the fact that the user can get a
> template, ready built with the server hooked up, from the API by
> hitting /resource_types/OS::Nova::__Server/template and just edit in
> the Volume and VolumeAttachment. (For a different example, they
> could of course begin with a different resource type - the launch
> config accepts any keys for parameters.) To the extent that this
> encourages people to write templates where the outputs are actually
> supplied, it will help reduce the number of people complaining their
> load balancers aren't forwarding any traffic because they didn't
> surface the IP addresses.
> My immediate reaction is to counter-propose just specifying an entire
> template instead of parameters and template separately, but I think the
As an API, I think that would be fine, though inconsistent between the
default (no template provided) and non-default cases. When it comes to
implementing Heat resources to represent those, however, it would make
the templates much less composable. If you wanted to reference anything
from the surrounding template (including parameters), you would have to
define the template inline and resolve references there. Whereas if you
can pass parameters, then you only need to include the template from a
separate file, or to reference a URL.
> crux will be this point you mentioned:
> - Templates can provide outputs - we'll need these when we go to do
> notifications (e.g. to load balancers).
> Can you explain this in a bit more depth? It seems like whatever it is
> may be the real deciding factor that means that your proposal can do
> something that a "resources" or a "template" parameter can't do. I
What I'm proposing _is_ a "template" parameter... I don't see any
difference. A "resources" parameter couldn't do this though, because the
resources section obviously doesn't contain outputs.
In any event, when we notify a Load Balancer, or _any_ type of thing
that needs a notification, we need to pass it some data. At the moment,
for load balancers, we pass the IDs of the servers (I originally thought
we passed IP addresses directly, hence possibly misleading comments
earlier). But our scaling unit is a template which may contain multiple
servers, or no servers. And the thing that gets notified may not even be
a load balancer. So there is no way to infer what the right data to send
is, we will need the user to tell us. The outputs section of the
template seems like a good mechanism to do it.
> thought we had a workable solution with the "LoadBalancerMember" idea,
> which you would use in a way somewhat similar to CinderVolumeAttachment
> in the above example, to hook servers up to load balancers.
I haven't seen this proposal at all. Do you have a link? How does it
handle the problem of wanting to notify an arbitrary service (i.e. not
necessarily a load balancer)?
More information about the OpenStack-dev