How does failover happen in multi-steps firewall upgrade using cdt?

[checkmate-Go]

Hi all,

I have tried installing blink_image R82 Take 44 using SmartConsole CDT in my lab environment and it was successful and pretty fast. I went from R81.20 to R82 recommended JH version. 

In our prod environment, we have always used CPUSE method to apply a hotfix or a version upgrade which feels slow to me, even though we will still use that method depending on few other factors, however there are internal firewalls with low-risk that I would like to do some testing on.
Usually with CPUSE method, we go to R82.10 base version and apply hotfix on top of that. This time, I am planning to use blink image to go from R82 to R82.10 JH T45 from smartconsole using CDT and rely on it for automatic fail-over.  I have following questions:

-How does that fail-over take place? Is it running Clusterxl_admin down behind the scene or cpstop?

-How reliable is a combination of blink  image, CDT and auto-failover?

-What are the ramifications that I should be prepared for?

I would appreciate any response, Thanks!

[Bob_Zimmerman]

It does a clusterXL_admin down. You can see it in the 'cphaprob show_failover' after an update or upgrade.

I've personally been advised against using Blink for most of my company's upgrades at this time. Not sure why, and it may be something specific to our environment. We typically use CDT in SmartConsole to upgrade to the base version of a release (with one failover), then to install the jumbo (with a second failover).

Lately, updating in general has been failing for us in weird ways. We've been given a 'confp_failure_fixer.sh' script which sometimes works, but sometimes we need to revert the firewall to a snapshot before it works fully (it's possible the improvement is actually from the reboot rather than from reverting). I'm told updates to CPUSE and a few other things are on the way to address the issue.