2015-03-10 23:21 GMT+08:00 Hongbin Lu <[email protected]>: > Hi Adrian, > > On Mon, Mar 9, 2015 at 6:53 PM, Adrian Otto <[email protected]> > 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. >> >> 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. >> > > A drawback of this option is that it increases the difficulty of > trouble-shooting. In my experience of using Heat (SoftwareDeployments in > particular), Ironic and Trove, one of the most frequent errors I > encountered is that the provisioning resources stayed in deploying state > (never went to completed). The reason is that they were waiting a callback > signal from the provisioning resource to indicate its completion, but the > callback signal was blocked due to various reasons (e.g. incorrect firewall > rules, incorrect configs, etc.). Troubling-shooting such problem is > generally harder. > I think that the "heat convergence" is working on the issues for your concern: https://wiki.openstack.org/wiki/Heat/Blueprints/Convergence
> > >> >> 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. > > >> 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: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Thanks, Jay Lau (Guangya Liu)
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
