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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
