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

Reply via email to