Open Stack

On 27/04/15 13:38, Steven Hardy wrote:
> On Mon, Apr 27, 2015 at 04:46:20PM +0100, Steven Hardy wrote:
>> AFAICT there's two options:
>>
>> 1. Update the stack.Stack so we store "now" at every transition (e.g in
>> state_set)
>>
>> 2. Stop trying to explicitly control updated_at, and just allow the oslo
>> TimestampMixin to do it's job and update updated_at every time the DB model
>> is updated.
>
> Ok, at the risk of answering my own question, there's a third option, which
> is to output an event for all stack transitions, not only resource
> transitions.  This appears to be the way the CFN event API works AFAICS.

My recollection was that in CFN events were always about a particular 
resource. That may have been wrong, or they may have changed it. In any 
event (uh, no pun intended), I think this option is preferable to 
options 1 & 2.

When we first implemented this stuff we only operated on one resource at 
a time, there was no way to cancel an update, &c. It was a simpler world ;)

> I guess the event would have a dummy OS::Heat::Stack type and then you

That's too hacky IMHO, I think we should have a more solid way of 
distinguishing resource events from stack events. OS::Heat::Stack is a 
type of resource already, after all. Arguably they should come from 
separate endpoints, to avoid breaking clients until we get to a v2 API.

> could find the most recent transition to e.g UPDATE_IN_PROGRESS in the
> events and use that as a marker so you only list results after that event?

Even that is not valid in a distributed system. For convergence we're 
planning to have a UUID associated with each update. We should reuse 
that to connect events with particular update traversals.

cheers,
Zane.