[openstack-dev] 答复: [Heat] Precursor to Phase 1 Convergence

Huangtianhua huangtianhua at huawei.com
Fri Jan 9 06:30:10 UTC 2015



发件人: Angus Salkeld [mailto:asalkeld at mirantis.com]
发送时间: 2015年1月9日 14:08
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [Heat] Precursor to Phase 1 Convergence


On Fri, Jan 9, 2015 at 3:22 PM, Murugan, Visnusaran <visnusaran.murugan at hp.com<mailto:visnusaran.murugan at hp.com>> wrote:
Steve,

My reasoning to have a “--continue” 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.

-Angus


+1 Agree with Angus:)

“--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:ckmvishnu at gmail.com<mailto:ckmvishnu at 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.








[图像已被发件人删除。]



Visnusaran Murugan
about.me/ckmvishnu<http://about.me/ckmvishnu>









On Thu, Jan 8, 2015 at 11:29 PM, Steven Hardy <shardy at redhat.com<mailto:shardy at 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 at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150109/58bc6d8d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 359 bytes
Desc: image001.jpg
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150109/58bc6d8d/attachment.jpg>


More information about the OpenStack-dev mailing list