Open Stack

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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>