On Fri, Jan 09, 2015 at 04:07:51PM +1000, Angus Salkeld wrote: > On Fri, Jan 9, 2015 at 3:22 PM, Murugan, Visnusaran > <visnusaran.muru...@hp.com> wrote: > > Steve, > > A > > My reasoning to have a a**--continuea** like functionality was to run it > as a periodic task and substitute continuous observer for now. > > I am not in favor of the --continue as an API. I'd suggest responding to > resource timeouts and if there is no response from the task, then re-start > (continue) > the task.
I agree, the --continue API seems unnecessary. I realized however that my initial remarks were a little unfair, because if an engine dies, you can't necessarily restart the failed action via stack-update, because we're in an unknown state. So what would be useful is persisting sufficient per-resource state that the following workflow becomes possible: - User initiates stack-create - Engine handling the create dies or is killed/restarted - Another engine detects the failure and puts the stack into a FAILED state, or the user has to wait for a lock timeout which does that. - User can do heat stack-update to continue the failed create Obviously it'd be best long term if the user-visible restart could be handled automatically, but the above would be a good first step. Steve _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
