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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
