[tickets] [opensaf:tickets] #315 SU restart not according to spec

2015-09-17 Thread Praveen 
For default branch 315.patch rebased on parent: 6844:ff30714b16bb tip.


Attachments:

- 
[315.patch](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/f316c8a6/ddd6/attachment/315.patch)
 (93.8 kB; application/octet-stream)


---

** [tickets:#315] SU restart not according to spec**

**Status:** review
**Milestone:** 4.5.2
**Created:** Fri May 24, 2013 08:35 AM UTC by Nagendra Kumar
**Last Updated:** Fri Sep 18, 2015 06:19 AM UTC
**Owner:** Praveen


Migrated from http://devel.opensaf.org/ticket/3061

First issue:
=
  When testing http://devel.opensaf.org/ticket/3056 I found the problem that SU 
restart does not follow the instantiation level as supposed to:

spec 3.8.2

"Within a service unit, the Availability Management Framework terminates the 
pre-instantiable components according to the configured instantiation level. 
All pre-instantiable components with the same instantiation level are 
terminated by the Avail-
ability Management Framework in parallel. Pre-instantiable components of a 
given level are only terminated by the Availability Management Framework when 
all pre-instantiable components with a higher instantiation level have been 
terminated.
As has been said previously, the instantiation level is only applicable during 
service unit instantiation and termination. As restarting a service unit means 
terminating the
service unit and instantiating it again, the instantiation level also applies 
when restart-ing a service unit."


It is obvious from the code in avnd_su_pres_inst_surestart_hdler():


/* 


•If pi su, pick the first pi comp & trigger it's FSM with RestartEv?. */ 
if (m_AVND_SU_IS_PREINSTANTIABLE(su)) {


TRACE("PI SU:'%s'",su->name.value);
for (curr_comp = 
m_AVND_COMP_FROM_SU_DLL_NODE_GET(m_NCS_DBLIST_FIND_FIRST(&su->comp_list));


should pick the last component since this list is sorted by the instantiation 
level.

Second issue:

3.11.1.2:

"Restarting a service unit is achieved by the following actions:
• First, all components in the service unit are terminated in the order 
dictated by their instantiation-levels.
• In a second step, all components in the service unit are instantiated 
in the order dictated by their instantiation-levels."


That is not the case today since each component is restarted (not terminated 
and instantiated)




---

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] #315 SU restart not according to spec

2015-09-17 Thread Praveen 
Attached are the patches for 4.5 and 4.6 branches.
1)4.5 :  315_4.5.patch (parent: 6841:0198c81ad4ad).
2)4.6:  315_4.6.patch  (generated on parent: 6842:e9b051d8a81e)


Attachments:

- 
[315_4.5.patch](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/f316c8a6/ace0/attachment/315_4.5.patch)
 (93.8 kB; application/octet-stream)
- 
[315_4.6.patch](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/f316c8a6/ace0/attachment/315_4.6.patch)
 (93.8 kB; application/octet-stream)


---

