<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 20, 2013 at 2:07 PM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 20/11/13 16:07, Christopher Armstrong wrote:<br>

</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
On Tue, Nov 19, 2013 at 4:27 PM, Zane Bitter <<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a><br></div><div class="im">
<mailto:<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>>> wrote:<br>
<br>
    On 19/11/13 19:14, Christopher Armstrong wrote:<br>
<br>
<br>
<br>
[snip]<br>
<br>
<br>
<br>
<br></div><div class="im">
    There are a number of advantages to including the whole template,<br>
    rather than a resource snippet:<br>
      - Templates are versioned!<br>
      - Templates accept parameters<br>
      - Templates can provide outputs - we'll need these when we go to<br>
    do notifications (e.g. to load balancers).<br>
<br>
    The obvious downside is there's a lot of fiddly stuff to include in<br>
    the template (hooking up the parameters and outputs), but this is<br>
    almost entirely mitigated by the fact that the user can get a<br>
    template, ready built with the server hooked up, from the API by<br></div>
    hitting /resource_types/OS::Nova::__<u></u>Server/template and just edit in<div class="im"><br>
    the Volume and VolumeAttachment. (For a different example, they<br>
    could of course begin with a different resource type - the launch<br>
    config accepts any keys for parameters.) To the extent that this<br>
    encourages people to write templates where the outputs are actually<br>
    supplied, it will help reduce the number of people complaining their<br>
    load balancers aren't forwarding any traffic because they didn't<br>
    surface the IP addresses.<br>
<br>
<br>
<br>
My immediate reaction is to counter-propose just specifying an entire<br>
template instead of parameters and template separately, but I think the<br>
</div></blockquote>
<br>
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.</blockquote>
<div><br></div><div>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.</div>
<div><br></div><div>(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?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
crux will be this point you mentioned:<br>
<br>
  - Templates can provide outputs - we'll need these when we go to do<br>
notifications (e.g. to load balancers).<br>
<br>
Can you explain this in a bit more depth? It seems like whatever it is<br>
may be the real deciding factor that means that your proposal can do<br>
something that a "resources" or a "template" parameter can't do.  I<br>
</blockquote>
<br></div>
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.<br>

<br>
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.<div class="im">
<br></div></blockquote><div><br></div><div>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?</div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
thought we had a workable solution with the "LoadBalancerMember" idea,<br>
which you would use in a way somewhat similar to CinderVolumeAttachment<br>
in the above example, to hook servers up to load balancers.<br>
</blockquote>
<br></div>
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)?<div class=""><div class="h5"><br></div></div></blockquote>
<div><br></div><div>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 :) </div><div><br></div><div><a href="https://wiki.openstack.org/wiki/Heat/AutoScaling#LBMember.3F">https://wiki.openstack.org/wiki/Heat/AutoScaling#LBMember.3F</a><br>
</div><div><br></div><div>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.</div>
<div><br></div><div>Thanks,</div></div><div><br></div>-- <br><div dir="ltr"><div>IRC: radix</div>Christopher Armstrong<div>Rackspace</div></div>
</div></div>