Open Stack

On Wed, Nov 20, 2013 at 2:07 PM, Zane Bitter <zbitter at redhat.com> wrote:

> 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.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131120/16608fae/attachment.html>