[tickets] [opensaf:tickets] #2066 smf: Fix loop timeout in admin operation handling

2016-09-30 Thread elunlen 
- **summary**: smf: In admin operation handling a not needed delay may be 
executed --> smf: Fix loop timeout in admin operation handling
- Description has changed:

Diff:



--- old
+++ new
@@ -1,2 +1 @@
-In method nodeGroupAdminOperation() a try again loop will do an not needed 
delay in some cases.
-Refactor this loop
+Timeout of AMF admin operation is not handled correctly. The value of 
smfAdminOpTimeout in SMF config object must not only be used as timeout input 
for saImmOmAdminOperationInvoke_2() it must also include TRY AGAIN handling for 
both saImmOmAdminOperationInvoke_2() and the AMF OI return code.



- **status**: unassigned --> accepted
- **assigned_to**: elunlen



---

** [tickets:#2066] smf: Fix loop timeout in admin operation handling**

**Status:** accepted
**Milestone:** 5.1.1
**Created:** Fri Sep 23, 2016 11:54 AM UTC by elunlen
**Last Updated:** Fri Sep 23, 2016 11:54 AM UTC
**Owner:** elunlen


Timeout of AMF admin operation is not handled correctly. The value of 
smfAdminOpTimeout in SMF config object must not only be used as timeout input 
for saImmOmAdminOperationInvoke_2() it must also include TRY AGAIN handling for 
both saImmOmAdminOperationInvoke_2() and the AMF OI return code.



---

Sent from sourceforge.net because 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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2087 SMF: smfnd asserted on active controller with long dn when executing the campaign.

2016-09-30 Thread elunlen 
SMF supports long DN in general but there are some limitations mainly becase 
AMF does not support long DN before OpenSAF version 5.1. Therefore SMF has 
tests that limit the usage of long DN for AMF related objects and long campaign 
names.
Support for long DN is implemented in AMF and enabled in SMF from version 5.1. 
Try to test with 5.1.0 or later. See also [#1968]


---

** [tickets:#2087] SMF: smfnd asserted on active controller with long dn when 
executing the campaign.**

**Status:** unassigned
**Milestone:** 4.7.2
**Created:** Fri Sep 30, 2016 11:47 AM UTC by Madhurika Koppula
**Last Updated:** Fri Sep 30, 2016 11:48 AM UTC
**Owner:** nobody
**Attachments:**

- 
[smfnd_assert.tgz](https://sourceforge.net/p/opensaf/tickets/2087/attachment/smfnd_assert.tgz)
 (936.2 kB; application/octet-stream)


**Environment Details:**

OS : Suse 64bit
Setup : 4 nodes ( 2 controllers and 2 payloads with headless feature disabled & 
PBE disabled ).

**Summary**:  smfnd asserted on active controller with long dn when executing 
the campaign.

**Steps followed & Observed behaviour:**

1) Initially brought up four nodes and all the nodes joined the cluster (PBE is 
disabled)
2) Enabled long dn as follows.
immcfg -a longDnsAllowed=1 opensafImm=opensafImm,safApp=safImmService
3) Successfully created the campaign object with long dn 
immcfg -c SaSmfCampaign 
safSmfCampaign=campaign_long_dn_d,safApp=safSmfService
 -a SmfCmpgFileUri=/hostfs/campaign85.xml 
4) Executed the campaign.

Observations:

smfnd asserted on active controller. Campaign execution failed.

Below is the timestamp of Active controller (SC-1):

Oct  9 22:07:06 SCALE_SLOT-21 osafsmfd[2816]: NO CAMP: Calling configured 
smfBundleCheckCmd for each bundle existing in IMM, to be installed or removed 
by the campaign

**Oct  9 22:07:06 SCALE_SLOT-21 osafsmfnd[2810]: osaf_extended_name.c:144: 
osaf_extended_name_length: Assertion 'osaf_extended_names_enabled && length >= 
SA_MAX_UNEXTENDED_NAME_LENGTH' failed.**

