Open Stack

On 08/04/15 18:03, Miguel Grinberg wrote:
> Here is where we disagree. In my opinion this is broken functionality.

It's not broken functionality, it's functionality that never existed. 
Spontaneous stack updates are just not part of the CloudFormation model, 
and they've never been a part of Heat at any point in the last 3+ years.

>         The ResourceGroup is an interesting resource. It is much simpler than
>         the ASG. In particular, the only way to scale the ResourceGroup is by
>         issuing a stack-update with a new size. This indirectly solves #1 and #2
>         above, because when a full update is issued any references to the
>         ResourceGroup get updated as well.
>
>
>     It doesn't really solve the problem, because you could still manually update the nested stack that the ResourceGroup manages. It just entirely lacks the feature that makes it easy to run in to the problem. And not in a good way.
>
>
> Not sure I understand this. You have a list of nested stacks, as many as the size property of the resource group dictates. You can update them and that's fine. I guess you can delete one and that is probably not fine, in the same way you can delete instances from the ASG pool without the ASG resource knowing, or actually modify or delete any native entities without the heat resource that owns it knowing. That still does not cancel the fact that if you play by the rules, the ResourceGroup is much more reliable than the ASG because it can only be updated in a stack-update operation.

There's one feature (alarm-based scaling) than doesn't work as well as 
you'd like. You always have the option of just not using it. It's very 
strange to see not having that feature at all be described as a virtue, 
as if it had _negative_ value.

If you want ASG to act like ResourceGroup, don't set up scaling policies 
for it. There is no step 2.

>     My vision for the second part has always been that we'd use hooks,
>     the initial implementation of which Tomas has landed in Kilo. We'll
>     need to implement some more hook types to do it - post-create,
>     post-update and pre-delete at a minimum. We also need some way of
>     notifying the user asynchronously about when the hooks are
>     triggered, so that they can take whatever action (e.g. add to load
>     balancer) before calling the API to clear the hook. (At the moment
>     the only way to find out when your hook should run is by polling the
>     Heat API.)
>
>
> I'm not really sure I understand how this would work. If I have a
> resource that sets one of its properties to { get_attr: [my_asg, size]
> }, then on a stack-update I don't need a hook to update my resource, it
> automatically updates. On an alarm triggered resize it will not, only
> because the update is partial in that case. If I add a post-update hook
> to that, then I may be able to get the resource to update on a resize
> event, but on a regular stack-update now the update will happen twice,
> once due to the normal update process, then again with the hook.

The hooks would not be set on the ASG resource; the ASG would set them 
on its individual members.

> To make this work I would have to not use get_attr, and somehow get this
> resource to obtain whatever attribute it needs from the ASG using some
> other way, like maybe the Heat API. Which is all fine, but get_attr is a
> valid option I have as a stack developer, and it is currently broken.

You wouldn't need to get it, it would fall automatically out of your 
hook code. Every time it gets called for post-create, you add the server 
it refers to to the load balancer and return from the hook. Every time 
it gets called for pre-delete, you remove the server from the load 
balancer and return from the hook. Then you always have the right 
servers in your load balancer.

> I know you disagree with my view, but in my opinion the problem, as I mentioned before, is that the resize event of the ASG does a partial update, which leaves the stack in an inconsistent state.

As I mentioned before, you're thinking of it wrong. The fact that ASG 
manages its members using a Heat stack is an implementation detail, in 
the same way that the fact that Trove manages its servers with Heat is. 
The ASG stack isn't a part of the parent stack. There is no 'partial' 
update of the parent stack - it's not being updated at all.

ASGs are just not special in this regard. Any resource could have its 
attributes change at any time for any number of reasons, and Heat is 
*never* notified and *never* triggers an update of the parent stack. 
That *is* a feature that is planned for Phase 2 of Convergence, but 
there is no way it is going to get merged in Kilo from a standing start 
after rc1 is already cut.

cheers,
Zane.