On Wed, Nov 20, 2013 at 2:07 PM, Zane Bitter <zbit...@redhat.com> wrote:
> 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. Yeah, that's a good point, but I could also imagine if you're *not* actually trying to dynamically parameterize the "flavor" and "image" in the above example, you wouldn't need to use parameters at all, so the example could get a bit shorter. (to diverge from the topic momentarily) I've been getting a little bit concerned about how we'll deal with templates-within-templates... It seems a *bit* unfortunate that users will be forced to use separate files for their scaled and outer templates, instead of having the option to specify them inline, but I can't think of a very satisfying way to solve that problem. Maybe an "escape" function that prevents heat from evaluating any of the function calls inside? > > 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. > > Hmm, okay. I still don't think I understand entirely how you expect outputs to be used, especially in context of the AS API. Can you give an example of how they would actually be used? I guess I don't yet understand all the implications of "notification" -- is that a new idea for icehouse? For what it's worth, I'm coming around to the idea of specifying the whole template in the API (or as a URI), but I'd still like to make sure I have a really good idea of the benefits it grants to justify the extra verbosity. > 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)? > > It's been described in the autoscaling wiki page for a while, and I thought the LBMember idea was discussed at the summit, but I wasn't there to verify that :) https://wiki.openstack.org/wiki/Heat/AutoScaling#LBMember.3F Basically, the LoadBalancerMember resource (which is very similar to the CinderVolumeAttachment) would be responsible for removing and adding IPs from/to the load balancer (which is actually a direct mapping to the way the various LB APIs work). Since this resource lives with the server resource inside the scaling unit, we don't really need to get anything _out_ of that stack, only pass _in_ the load balancer ID. Thanks, -- IRC: radix Christopher Armstrong Rackspace
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev