Hi Sirisha,
sorry for the late answer.
Yes behavior has changed here.
But changes of "behavior" at the level of admin-ownership is something one has
to accept.
I still dont fully understand what this test was trying to do and why.
But even without understanding it, I have explained that the simplest solution
(except not running this
particular test) is to set admin-owner to the same admin-owner name that is now
pre-set by the imm for
'opensafImm=opensafImm,safApp=safImmService'.
If you still have some kind of problem with this, then dont hesitate to ask.
/AndersBj
________________________________
From: Sirisha Alla [mailto:sirisha.a...@oracle.com]
Sent: den 8 september 2014 14:49
To: opensaf-tickets@lists.sourceforge.net
Subject: Re: [tickets] [opensaf:tickets] #1049 ccbs fail to apply after immnd
restart in 2pbe
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, Pbe file: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 because
opensaf-tickets@lists.sourceforge.net<mailto:opensaf-tickets@lists.sourceforge.net>
is subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://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-tickets@lists.sourceforge.net<mailto:Opensaf-tickets@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-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
