[openstack-dev] [Magnum][Heat] Expression of Bay Status

Zane Bitter zbitter at redhat.com
Tue Mar 10 13:29:03 UTC 2015


On 09/03/15 23:47, Angus Salkeld wrote:
> On Tue, Mar 10, 2015 at 8:53 AM, Adrian Otto <adrian.otto at rackspace.com
> <mailto:adrian.otto at 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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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
>




More information about the OpenStack-dev mailing list