On 01/12/2015 07:05 PM, Steven Hardy wrote:
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
Ooh, I forgot about resource_data! That sounds perfect, actually.
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).
I think we have two orthogonal questions here:
1. How do end users set up and clear breakpoints
2. How does the engine stores breakpoint-related data
As per the spec (and it makes perfect sense to me), users will declare
breakpoints via the environment and through CLI (which as you say can be
translated to the environment).
But we ran then read that and just store "has_breakpoint" in each
resource's data.
The spec does mention breakpoints on nested stacks briefly:
> For nested stack, the breakpoint would be prefixed with
> the name of the nested template.
I'm assuming we'll need some sort of separator, but the general idea
sounds okay to me. Something like this, perhaps:
nested_stack/nested_template.yaml/SomeResource
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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
