Open Stack

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.