Oct  9 22:07:06 SCALE_SLOT-21 osafamfnd[2794]: NO 
'safSu=SC-1,safSg=NoRed,safApp=OpenSAF' component restart probation timer 
started (timeout: 600 ns)
Oct  9 22:07:06 SCALE_SLOT-21 osafamfnd[2794]: NO Restarting a component of 
'safSu=SC-1,safSg=NoRed,safApp=OpenSAF' (comp restart count: 1)
Oct  9 22:07:06 SCALE_SLOT-21 osafamfnd[2794]: NO 
'safComp=SMFND,safSu=SC-1,safSg=NoRed,safApp=OpenSAF' faulted due to 'avaDown' 
: Recovery is 'componentRestart'
Oct  9 22:07:06 SCALE_SLOT-21 osafsmfnd[3072]: Started

Attachments:
1)Syslog, smf, imm traces of active controller.


---

Sent from sourceforge.net because 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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2087 SMF: smfnd asserted on active controller with long dn when executing the campaign.

2016-09-30 Thread Madhurika Koppula 
Attaching the stacktrace of smfnd.


Attachments:

- 
[smfnd_assert.txt](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/b205d76a/7556/attachment/smfnd_assert.txt)
 (2.8 kB; text/plain)


---

** [tickets:#2087] SMF: smfnd asserted on active controller with long dn when 
executing the campaign.**

**Status:** unassigned
**Milestone:** 4.7.2
**Created:** Fri Sep 30, 2016 11:47 AM UTC by Madhurika Koppula
**Last Updated:** Fri Sep 30, 2016 11:47 AM UTC
**Owner:** nobody
**Attachments:**

- 
[smfnd_assert.tgz](https://sourceforge.net/p/opensaf/tickets/2087/attachment/smfnd_assert.tgz)
 (936.2 kB; application/octet-stream)


**Environment Details:**

OS : Suse 64bit
Setup : 4 nodes ( 2 controllers and 2 payloads with headless feature disabled & 
PBE disabled ).

**Summary**:  smfnd asserted on active controller with long dn when executing 
the campaign.

**Steps followed & Observed behaviour:**

1) Initially brought up four nodes and all the nodes joined the cluster (PBE is 
disabled)
2) Enabled long dn as follows.
immcfg -a longDnsAllowed=1 opensafImm=opensafImm,safApp=safImmService
3) Successfully created the campaign object with long dn 
immcfg -c SaSmfCampaign 
safSmfCampaign=campaign_long_dn_d,safApp=safSmfService
 -a SmfCmpgFileUri=/hostfs/campaign85.xml 
4) Executed the campaign.

Observations:

smfnd asserted on active controller. Campaign execution failed.

Below is the timestamp of Active controller (SC-1):

Oct  9 22:07:06 SCALE_SLOT-21 osafsmfd[2816]: NO CAMP: Calling configured 
smfBundleCheckCmd for each bundle existing in IMM, to be installed or removed 
by the campaign

**Oct  9 22:07:06 SCALE_SLOT-21 osafsmfnd[2810]: osaf_extended_name.c:144: 
osaf_extended_name_length: Assertion 'osaf_extended_names_enabled && length >= 
SA_MAX_UNEXTENDED_NAME_LENGTH' failed.**

Oct  9 22:07:06 SCALE_SLOT-21 osafamfnd[2794]: NO 
'safSu=SC-1,safSg=NoRed,safApp=OpenSAF' component restart probation timer 
started (timeout: 600 ns)
Oct  9 22:07:06 SCALE_SLOT-21 osafamfnd[2794]: NO Restarting a component of 
'safSu=SC-1,safSg=NoRed,safApp=OpenSAF' (comp restart count: 1)
Oct  9 22:07:06 SCALE_SLOT-21 osafamfnd[2794]: NO 
'safComp=SMFND,safSu=SC-1,safSg=NoRed,safApp=OpenSAF' faulted due to 'avaDown' 
: Recovery is 'componentRestart'
Oct  9 22:07:06 SCALE_SLOT-21 osafsmfnd[3072]: Started

Attachments:
1)Syslog, smf, imm traces of active controller.


---

Sent from sourceforge.net because 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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2080 smf: balanced upgrade software bundle missmatch

