On 01/12/2015 10:36 PM, Zane Bitter wrote:
On 12/01/15 10:49, Ryan Brown wrote:
On 01/12/2015 10:29 AM, 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?
I'd rather not store it in metadata so we don't mix user metadata with
implementation-specific-and-also-subject-to-change runtime metadata. I
think this is a big enough feature to warrant a schema update (and I
can't think of another place I'd want to put the breakpoint info).
+1
I'm actually not convinced it should be in the template at all. Steve's
suggestion of putting it the environment might be a good one, or maybe
it should even just be an extra parameter to the stack create/update
APIs (like e.g. the timeout is)?
Absolutely. I've used metadata as the fastest way to play with breakpoints.
The spec talks about setting breakpoints via environment and via `heat
stack-create --breakpoint MyResource`. And that absolutely makes sense
to me.
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 :-).
+1 to PAUSED. To me, STOPPED implies an end state (which a breakpoint is
not).
I agree we need an easy way for the user to see why nothing is
happening, but adding additional states to the stack is a pretty
dangerous change that risks creating regressions all over the place. If
we can find _any_ other way to surface the information, it would be
preferable IMHO.
Would adding a new state to resources be similarly tricky, or could we
do that instead? That way you'd see what's going on in `resource-list`
which is should be good enough.
The patch is already emitting an event saying that a breakpoint has been
reached so we're not completely silent on this. But when debugging a
stack, I always look at resource-list first since it's easier to read
and only if I need the timing info do I reach for event-list.
Dunno how representative that is.
cheers,
Zane.
For sublime end user confusion, we could use BROKEN. ;)
Haha, that's brilliant!
Tomas
[1]:
http://specs.openstack.org/openstack/heat-specs/specs/juno/stack-breakpoint.html
__________________________________________________________________________
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
__________________________________________________________________________
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