** [tickets:#315] SU restart not according to spec**

**Status:** review
**Milestone:** 4.5.2
**Created:** Fri May 24, 2013 08:35 AM UTC by Nagendra Kumar
**Last Updated:** Fri Sep 11, 2015 04:35 AM UTC
**Owner:** Praveen


Migrated from http://devel.opensaf.org/ticket/3061

First issue:
=
  When testing http://devel.opensaf.org/ticket/3056 I found the problem that SU 
restart does not follow the instantiation level as supposed to:

spec 3.8.2

"Within a service unit, the Availability Management Framework terminates the 
pre-instantiable components according to the configured instantiation level. 
All pre-instantiable components with the same instantiation level are 
terminated by the Avail-
ability Management Framework in parallel. Pre-instantiable components of a 
given level are only terminated by the Availability Management Framework when 
all pre-instantiable components with a higher instantiation level have been 
terminated.
As has been said previously, the instantiation level is only applicable during 
service unit instantiation and termination. As restarting a service unit means 
terminating the
service unit and instantiating it again, the instantiation level also applies 
when restart-ing a service unit."


It is obvious from the code in avnd_su_pres_inst_surestart_hdler():


/* 


•If pi su, pick the first pi comp & trigger it's FSM with RestartEv?. */ 
if (m_AVND_SU_IS_PREINSTANTIABLE(su)) {


TRACE("PI SU:'%s'",su->name.value);
for (curr_comp = 
m_AVND_COMP_FROM_SU_DLL_NODE_GET(m_NCS_DBLIST_FIND_FIRST(&su->comp_list));


should pick the last component since this list is sorted by the instantiation 
level.

Second issue:

3.11.1.2:

"Restarting a service unit is achieved by the following actions:
• First, all components in the service unit are terminated in the order 
dictated by their instantiation-levels.
• In a second step, all components in the service unit are instantiated 
in the order dictated by their instantiation-levels."


That is not the case today since each component is restarted (not terminated 
and instantiated)




---

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] #464 Verify duplicate TIPC node_id before configuring TIPC

2015-09-17 Thread A V Mahesh (AVM) 
- **status**: review --> fixed
- **Comment**:

changeset:   6844:ff30714b16bb
tag: tip
user:A V Mahesh 
date:Fri Sep 18 11:00:14 2015 +0530
summary: opensaf: prevented cluster re-start on misconfigured slot_id 
[#464/#414]



---

** [tickets:#464] Verify duplicate TIPC node_id before configuring TIPC**

**Status:** fixed
**Milestone:** 4.7.FC
**Created:** Tue Jun 18, 2013 10:06 AM UTC by Mathi Naickan
**Last Updated:** Thu Sep 03, 2015 08:56 AM UTC
**Owner:** A V Mahesh (AVM)


Currently, there is no direct way to detect if there is already another node 
running with the same TIPC node_id.
If we could query say the TIPC routing table before doing stuff that within 
nid_tipc, then we could fail the opensaf startup when duplicate slot_id is 
configured.

This can fix known issues like http://devel.opensaf.org/ticket/2802


---

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] #427 amf: Dependent sis are still in assigned state when tolerence timer expires during controller failover.

2015-09-17 Thread Praveen 
- **status**: review --> fixed
- **Comment**:

changeset:   6841:0198c81ad4ad
branch:  opensaf-4.5.x
parent:  6838:9ff3ee6e28df
user:praveen.malv...@oracle.com
date:Fri Sep 18 10:13:36 2015 +0530
summary: amfd: act on dep SIs if tol timer expires during controller 
fail-over [#427]

changeset:   6842:e9b051d8a81e
branch:  opensaf-4.6.x
parent:  6839:964e043fa545
user:praveen.malv...@oracle.com
date:Fri Sep 18 10:13:52 2015 +0530
summary: amfd: act on dep SIs if tol timer expires during controller 
fail-over [#427]

changeset:   6843:6a62544eb8ac
tag: tip
parent:  6840:a2c9e8a31cb4
user:praveen.malv...@oracle.com
date:Fri Sep 18 10:14:03 2015 +0530
summary: amfd: act on dep SIs if tol timer expires during controller 
fail-over [#427]




---

** [tickets:#427] amf: Dependent sis are still in assigned state when tolerence 
timer expires during controller failover.**

**Status:** fixed
**Milestone:** 4.5.2
**Labels:** SI Deps 
**Created:** Fri May 31, 2013 06:32 AM UTC by Praveen
**Last Updated:** Tue May 19, 2015 10:08 AM UTC
**Owner:** Praveen


Migrated from http://devel.opensaf.org/ticket/2834.

Changeset : 3784 4.2.2 RC1
 

Found on SLES 32 Bit Setup
 2 Controllers and 2 Payloads
 

Model - 2n
 SUs are hosted on payloads.
 

Scenario:
 



Created Dependency like SI1 as sponsor and SI2 as dependent with tolerance time 
as 60 sec.
 

Lock SI1 
SI1 has been unassigned.
 Waited for 56 sec
 Did "pkill osafamfd" on Active Controller and Active controller went for reboot
 Controller node joined successfully after reboot.
 

SI2 unassignment never happened.
 

SI assignment status is showing as:
 



safSi=SI1,safApp=App1
 


saAmfSIAdminState=LOCKED(2)
 saAmfSIAssignmentState=UNASSIGNED(1)
 

safSi=SI2,safApp=App1
 


saAmfSIAdminState=UNLOCKED(1)
 saAmfSIAssignmentState=FULLY_ASSIGNED(2)
 

safSi=SI3,safApp=App1
 


saAmfSIAdminState=UNLOCKED(1)
 saAmfSIAssignmentState=FULLY_ASSIGNED(2)
 

safSi=SI4,safApp=App1
 


saAmfSIAdminState=UNLOCKED(1)
 saAmfSIAssignmentState=FULLY_ASSIGNED(2)
 

Expected behavior is when tolerance timer is expires during controller 
failover, tolerance timer should restart after failover is done.
 

Attached /var/log/messages of all nodes



---

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] #1488 LCK: if master GLND reboots deadlock can occur for currently held locks

2015-09-17 Thread Alex Jones 
- **status**: assigned --> review



---

** [tickets:#1488] LCK: if master GLND reboots deadlock can occur for currently 
held locks**

**Status:** review
**Milestone:** 4.5.2
**Created:** Wed Sep 16, 2015 02:54 PM UTC by Alex Jones
**Last Updated:** Wed Sep 16, 2015 02:54 PM UTC
**Owner:** Alex Jones


If the master GLND is rebooted while an exclusive lock (or locks) is held, when 
the new master is elected and the other GLNDs send over the current lock 
information held by them to the new master, they do not send all information 
needed by the new master to lock/unlock currently held locks.

When this happens the lock(s) can never be unlocked or granted.


---

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.--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1473 AMF: Component Termination Failed alarm is raised then cleared immediately

2015-09-17 Thread Praveen 
- **status**: accepted --> review



---

** [tickets:#1473] AMF: Component Termination Failed alarm is raised then 
cleared immediately**

**Status:** review
**Milestone:** 4.5.2
**Created:** Thu Sep 10, 2015 09:52 AM UTC by Quyen Dao
**Last Updated:** Thu Sep 17, 2015 11:43 AM UTC
**Owner:** Praveen
**Attachments:**

- 
[osafamfd](https://sourceforge.net/p/opensaf/tickets/1473/attachment/osafamfd) 
(161.3 kB; application/octet-stream)
- 
[AppConfig-2N.xml](https://sourceforge.net/p/opensaf/tickets/1473/attachment/AppConfig-2N.xml)
 (9.3 kB; text/xml)


Steps to reproduce:
* Load the attached model
* Change the clc-cli script of the component to always return 1 for cleanup
* Kill the component

Result: Component Termination Failed alarm is raised then cleared immediately 
and presence state of the failed component is UNINSTANTIATED instead 
TERMINATION-FAILED.


Log


root@PL-3:~# ntfread
===  Sep 10 15:51:42 - Alarm  ===
eventType = SA_NTF_ALARM_PROCESSING
notificationObject = "safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1"
notifyingObject = "safApp=safAmfService"
notificationClassId = SA_NTF_VENDOR_ID_SAF.SA_SVC_AMF.3 (0x3)
additionalText = "Cleanup of Component 
safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1 failed"
- additionalInfo: 0 -
 infoId = 1
 infoType = 10
 infoValue = "safAmfNode=PL-3,safAmfCluster=myAmfCluster"
probableCause = SA_NTF_SOFTWARE_ERROR
perceivedSeverity = SA_NTF_SEVERITY_MAJOR

===  Sep 10 15:51:42 - Alarm  ===
eventType = SA_NTF_ALARM_PROCESSING
notificationObject = "safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1"
notifyingObject = "safApp=safAmfService"
notificationClassId = SA_NTF_VENDOR_ID_SAF.SA_SVC_AMF.3 (0x3)
additionalText = "Previous raised alarm of 
safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1 is now cleared"
probableCause = SA_NTF_SOFTWARE_ERROR
perceivedSeverity = SA_NTF_SEVERITY_CLEARED

root@PL-3:~# amf-state su all safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1
safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1
saAmfSUAdminState=UNLOCKED(1)
saAmfSUOperState=DISABLED(2)
saAmfSUPresenceState=TERMINATION-FAILED(7)
saAmfSUReadinessState=OUT-OF-SERVICE(1)
root@PL-3:~#
root@PL-3:~# amf-state comp all 
safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1
safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1
saAmfCompOperState=DISABLED(2)
saAmfCompPresenceState=UNINSTANTIATED(1)
saAmfCompReadinessState=OUT-OF-SERVICE(1)
root@PL-3:~#


---

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.--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #78 amf: support for si-swap admin op for Nway model.

2015-09-17 Thread Praveen 
Attached is a sample configuration for Nway model.


Attachments:

- 
[AppConfig-N-Way_2Comp_2SI_2CSI.xml](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/fc168502/dd29/attachment/AppConfig-N-Way_2Comp_2SI_2CSI.xml)
 (16.1 kB; text/xml)


---

** [tickets:#78] amf: support for si-swap admin op for Nway model.**

**Status:** review
**Milestone:** 4.7.FC
**Created:** Mon May 13, 2013 04:31 AM UTC by Nagendra Kumar
**Last Updated:** Wed Sep 16, 2015 10:54 AM UTC
**Owner:** Praveen


Migrated from http://devel.opensaf.org/ticket/2073

performing "si-swap" on an si of models NplusM, Nway,NwayActive? is returning 
"ERR_NOT SUPPORTED"


Also there is no mentioning about what the return code should be for "si-swap" 
on NwayActive? and NoRed? Models. 


console output:
amf-adm si-swap safSi=NWayActiveXAppSiorder_SI1,safApp=NWayActiveXAppSiorder
error - saImmOmAdminOperationInvoke_2 admin-op RETURNED: 
SA_AIS_ERR_NOT_SUPPORTED (19)

**Implementation details:**
In this implemntaion for NWAY model, si-swap admin op will be supported with 
following restrictions:
1)Operation will be rejected if Equal distribution feature is enabled.
2)operation will be rejected if SIRankedSU is configured and AutoAdjust flag is
enabled. However it will be allowed if AutoAdjust is disabled.

**Reason for rejecting the operation in above two cases:**
In both of these cases AutoAdjust flag is eanbled and is used to partially
adjust the SG. At the same time, autoadjust feature is used without
using autoadjustprob timer. In the equal distribution cases both active
assignments and standby assignments are equally distributed among the
available SUs without waiting for any autoadjustprob timer expiry.
Thus if si-swap is supported in this case, SG will be adjusted to
same configuration.
Same explanation is valid for other case 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.--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #520 Mds: Tune MDS logging to minimal & informative

2015-09-17 Thread Praveen 
- **status**: assigned --> review



---

** [tickets:#520] Mds: Tune MDS logging  to minimal & informative **

**Status:** review
**Milestone:** 4.7.FC
**Created:** Thu Jul 25, 2013 01:19 PM UTC by hano
**Last Updated:** Tue Aug 25, 2015 04:08 PM UTC
**Owner:** A V Mahesh (AVM)


Minimize the  MDS logging  to  only in case of  required so that it can not 
reach  1 Mb of log rotation range/size sooner .


amfnd core dump is produced when amfnd main thread (10720) is waiting for a 
pthread mutex, gl_mds_library_mutex, which is held by the mds thread (10723).
The amf watchdog detects this (no healthchecks received) and sends an abort 
signal to the amfnd. Holding a mutex during file operations in MDS is not 
correct and should be corrected. (HR50165)
 

 #0  0x7f7830d70294 in __lll_lock_wait () from /lib64/libpthread.so.0

(gdb) p gl_mds_library_mutex

$1 = {__data = {__lock = 2, __count = 1, __owner = 10723, __nusers = 1, __kind 
= 1, __spins = 0, __list = {__prev = 0x0, __next = 0x0}},

  __size = " ã ) ", ' ' , __align = 4294967298}

(gdb) info thr

  Id   Target Id Frame

  4Thread 0x7f7832263b00 (LWP 10723) 0x7f783083e20d in write () from 
/lib64/libc.so.6

  3Thread 0x7f7832283b00 (LWP 10722) 0x7f7830844f53 in select () from 
/lib64/libc.so.6

  2Thread 0x7f7832243b00 (LWP 10724) 0x7f7830d7076d in read () from 
/lib64/libpthread.so.0

* 1Thread 0x7f7832286700 (LWP 10720) 0x7f7830d70294 in __lll_lock_wait 
() from /lib64/libpthread.so.0

 


---

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.--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1473 AMF: Component Termination Failed alarm is raised then cleared immediately

2015-09-17 Thread Praveen 
- **status**: unassigned --> accepted
- **assigned_to**: Praveen
- Attachments has changed:

Diff:



--- old
+++ new
@@ -1 +1,2 @@
+osafamfd (161.3 kB; application/octet-stream)
 AppConfig-2N.xml (9.3 kB; text/xml)



- **Part**: - --> d
- **Comment**:

I reproduced the issue by using the attached configuration. Only change I did 
is hosting the Sus on controllers. 
There is a case when amfd is clearing the alram raised on comp in  term_failed 
state. When all components are cleaned up, amfnd sends a su-failvoer request to 
amfd. In this case alram is being cleared and component is marked 
uninstantiated, even in the case when saAmfNodeFailfastOnTerminationFailure is 
false on the node hosting the term_failed comp.
Amfd should not mark comp uninstantiated and hence should not clear alarm when 
saAmfNodeFailfastOnTerminationFailure is false and admin repair is pending.

Attached is the amfd trace.




---

** [tickets:#1473] AMF: Component Termination Failed alarm is raised then 
cleared immediately**

**Status:** accepted
**Milestone:** 4.5.2
**Created:** Thu Sep 10, 2015 09:52 AM UTC by Quyen Dao
**Last Updated:** Thu Sep 10, 2015 09:52 AM UTC
**Owner:** Praveen
**Attachments:**

- 
[osafamfd](https://sourceforge.net/p/opensaf/tickets/1473/attachment/osafamfd) 
(161.3 kB; application/octet-stream)
- 
[AppConfig-2N.xml](https://sourceforge.net/p/opensaf/tickets/1473/attachment/AppConfig-2N.xml)
 (9.3 kB; text/xml)


Steps to reproduce:
* Load the attached model
* Change the clc-cli script of the component to always return 1 for cleanup
* Kill the component

Result: Component Termination Failed alarm is raised then cleared immediately 
and presence state of the failed component is UNINSTANTIATED instead 
TERMINATION-FAILED.


Log


root@PL-3:~# ntfread
===  Sep 10 15:51:42 - Alarm  ===
eventType = SA_NTF_ALARM_PROCESSING
notificationObject = "safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1"
notifyingObject = "safApp=safAmfService"
notificationClassId = SA_NTF_VENDOR_ID_SAF.SA_SVC_AMF.3 (0x3)
additionalText = "Cleanup of Component 
safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1 failed"
- additionalInfo: 0 -
 infoId = 1
 infoType = 10
 infoValue = "safAmfNode=PL-3,safAmfCluster=myAmfCluster"
probableCause = SA_NTF_SOFTWARE_ERROR
perceivedSeverity = SA_NTF_SEVERITY_MAJOR

===  Sep 10 15:51:42 - Alarm  ===
eventType = SA_NTF_ALARM_PROCESSING
notificationObject = "safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1"
notifyingObject = "safApp=safAmfService"
notificationClassId = SA_NTF_VENDOR_ID_SAF.SA_SVC_AMF.3 (0x3)
additionalText = "Previous raised alarm of 
safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1 is now cleared"
probableCause = SA_NTF_SOFTWARE_ERROR
perceivedSeverity = SA_NTF_SEVERITY_CLEARED

root@PL-3:~# amf-state su all safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1
safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1
saAmfSUAdminState=UNLOCKED(1)
saAmfSUOperState=DISABLED(2)
saAmfSUPresenceState=TERMINATION-FAILED(7)
saAmfSUReadinessState=OUT-OF-SERVICE(1)
root@PL-3:~#
root@PL-3:~# amf-state comp all 
safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1
safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1
saAmfCompOperState=DISABLED(2)
saAmfCompPresenceState=UNINSTANTIATED(1)
saAmfCompReadinessState=OUT-OF-SERVICE(1)
root@PL-3:~#


---

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.--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1490 log: cannot delete value of logStreamFileFormat

2015-09-17 Thread Vu Minh Nguyen 
- **status**: accepted --> review



---

** [tickets:#1490] log: cannot delete value of logStreamFileFormat**

**Status:** review
**Milestone:** 4.7.FC
**Created:** Thu Sep 17, 2015 09:07 AM UTC by Vu Minh Nguyen
**Last Updated:** Thu Sep 17, 2015 09:07 AM UTC
**Owner:** Vu Minh Nguyen


At start up, `logStreamFileFormat` attribute in configuration obj has  
value. Means that, built-in file format will be used as default value for app 
stream. If user sets an value to `logStreamFileFormat`, users can not delete 
the value of this attribute.

This is not correct.

If user want to use built-in file format, logsv has to allow user to delete the 
value of `logStreamFileFormat`.



---

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.--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1490 log: cannot delete value of logStreamFileFormat

2015-09-17 Thread Vu Minh Nguyen 
- **status**: unassigned --> accepted
- **assigned_to**: Vu Minh Nguyen



---

** [tickets:#1490] log: cannot delete value of logStreamFileFormat**

**Status:** accepted
**Milestone:** 4.7.FC
**Created:** Thu Sep 17, 2015 09:07 AM UTC by Vu Minh Nguyen
**Last Updated:** Thu Sep 17, 2015 09:07 AM UTC
**Owner:** Vu Minh Nguyen


At start up, `logStreamFileFormat` attribute in configuration obj has  
value. Means that, built-in file format will be used as default value for app 
stream. If user sets an value to `logStreamFileFormat`, users can not delete 
the value of this attribute.

This is not correct.

If user want to use built-in file format, logsv has to allow user to delete the 
value of `logStreamFileFormat`.



---

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.--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1490 log: cannot delete value of logStreamFileFormat

2015-09-17 Thread Vu Minh Nguyen 



---

** [tickets:#1490] log: cannot delete value of logStreamFileFormat**

**Status:** unassigned
**Milestone:** 4.7.FC
**Created:** Thu Sep 17, 2015 09:07 AM UTC by Vu Minh Nguyen
**Last Updated:** Thu Sep 17, 2015 09:07 AM UTC
**Owner:** nobody


At start up, `logStreamFileFormat` attribute in configuration obj has  
value. Means that, built-in file format will be used as default value for app 
stream. If user sets an value to `logStreamFileFormat`, users can not delete 
the value of this attribute.

This is not correct.

If user want to use built-in file format, logsv has to allow user to delete the 
value of `logStreamFileFormat`.



---

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.--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1489 amf: setting saAmfSIPrefActiveAssignments to empty in runtime causes amfd to crash.

2015-09-17 Thread Rafael 



---

** [tickets:#1489] amf: setting saAmfSIPrefActiveAssignments to empty in 
runtime causes amfd to crash.**

**Status:** unassigned
**Milestone:** future
**Created:** Thu Sep 17, 2015 08:50 AM UTC by Rafael
**Last Updated:** Thu Sep 17, 2015 08:50 AM UTC
**Owner:** nobody


To reproduce it run:

immcfg -a saAmfSIPrefActiveAssignments="" 
safSi=All-NWayActive,safApp=DemoApp

This will cause a amfd crash, from the system log:

Sep 17 10:00:46 SC-2-1 osafamfd[15466]: si.cc:1291: update_ass_state: Assertion 
'saAmfSINumCurrActiveAssignments <= saAmfSIPrefActiveAssignments' failed.
Sep 17 10:00:47 SC-2-1 osafamfnd[15479]: WA AMF director unexpectedly crashed
Sep 17 10:00:47 SC-2-1 osafamfnd[15479]: Rebooting OpenSAF NodeId = 131343 EE 
Name = , Reason: local AVD down(Adest) or both AVD down(Vdest) received, 
OwnNodeId = 131343, SupervisionTime = 60



---

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.--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1396 log: issue with priority of messages adding to mailbox in the server

2015-09-17 Thread elunlen 
- **Type**: defect --> enhancement
- **Milestone**: 4.5.2 --> 5.0



---

** [tickets:#1396] log: issue with priority of messages adding to mailbox in 
the server**

**Status:** accepted
**Milestone:** 5.0
**Created:** Mon Jun 29, 2015 09:14 AM UTC by Vu Minh Nguyen
**Last Updated:** Thu Sep 17, 2015 07:41 AM UTC
**Owner:** do truong giang


If there are several initialize and finalize done in a row in the same process, 
there is possibility getting SA_AIS_ERR_BAD_HANDLE.

[Test sequence]
1. saLogInitialize()
2. saLogFinalize()
3. saLogInitialize()
4. saLogFinalize()
--> get error SA_AIS_ERR_BAD_HANDLE

Here is the problem:

The finalize request will delete the requested client and the agent will wait 
for the answer (ack). If the last client initialized by this process is 
finalized the agent will free the resources used by the agent which means that 
the mds also is finalized which results in an agent down event on the server 
side.
The agent down message to the event handler is placed in the mailbox queue with 
the lowest priority.
In this test sequence the next thing that happens is that the agent is started 
again and a new initiate request is sent. When this request is received on the 
server the initialize message to the event handler is placed in the queue with 
the highest priority.

What happen in this case is that the event handler has not yet fetched the 
agent down message when the initiate message is queued which means that the 
order of handling the messages will be initialize (highest priority) and then 
agent down (lowest priority).
- The initialize will create a client
- The agent down will remove all clients for the agent  process including the 
just initialized
- The agent sends a finalize and gets BAD_HANDLE as a reply in the ack from the 
server since the client is already 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.--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1396 log: issue with priority of messages adding to mailbox in the server

2015-09-17 Thread elunlen 
- **status**: assigned --> accepted



---

** [tickets:#1396] log: issue with priority of messages adding to mailbox in 
the server**

**Status:** accepted
**Milestone:** 4.5.2
**Created:** Mon Jun 29, 2015 09:14 AM UTC by Vu Minh Nguyen
**Last Updated:** Thu Jul 23, 2015 03:25 AM UTC
**Owner:** do truong giang


If there are several initialize and finalize done in a row in the same process, 
there is possibility getting SA_AIS_ERR_BAD_HANDLE.

[Test sequence]
1. saLogInitialize()
2. saLogFinalize()
3. saLogInitialize()
4. saLogFinalize()
--> get error SA_AIS_ERR_BAD_HANDLE

Here is the problem:

The finalize request will delete the requested client and the agent will wait 
for the answer (ack). If the last client initialized by this process is 
finalized the agent will free the resources used by the agent which means that 
the mds also is finalized which results in an agent down event on the server 
side.
The agent down message to the event handler is placed in the mailbox queue with 
the lowest priority.
In this test sequence the next thing that happens is that the agent is started 
again and a new initiate request is sent. When this request is received on the 
server the initialize message to the event handler is placed in the queue with 
the highest priority.

What happen in this case is that the event handler has not yet fetched the 
agent down message when the initiate message is queued which means that the 
order of handling the messages will be initialize (highest priority) and then 
agent down (lowest priority).
- The initialize will create a client
- The agent down will remove all clients for the agent  process including the 
just initialized
- The agent sends a finalize and gets BAD_HANDLE as a reply in the ack from the 
server since the client is already 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.--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets