[openstack-dev] [Heat] Where to keep data about stack breakpoints?
zbitter at redhat.com
Mon Jan 12 21:36:16 UTC 2015
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)?
>> 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
> For sublime end user confusion, we could use BROKEN. ;)
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev