On 20/11/13 16:07, Christopher Armstrong wrote:
On Tue, Nov 19, 2013 at 4:27 PM, Zane Bitter <zbit...@redhat.com <mailto:zbit...@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
