Hi Alex We are looking at this. I will run a legacy test with your patches for 2144 and 2145. I will also look a bit more into the consequences of this (SMF backwards compatibility, BC). Note: A common way of handling BC is to add a configuration attribute to the general configuration IMM class that makes it possible to switch on and off a feature. However in this case you have implemented something that is specified in AIS so let's hope this is not needed.
Thanks Lennart > -----Original Message----- > From: Alex Jones [mailto:[email protected]] > Sent: den 28 februari 2017 01:42 > To: praveen malviya <[email protected]>; Lennart Lund > <[email protected]>; Rafael Odzakow > <[email protected]>; Neelakanta Reddy > <[email protected]> > Cc: [email protected] > Subject: Re: [PATCH 1 of 1] amf: add support for restrictions to auto-repair > [#2144] > > 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. ------------------------------------------------------------------------------ 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
