On 09/03/15 23:47, Angus Salkeld wrote:
On Tue, Mar 10, 2015 at 8:53 AM, Adrian Otto <adrian.o...@rackspace.com
<mailto:adrian.o...@rackspace.com>> wrote:
Magnum Team,
In the following review, we have the start of a discussion about how
to tackle bay status:
https://review.openstack.org/159546
I think a key issue here is that we are not subscribing to an event
feed from Heat to tell us about each state transition, so we have a
low degree of confidence that our state will match the actual state
of the stack in real-time. At best, we have an eventually consistent
state for Bay following a bay creation.
Hi Adrian
Currently Heat does not an "event stream", but instead an event table
and REST resource. This sucks as you have to poll it.
We have been long wanting some integration with Zaqar - we are all
convinced, just needs someone to do the work.
So the idea here is we send user related events via a Zaqar queue and
the user (Magnum) subscribes and get events.
From last summit
https://etherpad.openstack.org/p/kilo-heat-summit-topics (see line 73).
+1
Here are some options for us to consider to solve this:
1) Propose enhancements to Heat (or learn about existing features)
to emit a set of notifications upon state changes to stack resources
so the state can be mirrored in the Bay resource.
See above, you have anyone to drive this?
2) Spawn a task to poll the Heat stack resource for state changes,
and express them in the Bay status, and allow that task to exit once
the stack reaches its terminal (completed) state.
3) Don’t store any state in the Bay object, and simply query the
heat stack for status as needed.
If it's not too frequent then this might be your best bet until we get "1)".
Hope this helps
-Angus
Are each of these options viable? Are there other options to
consider? What are the pro/con arguments for each?
Thanks,
Adrian
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
