Open Stack

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:
>
>
>
> [snip]
>
>
>
>
>     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)?

cheers,
Zane.