Le Fri, 20 May 2016 11:12:28 +0200, "Ulrich Windl" <ulrich.wi...@rz.uni-regensburg.de> a écrit :
> >>> Jehan-Guillaume de Rorthais <j...@dalibo.com> schrieb am 20.05.2016 um > 09:59 in > Nachricht <20160520095934.029c1822@firost>: > > Le Fri, 20 May 2016 08:39:42 +0200, > > "Ulrich Windl" <ulrich.wi...@rz.uni-regensburg.de> a écrit : > > > >> >>> Jehan-Guillaume de Rorthais <j...@dalibo.com> schrieb am 19.05.2016 um > >> >>> 21:29 in > >> Nachricht <20160519212947.6cc0fd7b@firost>: > >> [...] > >> > I was thinking of a use case where a graceful demote or stop action > failed > >> > multiple times and to give a chance to the RA to choose another method to > > >> > stop > >> > the resource before it requires a migration. As instance, PostgreSQL has > 3 > >> > different kind of stop, the last one being not graceful, but still better > > >> > than > >> > a kill -9. > >> > >> For example the Xen RA tries a clean shutdown with a timeout of about 2/3 > of > >> the timeout; it it fails it shuts the VM down the hard way. > > > > Reading the Xen RA, I see they added a shutdown timeout escalation > > parameter. > > Not quite: > if [ -n "$OCF_RESKEY_shutdown_timeout" ]; then > timeout=$OCF_RESKEY_shutdown_timeout > elif [ -n "$OCF_RESKEY_CRM_meta_timeout" ]; then > # Allow 2/3 of the action timeout for the orderly shutdown > # (The origin unit is ms, hence the conversion) > timeout=$((OCF_RESKEY_CRM_meta_timeout/1500)) > else > timeout=60 > fi > > > This is a reasonable solution, but isn't it possible to get the action > > timeout > > directly? I looked for such information in the past with no success. > > See above. Gosh, this is embarrassing...how could we miss that? Thank you for pointing this! _______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org