[openstack-dev] [Heat] Where to keep data about stack breakpoints?
tsedovic at redhat.com
Tue Jan 13 16:58:50 UTC 2015
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 and I put the "does this resource have a breakpoint" flag into
>>> the metadata of the resource:
>>> 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).
> 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
>>> 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
> 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.
>> For sublime end user confusion, we could use BROKEN. ;)
Haha, that's brilliant!
>>> OpenStack Development Mailing List (not for usage questions)
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev