Open Stack

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

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

cheers,
Zane.

> For sublime end user confusion, we could use BROKEN. ;)
>
>> 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-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>