Hi Guys,

  We need some consensus here to move tickets 2144 and 2145 forward.

  Here is my understanding of the AMF and SMF specs and current
implementations regarding rolling upgrade with reboot. Please correct me
if I am wrong. This mostly affects rollback and undo.

  I believe the SMF spec intends the behavior to be as follows for
rolling upgrade with reboot (see 3.3.2.1 and 3.3.2.2):

(1) AMF lock of node
(2) AMF lock-in of node
(3) reboot node
(3a) this reboot should not generate any DISABLED state transitions for
any SUs as long as the components are properly terminated, otherwise the
campaign goes into error detected state
(4) AMF unlock-in of node
(5) AMF unlock of node

  Can you point me to the place in the AMF spec where it says that a
node must become disabled when it reboots? I can't seem to find it. The
only thing I can find is 3.2.6.2:

"If a node is enabled and in the locked-instantiation administrative
state when it leaves the cluster membership, the node stays enabled
until it joins the cluster again."

  This says nothing about expected or unexpected leaving of the cluster.

  In short, I see two possible solutions:

(1) We need a way to reboot the node without AMF sending DISABLED
operational states for SUs on that node, which it currently does even if
the reboot is graceful. This is the preferred approach, as I believe it
follows the specs. I have supplied a patch for this.

(2) Or, SMF could unset the suMaintenanceCampaign after it does the
lock-in of the node before the reboot. The downside with this is that
any errors in middleware SUs could not be detected.

Alex

On 02/27/2017 01:55 AM, praveen malviya wrote:
> One more thing, as per spec AMF has to mark a node disabled when it
> reboots.

Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Reply via email to