Open Stack

On Mon, Jan 12, 2015 at 04:29:15PM +0100, Tomas Sedovic wrote:
> Hey folks,
> 
> I did a quick proof of concept for a part of the Stack Breakpoint spec[1]
> and I put the "does this resource have a breakpoint" flag into the metadata
> of the resource:
> 
> https://review.openstack.org/#/c/146123/
> 
> I'm not sure where this info really belongs, though. It does sound like
> metadata to me (plus we don't have to change the database schema that way),
> but can we use it for breakpoints etc., too? Or is metadata strictly for
> Heat users and not for engine-specific stuff?

Metadata is supposed to be for template defined metadata (with the notable
exception of server resources where we merge SoftwareDeployment metadata in
to that defined in the template).

So if we're going to use the metadata template interface as a way to define
the breakpoint, this is OK, but do we want to mix the definition of the
stack with this flow control data? (I personally think probably not).

I can think of a couple of alternatives:

1. Use resource_data, which is intended for per-resource internal data, and
set it based on API data passed on create/update (see Resource.data_set)

2. Store the breakpoint metadata in the environment

I think the environment may be the best option, but we'll have to work out
how to best represent a tree of nested stacks (something the spec interface
description doesn't consider AFAICS).

If we use the environment, then no additional API interfaces are needed,
just supporting a new key in the existing data, and python-heatclient can
take care of translating any CLI --breakpoint argument into environment
data.

> 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

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

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.

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.

Steve