Steve, My reasoning to have a “--continue” like functionality was to run it as a periodic task and substitute continuous observer for now.
“--continue” based command should work on realized vs. actual graph and issue a stack update. I completely agree that user action should not be needed to realize a partially completed stack. Your thoughts. From: vishnu [mailto:ckmvis...@gmail.com] Sent: Friday, January 9, 2015 10:08 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Heat] Precursor to Phase 1 Convergence Steve, Auto recovery is the plan. Engine failure should be detected by way of heartbeat or recover partially realised stack on engine startup in case of a single engine scenario. "--continue" command was just a additional helper api. [http://d13pix9kaak6wt.cloudfront.net/signature/me-badge.png] Visnusaran Murugan about.me/ckmvishnu On Thu, Jan 8, 2015 at 11:29 PM, Steven Hardy <sha...@redhat.com<mailto:sha...@redhat.com>> wrote: On Thu, Jan 08, 2015 at 09:53:02PM +0530, vishnu wrote: > Hi Zane, > I was wondering if we could push changes relating to backup stack removal > and to not load resources as part of stack. There needs to be a capability > to restart jobs left over by dead engines.A > something like heat stack-operation --continue [git rebase --continue] To me, it's pointless if the user has to restart the operation, they can do that already, e.g by triggering a stack update after a failed stack create. The process needs to be automatic IMO, if one engine dies, another engine should detect that it needs to steal the lock or whatever and continue whatever was in-progress. > Had a chat with shady regarding this. IMO this would be a valuable > enhancement. Notification based lead sharing can be taken up upon > completion. I was referring to a capability for the service to transparently recover if, for example, a heat-engine is restarted during a service upgrade. Currently, users will be impacted in this situation, and making them manually restart failed operations doesn't seem like a super-great solution to me (like I said, they can already do that to some extent) Steve _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
