On 12/01/15 13:05, Steven Hardy wrote:
>I also had a chat with Steve Hardy and he suggested adding a STOPPED state
>to the stack (this isn't in the spec). While not strictly necessary to
>implement the spec, this would help people figure out that the stack has
>reached a breakpoint instead of just waiting on a resource that takes a long
>time to finish (the heat-engine log and event-list still show that a
>breakpoint was reached but I'd like to have it in stack-list and
>resource-list, too).
>
>It makes more sense to me to call it PAUSED (we're not completely stopping
>the stack creation after all, just pausing it for a bit), I'll let Steve
>explain why that's not the right choice :-).
So, I've not got strong opinions on the name, it's more the workflow:
1. User triggers a stack create/update
2. Heat walks the graph, hits a breakpoint and stops.
3. Heat explicitly triggers continuation of the create/update
Did you mean the user rather than Heat for (3)?
My argument is that (3) is always a stack update, either a PUT or PATCH
update, e.g we_are_ completely stopping stack creation, then a user can
choose to re-start it (either with the same or a different definition).
Hmmm, ok that's interesting. I have not been thinking of it that way.
I've always thought of it like this:
http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/adding-lifecycle-hooks.html
(Incidentally, this suggests an implementation where the lifecycle hook
is actually a resource - with its own API, naturally.)
So, if it's requested, before each operation we send out a notification
(hopefully via Zaqar), and if a breakpoint is set that operation is not
carried out until the user makes an API call acknowledging it.
So, it_is_ really an end state, as a user might never choose to update
from the stopped state, in which case *_STOPPED makes more sense.
That makes a bit more sense now.
I think this is going to be really hard to implement though. Because
while one branch of the graph stops, other branches have to continue as
far as they can. At what point do you change the state of the stack?
Paused implies the same action as the PATCH update, only we trigger
continuation of the operation from the point we reached via some sort of
user signal.
If we actually pause an in-progress action via the scheduler, we'd have to
start worrying about stuff like token expiry, hitting timeouts, resilience
to engine restarts, etc, etc. So forcing an explicit update seems simpler
to me.
Yes, token expiry and stack timeouts are annoying things we'd have to
deal with. (Resilience to engine restarts is not affected though.)
However, I'm not sure your model is simpler, and in particular it sounds
much harder to implement in the convergence architecture.
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