2016-09-30 Thread Rafael 
- **status**: accepted --> fixed



---

** [tickets:#2080] smf: balanced upgrade software bundle missmatch**

**Status:** fixed
**Milestone:** 5.1.1
**Created:** Thu Sep 29, 2016 07:50 AM UTC by Rafael
**Last Updated:** Fri Sep 30, 2016 08:18 AM UTC
**Owner:** Rafael


When merging steps for the BALANCED_MODE execution there is a missmatch in how 
the software bundles are added to the new step. The problem will show when 
nodes have different software installed and not all of those nodes are included 
in the balanced list.


---

Sent from sourceforge.net because 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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2080 smf: balanced upgrade software bundle missmatch

2016-09-30 Thread Rafael 
changeset:   8177:d70633d36e89
branch:  opensaf-5.1.x
parent:  8173:2e102946fdfb
summary: smf: balanced upgrade software bundle missmatch [#2080]
Node ID d70633d36e89aed4454dba9097ec3e5e0df50f52


changeset:   8176:e27693353f50
summary: smf: balanced upgrade software bundle missmatch [#2080]
Node ID e27693353f50f56ffd42722c0343eb2a577f4d00





---

** [tickets:#2080] smf: balanced upgrade software bundle missmatch**

**Status:** accepted
**Milestone:** 5.1.1
**Created:** Thu Sep 29, 2016 07:50 AM UTC by Rafael
**Last Updated:** Thu Sep 29, 2016 07:50 AM UTC
**Owner:** Rafael


When merging steps for the BALANCED_MODE execution there is a missmatch in how 
the software bundles are added to the new step. The problem will show when 
nodes have different software installed and not all of those nodes are included 
in the balanced list.


---

Sent from sourceforge.net because 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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2049 smf: Delete node group if already exist when creating

2016-09-30 Thread elunlen 
- **status**: review --> fixed
- **assigned_to**: elunlen -->  nobody 
- **Comment**:

changeset:   8174:dd0be709aa28
parent:  8171:ab0c13244507
user:Lennart Lund 
date:Fri Sep 30 09:27:06 2016 +0200
summary: smf: Delete node group if already exist when creating [#2049]

rev: dd0be709aa289608b57d1e00a50c1fd2388cc276

changeset:   8172:c601b355c500
branch:  opensaf-5.1.x
parent:  8170:20b4d2bb8bc0
user:Lennart Lund 
date:Fri Sep 30 09:27:06 2016 +0200
summary: smf: Delete node group if already exist when creating [#2049]

rev: c601b355c50052581a150c9e49d1bd4e203d7d66



---

** [tickets:#2049] smf: Delete node group if already exist when creating**

**Status:** fixed
**Milestone:** 5.1.1
**Created:** Mon Sep 19, 2016 12:52 PM UTC by elunlen
**Last Updated:** Tue Sep 27, 2016 05:21 PM UTC
**Owner:** nobody


If for some reason a node a node group for admin operation already exist when 
trying to create one the existing node group shall be deleted and a new attempt 
to create the node group shall be done


---

Sent from sourceforge.net because 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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2046 smf: Recreate IMM handles if bad handle when deleting node group

2016-09-30 Thread elunlen 
- **status**: review --> fixed
- **assigned_to**: elunlen -->  nobody 
- **Comment**:

changeset:   8175:6c94f3d082e5
tag: tip
user:Lennart Lund 
date:Fri Sep 30 09:27:23 2016 +0200
summary: smf: Recreate IMM handles if bad handle when deleting node group 
[#2046]

rev: 6c94f3d082e51ad81f3377d1bac797a63c970f88

changeset:   8173:2e102946fdfb
branch:  opensaf-5.1.x
user:Lennart Lund 
date:Fri Sep 30 09:27:23 2016 +0200
summary: smf: Recreate IMM handles if bad handle when deleting node group 
[#2046]

rev: 2e102946fdfb9a7a389d1dde127dd892bdac7c7e



---

** [tickets:#2046] smf: Recreate IMM handles if bad handle when deleting node 
group**

**Status:** fixed
**Milestone:** 5.1.1
**Created:** Mon Sep 19, 2016 11:23 AM UTC by elunlen
**Last Updated:** Tue Sep 27, 2016 05:21 PM UTC
**Owner:** nobody


When doing an admin operation on AMF a fail may cause the handles that was 
created when the admin operation C++ object was created to be invalid. If that 
happen a node group that was created before the admin operation cannot be 
deleted, will fail with bad handle.
The node group must always be deleted.
The deleteNodeGroup() method must be fixed so that if the delete operation 
fails with bad handles new handles has to be created so that the node group can 
be deleted


---

Sent from sourceforge.net because 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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1944 amf: two actives for same SI after sufailover recovery during su lock/shutdown, NWAY.

2016-09-30 Thread Praveen 
- **status**: accepted --> review



---

** [tickets:#1944] amf: two actives for same SI after sufailover recovery 
during su lock/shutdown, NWAY.**

**Status:** review
**Milestone:** 5.0.2
**Created:** Tue Aug 09, 2016 09:23 AM UTC by Praveen
**Last Updated:** Tue Sep 20, 2016 05:59 PM UTC
**Owner:** Praveen
**Attachments:**

- 
[two_actives.tgz](https://sourceforge.net/p/opensaf/tickets/1944/attachment/two_actives.tgz)
 (69.1 kB; application/x-compressed)


Attached are traces and conf.

steps to reproduce:
1)Bring the configuration up.
2)Lock active SU.
3)While processing remove callback, one comp must fault sufailover recovery.
4)Amf will make Su3 also active for both the SIs when Su2 is already make 
active after quiesced assignments.

Assignments before su lock
safSISU=safSu=SU2\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo,safApp=AmfDemo1
saAmfSISUHAState=STANDBY(2)
safSISU=safSu=SU2\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo1,safApp=AmfDemo1
saAmfSISUHAState=STANDBY(2)
safSISU=safSu=SU3\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo,safApp=AmfDemo1
saAmfSISUHAState=STANDBY(2)
safSISU=safSu=SU3\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo1,safApp=AmfDemo1
saAmfSISUHAState=STANDBY(2)
safSISU=safSu=SU1\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo,safApp=AmfDemo1
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SU1\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo1,safApp=AmfDemo1
saAmfSISUHAState=ACTIVE(1)

Assignments after SU lock:
safSISU=safSu=SU2\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo,safApp=AmfDemo1
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SU2\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo1,safApp=AmfDemo1
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SU3\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo,safApp=AmfDemo1
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SU3\,safSg=AmfDemo\,safApp=AmfDemo1,safSi=AmfDemo1,safApp=AmfDemo1
saAmfSISUHAState=ACTIVE(1)

Issue will be applicable to Nore lock/shutdown also.


---

Sent from sourceforge.net because 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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2086 LCK : Lock waiter callbacks are not invoked after glnd restart

2016-09-30 Thread Srikanth R 



---

** [tickets:#2086] LCK : Lock waiter callbacks are not invoked after glnd 
restart**

**Status:** unassigned
**Milestone:** 4.7.2
**Created:** Fri Sep 30, 2016 06:10 AM UTC by Srikanth R
**Last Updated:** Fri Sep 30, 2016 06:10 AM UTC
**Owner:** nobody


Changeset : 7997 5.1.FC

 Lock waiter callbacks are not invoked after glnd restart. Below are the steps 
performed as part of  application.
 
 -> Initialize with LCK and store as handle 1.
 -> Initialize with LCK and store as handle 2 in another thread.
 -> Open a lock using saLckResourceOpen with handle1
 -> Open the same lock using saLckResourceOpen with handle2
 -> With handle 2, request lock in PR mode using saLckResourceOpen api. Call 
this api 5 times.
 -> WIth handle 1, request lock in EX mode,
 
 As the handle 2 has requested the lock 5 times, the thread for handle 1 
should get 5 lock waiter callbacks. Some times, lock waiter callback is not 
invoked for the thread using handle 1.


---

Sent from sourceforge.net because 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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets