In 2PBE case safImmService is the admin owner for object opensafImm=opensafImm,safApp=safImmService. By default when 2PBE is coming up safImmService is set as adminowner for object opensafImm=opensafImm,safApp=safImmService . The same requirement is not there for 1PBE. No, change in the behavior from 4.4.
On Monday 08 September 2014 06:19 PM, Sirisha Alla wrote: > Without being an admin owner for an object, does IMM honor clear of > admin owner on that object? And why does this work in single PBE case? > Is this behavior different from 4.4? > > > On Monday 08 September 2014 06:10 PM, Neelakanta Reddy wrote: >> - **status**: unassigned --> invalid >> - **Comment**: >> >> Application has explicitly called Adminownerclear on object >> opensafImm=opensafImm,safApp=safImmService. imm service needs >> admin-ownership over the object "opensafImm=opensafImm,safApp=safImmService" >> in order for 2PBE to work properly(see README.2PBE) >> >> Sep 8 15:48:55.996067 osafimmnd [20639:immsv_evt.c:5382] T8 Received: >> IMMND_EVT_A2ND_ADMO_CLEAR (11) from 0 >> Sep 8 15:48:55.996081 osafimmnd [20639:ImmModel.cc:4374] >> adminOwnerChange >> Sep 8 15:48:55.996092 osafimmnd [20639:ImmModel.cc:4401] T5 Clear admin >> owner 'ALL' >> Sep 8 15:48:55.996139 osafimmnd [20639:ImmModel.cc:4506] TR Cutoff in >> admo-change-loop by childCount >> Sep 8 15:48:55.996153 osafimmnd [20639:ImmModel.cc:4414] T5 Clear Admin >> Owner for object opensafImm=opensafImm,safApp=safImmService >> Sep 8 15:48:55.996173 osafimmnd [20639:ImmModel.cc:4506] TR Cutoff in >> admo-change-loop by childCount >> Sep 8 15:48:55.996186 osafimmnd [20639:ImmModel.cc:4519] << adminOwnerChange >> >> >> >> >> --- >> >> ** [tickets:#1049] ccbs fail to apply after immnd restart in 2pbe** >> >> **Status:** invalid >> **Milestone:** 4.3.3 >> **Created:** Mon Sep 08, 2014 10:53 AM UTC by Sirisha Alla >> **Last Updated:** Mon Sep 08, 2014 11:14 AM UTC >> **Owner:** nobody >> >> The issue is seen on SLES X86-64 VMs. Opensaf is running on changeset 5697 >> with 2pbe. Same IMM applications ran fine on single pbe. >> >> opensaf is running on 4 nodes. The issue is observed after IMMND restart. >> >> After IMMND is killed on PL-3, Syslog on PL-3 and SC-1 (active controller): >> >> Sep 8 15:49:14 SLES-64BIT-SLOT3 osafamfnd[18773]: NO >> 'safSu=PL-3,safSg=NoRed,safApp=OpenSAF' component restart probation timer >> started (timeout: 60000000000 ns) >> Sep 8 15:49:14 SLES-64BIT-SLOT3 osafamfnd[18773]: NO Restarting a component >> of 'safSu=PL-3,safSg=NoRed,safApp=OpenSAF' (comp restart count: 1) >> Sep 8 15:49:14 SLES-64BIT-SLOT3 osafamfnd[18773]: NO >> 'safComp=IMMND,safSu=PL-3,safSg=NoRed,safApp=OpenSAF' faulted due to >> 'avaDown' : Recovery is 'componentRestart' >> Sep 8 15:49:14 SLES-64BIT-SLOT3 osafimmnd[19065]: Started >> Sep 8 15:49:14 SLES-64BIT-SLOT3 osafimmnd[19065]: NO Persistent Back-End >> capability configured, Pbefile:imm.db (suffix may get added) >> Sep 8 15:49:14 SLES-64BIT-SLOT3 osafimmnd[19065]: NO Fevs count adjusted to >> 2143 preLoadPid: 0 >> Sep 8 15:49:14 SLES-64BIT-SLOT3 osafimmnd[19065]: NO SERVER STATE: >> IMM_SERVER_ANONYMOUS --> IMM_SERVER_CLUSTER_WAITING >> Sep 8 15:49:14 SLES-64BIT-SLOT3 osafimmnd[19065]: NO SERVER STATE: >> IMM_SERVER_CLUSTER_WAITING --> IMM_SERVER_LOADING_PENDING >> Sep 8 15:49:15 SLES-64BIT-SLOT3 osafimmnd[19065]: NO SERVER STATE: >> IMM_SERVER_LOADING_PENDING --> IMM_SERVER_SYNC_PENDING >> Sep 8 15:49:15 SLES-64BIT-SLOT3 osafimmnd[19065]: NO NODE STATE-> >> IMM_NODE_ISOLATED >> Sep 8 15:49:15 SLES-64BIT-SLOT3 osafimmnd[19065]: NO NODE STATE-> >> IMM_NODE_W_AVAILABLE >> Sep 8 15:49:16 SLES-64BIT-SLOT3 osafimmnd[19065]: NO SERVER STATE: >> IMM_SERVER_SYNC_PENDING --> IMM_SERVER_SYNC_CLIENT >> Sep 8 15:49:16 SLES-64BIT-SLOT3 osafimmnd[19065]: NO NODE STATE-> >> IMM_NODE_FULLY_AVAILABLE 2460 >> Sep 8 15:49:16 SLES-64BIT-SLOT3 osafimmnd[19065]: NO RepositoryInitModeT is >> SA_IMM_KEEP_REPOSITORY >> Sep 8 15:49:16 SLES-64BIT-SLOT3 osafimmnd[19065]: WA IMM Access Control >> mode is DISABLED! >> >> Sep 8 15:49:44 SLES-64BIT-SLOT3 osafimmnd[19065]: NO Implementer connected: >> 43 (Rajesh) <130, 2030f> >> Sep 8 15:49:46 SLES-64BIT-SLOT3 osafimmnd[19065]: NO implementer for class >> 'AHGEspukccZxcngTQuhG' is Rajesh => class extent is safe. >> Sep 8 15:49:46 SLES-64BIT-SLOT3 osafimmnd[19065]: NO ERR_BAD_OPERATION: >> Mismatch on administrative owner '' != 'safImmService' >> Sep 8 15:49:46 SLES-64BIT-SLOT3 osafimmnd[19065]: NO ERR_BAD_OPERATION: >> Mismatch on administrative owner '' != 'safImmService' >> Sep 8 15:49:47 SLES-64BIT-SLOT3 osafimmnd[19065]: NO ERR_BAD_OPERATION: >> Mismatch on administrative owner '' != 'safImmService' >> Sep 8 15:49:47 SLES-64BIT-SLOT3 osafimmnd[19065]: NO ERR_BAD_OPERATION: >> Mismatch on administrative owner '' != 'safImmService' >> Sep 8 15:49:48 SLES-64BIT-SLOT3 osafimmnd[19065]: NO ERR_BAD_OPERATION: >> Mismatch on administrative owner '' != 'safImmService' >> Sep 8 15:49:48 SLES-64BIT-SLOT3 osafimmnd[19065]: NO ERR_BAD_OPERATION: >> Mismatch on administrative owner '' != 'safImmService' >> Sep 8 15:49:49 SLES-64BIT-SLOT3 osafimmnd[19065]: NO Validation error >> (BAD_OPERATION) reported by implementer 'OpenSafImmPBE', Ccb 17 will be >> aborted >> Sep 8 15:49:49 SLES-64BIT-SLOT3 osafimmnd[19065]: NO Ccb 17 ABORTED >> (SetUp_Ccb) >> >> >> Sep 8 15:49:43 SLES-64BIT-SLOT1 osafimmpbed: IN Starting distributed PBE >> commit for Ccb:11/17 >> Sep 8 15:49:43 SLES-64BIT-SLOT1 osafimmnd[20639]: NO ERR_BAD_OPERATION: >> Mismatch on administrative owner '' != 'safImmService' >> Sep 8 15:49:44 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE 20 or Immsv >> (4294901760) replied with transient error on prepare for ccb:11/17 >> Sep 8 15:49:44 SLES-64BIT-SLOT1 osafimmnd[20639]: NO ERR_BAD_OPERATION: >> Mismatch on administrative owner '' != 'safImmService' >> Sep 8 15:49:44 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE 20 or Immsv >> (4294901760) replied with transient error on prepare for ccb:11/17 >> Sep 8 15:49:44 SLES-64BIT-SLOT1 osafimmnd[20639]: NO ERR_BAD_OPERATION: >> Mismatch on administrative owner '' != 'safImmService' >> Sep 8 15:49:45 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE 20 or Immsv >> (4294901760) replied with transient error on prepare for ccb:11/17 >> Sep 8 15:49:45 SLES-64BIT-SLOT1 osafimmnd[20639]: NO ERR_BAD_OPERATION: >> Mismatch on administrative owner '' != 'safImmService' >> Sep 8 15:49:45 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE 20 or Immsv >> (4294901760) replied with transient error on prepare for ccb:11/17 >> Sep 8 15:49:45 SLES-64BIT-SLOT1 osafimmnd[20639]: NO ERR_BAD_OPERATION: >> Mismatch on administrative owner '' != 'safImmService' >> Sep 8 15:49:46 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE 20 or Immsv >> (4294901760) replied with transient error on prepare for ccb:11/17 >> Sep 8 15:49:46 SLES-64BIT-SLOT1 osafimmnd[20639]: NO ERR_BAD_OPERATION: >> Mismatch on administrative owner '' != 'safImmService' >> Sep 8 15:49:46 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE 20 or Immsv >> (4294901760) replied with transient error on prepare for ccb:11/17 >> Sep 8 15:49:46 SLES-64BIT-SLOT1 osafimmpbed: WA Start prepare for ccb: >> 11/17 towards slave PBE returned: '20' from Immsv >> Sep 8 15:49:46 SLES-64BIT-SLOT1 osafimmpbed: WA PBE-A failed to prepare >> Ccb:11/17 towards PBE-B >> Sep 8 15:49:46 SLES-64BIT-SLOT1 osafimmnd[20639]: NO Validation error >> (BAD_OPERATION) reported by implementer 'OpenSafImmPBE', Ccb 17 will be >> aborted >> Sep 8 15:49:46 SLES-64BIT-SLOT1 osafimmnd[20639]: NO Ccb 17 ABORTED >> (SetUp_Ccb) >> >> >> Syslog and immnd traces are attached. The issue is reproducible. >> >> >> >> >> >> --- >> >> Sent from sourceforge.net becauseopensaf-tick...@lists.sourceforge.net is >> subscribed tohttps://sourceforge.net/p/opensaf/tickets/ >> >> To unsubscribe from further messages, a project admin can change settings >> athttps://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a >> mailing list, you can unsubscribe from the mailing list. >> >> >> ------------------------------------------------------------------------------ >> Want excitement? >> Manually upgrade your production database. >> When you want reliability, choose Perforce >> Perforce version control. Predictably reliable. >> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >> >> >> _______________________________________________ >> Opensaf-tickets mailing list >> opensaf-tick...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/opensaf-tickets > > > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > > > _______________________________________________ > Opensaf-tickets mailing list > opensaf-tick...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensaf-tickets ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
