[tickets] [opensaf:tickets] #2591 imm: Admo id is not updated after resurrecting the client

2017-09-25 Thread Hung Nguyen via Opensaf-tickets



---

** [tickets:#2591] imm: Admo id is not updated after resurrecting the client**

**Status:** accepted
**Milestone:** 5.17.10
**Created:** Mon Sep 25, 2017 07:08 AM UTC by Hung Nguyen
**Last Updated:** Mon Sep 25, 2017 07:08 AM UTC
**Owner:** Hung Nguyen


Steps to reproduce:

1. OmAdminOwnerInitialize (ROF=False)
1. OmAdminOwnerSet 
1. Kill osafimmnd and wait for it to finishing syncing
1. OmAdminOperationInvoke returns ERR_BAD_HANDLE, it should return OK.


-


In admin_op_invoke_common(), admo id is obtained before checking for the client 
being stale.
~~~
  adminOwnerId = ao_node->mAdminOwnerId;
...
  if (cl_node->stale) {
... // If stale, ao_node->mAdminOwnerId my be upadted with new value here
  }
~~~

In case of the client being stale, new admo id will be retrieved from the 
server and set to ao_node->mAdminOwnerId.
adminOwnerId should be assigned after resurrecting.




---

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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #2592 smf: Upgrade nodes without using node group

2017-09-25 Thread elunlen via Opensaf-tickets



---

** [tickets:#2592] smf: Upgrade nodes without using node group**

**Status:** assigned
**Milestone:** 5.17.10
**Created:** Mon Sep 25, 2017 11:15 AM UTC by elunlen
**Last Updated:** Mon Sep 25, 2017 11:15 AM UTC
**Owner:** elunlen


After parallel lock handling was introduced a node group is always created when 
activation/deactivation units are nodes. This is also the case if the list of 
nodes only contains one node.
A problem is that old versions of AMF will crash and cause a cyclic node reboot 
since node groups are not handled correctly.
Change lock handling so that a node group is not used if only one node. This 
will make it possible to upgrade using rolling upgrade over nodes (only one 
node at a time)


---

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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #2593 uml: Add IPv6 support and update the kernel version

2017-09-25 Thread Anders Widell via Opensaf-tickets



---

** [tickets:#2593] uml: Add IPv6 support and update the kernel version**

**Status:** accepted
**Milestone:** 5.17.10
**Created:** Mon Sep 25, 2017 02:00 PM UTC by Anders Widell
**Last Updated:** Mon Sep 25, 2017 02:00 PM UTC
**Owner:** Anders Widell


Add support for IPv6 in UML, and update the linux kernel to the latest version 
(4.13).


---

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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #2590 CLM: Add user data in CLMSV_CLUSTER_JOIN_REQ message

2017-09-25 Thread Hans Nordebäck
- **status**: assigned --> review



---

** [tickets:#2590] CLM: Add user data in CLMSV_CLUSTER_JOIN_REQ message**

**Status:** review
**Milestone:** 5.17.10
**Created:** Fri Sep 22, 2017 11:40 AM UTC by Hans Nordebäck
**Last Updated:** Fri Sep 22, 2017 11:40 AM UTC
**Owner:** Hans Nordebäck


To join the clm cluster a CLMSV_CLUSTER_JOIN_REQ message is sent to clms. The 
message contains a node name read from file "node_name". The node name is e.g. 
passed on to the opensaf_scale_out script. To also send user data to the 
opensaf_scale_out script an additional file "user_data" is created and data can 
be added. The use case for this is e.g. sending software package version data, 
etc. for additional validation in the opensaf_scale_out script.  


---

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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #2593 uml: Add IPv6 support and update the kernel version

2017-09-25 Thread Anders Widell via Opensaf-tickets
- **status**: accepted --> review



---

** [tickets:#2593] uml: Add IPv6 support and update the kernel version**

**Status:** review
**Milestone:** 5.17.10
**Created:** Mon Sep 25, 2017 02:00 PM UTC by Anders Widell
**Last Updated:** Mon Sep 25, 2017 02:00 PM UTC
**Owner:** Anders Widell


Add support for IPv6 in UML, and update the linux kernel to the latest version 
(4.13).


---

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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #2585 AMF: Allow to delete SI and SI Dependency object in same CCB

2017-09-25 Thread Minh Hon Chau via Opensaf-tickets
- **status**: unassigned --> accepted
- **assigned_to**: Minh Hon Chau



---

** [tickets:#2585] AMF: Allow to delete SI and SI Dependency object in same 
CCB**

**Status:** accepted
**Milestone:** 5.17.10
**Created:** Wed Sep 20, 2017 06:47 AM UTC by Minh Hon Chau
**Last Updated:** Thu Sep 21, 2017 04:10 AM UTC
**Owner:** Minh Hon Chau


AMF today only allows users to delete SI if all SI Dependency objects 
(safDepend) related to the SI are deleted first. The CCB will be rejected if 
users delete both SI and safDepend objects in the same CCB.
There's a model migration use case that needs to delete all SIs and all related 
safDepend in the same CCB, provided that all SIs are unassigned.
This ticket enables this use case.
(to be updated)


---

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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #2594 AMF: Improve SC status change callback

2017-09-25 Thread Quyen Dao via Opensaf-tickets



---

** [tickets:#2594] AMF: Improve SC status change callback**

**Status:** accepted
**Milestone:** 5.17.10
**Created:** Tue Sep 26, 2017 02:34 AM UTC by Quyen Dao
**Last Updated:** Tue Sep 26, 2017 02:34 AM UTC
**Owner:** Quyen Dao


The SC status change callback declaration/definition is not consistent with 
other AMF callbacks.

1. It doesn't have an alias for callback type (defined by typdef) as the others

extern SaAisErrorT osafAmfInstallSCStatusChangeCallback(
 SaAmfHandleT amfHandle,
 void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT status));

2. Callback name is not correct. It should not end with T as it's not a type

static void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT state);

Beside that the current declaration/definition of SC status change call may 
cause issue for the script that automatically generates the python AIS 
interface in #2471 as it's not consistent with other AMF callbacks


---

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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #2594 AMF: Improve SC status change callback

2017-09-25 Thread Quyen Dao via Opensaf-tickets
- Description has changed:

Diff:



--- old
+++ new
@@ -1,12 +1,12 @@
 The SC status change callback declaration/definition is not consistent with 
other AMF callbacks.
 
-1. It doesn't have an alias for callback type (defined by typdef) as the others
+1.  It doesn't have an alias for callback type (defined by typdef) as the 
others
 
 extern SaAisErrorT osafAmfInstallSCStatusChangeCallback(
  SaAmfHandleT amfHandle,
  void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT status));
 
-2. Callback name is not correct. It should not end with T as it's not a type
+2.  Callback name is not correct. It should not end with T as it's not a type
 
 static void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT state);
 






---

** [tickets:#2594] AMF: Improve SC status change callback**

**Status:** accepted
**Milestone:** 5.17.10
**Created:** Tue Sep 26, 2017 02:34 AM UTC by Quyen Dao
**Last Updated:** Tue Sep 26, 2017 02:34 AM UTC
**Owner:** Quyen Dao


The SC status change callback declaration/definition is not consistent with 
other AMF callbacks.

1.  It doesn't have an alias for callback type (defined by typdef) as the others

extern SaAisErrorT osafAmfInstallSCStatusChangeCallback(
 SaAmfHandleT amfHandle,
 void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT status));

2.  Callback name is not correct. It should not end with T as it's not a type

static void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT state);

Beside that the current declaration/definition of SC status change call may 
cause issue for the script that automatically generates the python AIS 
interface in #2471 as it's not consistent with other AMF callbacks


---

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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #2594 AMF: Improve SC status change callback

2017-09-25 Thread Quyen Dao via Opensaf-tickets
- Description has changed:

Diff:



--- old
+++ new
@@ -1,12 +1,12 @@
 The SC status change callback declaration/definition is not consistent with 
other AMF callbacks.
 
-1.  It doesn't have an alias for callback type (defined by typdef) as the 
others
+1) It doesn't have an alias for callback type (defined by typdef) as the others
 
 extern SaAisErrorT osafAmfInstallSCStatusChangeCallback(
  SaAmfHandleT amfHandle,
  void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT status));
 
-2.  Callback name is not correct. It should not end with T as it's not a type
+2) Callback name is not correct. It should not end with T as it's not a type
 
 static void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT state);
 






---

** [tickets:#2594] AMF: Improve SC status change callback**

**Status:** accepted
**Milestone:** 5.17.10
**Created:** Tue Sep 26, 2017 02:34 AM UTC by Quyen Dao
**Last Updated:** Tue Sep 26, 2017 02:36 AM UTC
**Owner:** Quyen Dao


The SC status change callback declaration/definition is not consistent with 
other AMF callbacks.

1) It doesn't have an alias for callback type (defined by typdef) as the others

extern SaAisErrorT osafAmfInstallSCStatusChangeCallback(
 SaAmfHandleT amfHandle,
 void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT status));

2) Callback name is not correct. It should not end with T as it's not a type

static void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT state);

Beside that the current declaration/definition of SC status change call may 
cause issue for the script that automatically generates the python AIS 
interface in #2471 as it's not consistent with other AMF callbacks


---

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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #2594 AMF: Improve SC status change callback

2017-09-25 Thread Quyen Dao via Opensaf-tickets
- Description has changed:

Diff:



--- old
+++ new
@@ -2,12 +2,14 @@
 
 1) It doesn't have an alias for callback type (defined by typdef) as the others
 
+~~~
 extern SaAisErrorT osafAmfInstallSCStatusChangeCallback(
  SaAmfHandleT amfHandle,
  void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT status));
+~~~
 
 2) Callback name is not correct. It should not end with T as it's not a type
 
-static void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT state);
+`static void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT state);`
 
 Beside that the current declaration/definition of SC status change call may 
cause issue for the script that automatically generates the python AIS 
interface in #2471 as it's not consistent with other AMF callbacks






---

** [tickets:#2594] AMF: Improve SC status change callback**

**Status:** accepted
**Milestone:** 5.17.10
**Created:** Tue Sep 26, 2017 02:34 AM UTC by Quyen Dao
**Last Updated:** Tue Sep 26, 2017 02:39 AM UTC
**Owner:** Quyen Dao


The SC status change callback declaration/definition is not consistent with 
other AMF callbacks.

1) It doesn't have an alias for callback type (defined by typdef) as the others

~~~
extern SaAisErrorT osafAmfInstallSCStatusChangeCallback(
 SaAmfHandleT amfHandle,
 void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT status));
~~~

2) Callback name is not correct. It should not end with T as it's not a type

`static void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT state);`

Beside that the current declaration/definition of SC status change call may 
cause issue for the script that automatically generates the python AIS 
interface in #2471 as it's not consistent with other AMF callbacks


---

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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #2591 imm: Admo id is not updated after resurrecting the client

2017-09-25 Thread Hung Nguyen via Opensaf-tickets
- **status**: accepted --> review



---

** [tickets:#2591] imm: Admo id is not updated after resurrecting the client**

**Status:** review
**Milestone:** 5.17.10
**Created:** Mon Sep 25, 2017 07:08 AM UTC by Hung Nguyen
**Last Updated:** Mon Sep 25, 2017 07:08 AM UTC
**Owner:** Hung Nguyen


Steps to reproduce:

1. OmAdminOwnerInitialize (ROF=False)
1. OmAdminOwnerSet 
1. Kill osafimmnd and wait for it to finishing syncing
1. OmAdminOperationInvoke returns ERR_BAD_HANDLE, it should return OK.


-


In admin_op_invoke_common(), admo id is obtained before checking for the client 
being stale.
~~~
  adminOwnerId = ao_node->mAdminOwnerId;
...
  if (cl_node->stale) {
... // If stale, ao_node->mAdminOwnerId my be upadted with new value here
  }
~~~

In case of the client being stale, new admo id will be retrieved from the 
server and set to ao_node->mAdminOwnerId.
adminOwnerId should be assigned after resurrecting.




---

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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #2595 amfd: remove node_up variable from AVD_AVND

2017-09-25 Thread Gary Lee via Opensaf-tickets



---

** [tickets:#2595] amfd: remove node_up variable from AVD_AVND**

**Status:** accepted
**Milestone:** 5.17.10
**Created:** Tue Sep 26, 2017 03:12 AM UTC by Gary Lee
**Last Updated:** Tue Sep 26, 2017 03:12 AM UTC
**Owner:** Gary Lee


Ticket 2547 introduced a 'node_up' variable per node director, but this isn't 
checkpointed to the standby. Thus it may contain an invalid value after a 
failover. This can lead to premature deletion of the node from node_id_db. One 
side effect of this is the node oper state may not be set to disabled if the 
node is CLM locked.

We can just check for node_state == AVD_AVND_STATE_ABSENT, which is already 
checkpointed.



---

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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #2594 AMF: Improve SC status change callback

2017-09-25 Thread Quyen Dao via Opensaf-tickets
- **status**: accepted --> review



---

** [tickets:#2594] AMF: Improve SC status change callback**

**Status:** review
**Milestone:** 5.17.10
**Created:** Tue Sep 26, 2017 02:34 AM UTC by Quyen Dao
**Last Updated:** Tue Sep 26, 2017 02:39 AM UTC
**Owner:** Quyen Dao


The SC status change callback declaration/definition is not consistent with 
other AMF callbacks.

1) It doesn't have an alias for callback type (defined by typdef) as the others

~~~
extern SaAisErrorT osafAmfInstallSCStatusChangeCallback(
 SaAmfHandleT amfHandle,
 void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT status));
~~~

2) Callback name is not correct. It should not end with T as it's not a type

`static void (*OsafAmfSCStatusChangeCallbackT)(OsafAmfSCStatusT state);`

Beside that the current declaration/definition of SC status change call may 
cause issue for the script that automatically generates the python AIS 
interface in #2471 as it's not consistent with other AMF callbacks


---

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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #2407 amfnd: message ID mismatches during SC absence recovery

2017-09-25 Thread Gary Lee via Opensaf-tickets
- **status**: accepted --> not-reproducible
- **Blocker**:  --> False
- **Milestone**: 5.17.08 --> future



---

** [tickets:#2407] amfnd: message ID mismatches during SC absence recovery**

**Status:** not-reproducible
**Milestone:** future
**Created:** Fri Mar 31, 2017 08:55 AM UTC by Gary Lee
**Last Updated:** Mon Apr 10, 2017 01:40 PM UTC
**Owner:** Gary Lee


In a test case where the active SC is repeatedly powered off abruptly, 
sometimes this can be seen:

2017-03-27 21:42:38 PL-5 osafamfnd[422]: Rebooting OpenSAF NodeId = 0 EE Name = 
No EE Mapped, Reason: Message ID mismatch, rec 1, expected 2, OwnNodeId = 
132367, SupervisionTime = 60

2017-03-27 21:42:36 SC-1 osafamfd[510]: Started
2017-03-27 21:42:36 SC-1 osafamfd[510]: NO Received node_up from 2030f: msg_id 2
2017-03-27 21:42:36 SC-1 osafamfd[510]: NO Received node_up from 2030f: msg_id 2
2017-03-27 21:42:36 SC-1 osafamfd[510]: NO Received node_up_msg from all nodes
2017-03-27 21:42:36 SC-1 osafamfd[510]: NO Received node_up from 2040f: msg_id 2
2017-03-27 21:42:36 SC-1 osafamfd[510]: NO Received node_up from 2030f: msg_id 2
2017-03-27 21:42:36 SC-1 osafamfd[510]: NO Received node_up from 2050f: msg_id 2

```
2017-03-27 21:39:50 PL-5 osafamfnd[422]: Started
2017-03-27 21:39:50 PL-5 osafamfnd[422]: WA saClmInitialize_4 returned 31
2017-03-27 21:39:50 PL-5 osafamfnd[422]: NO Sending node up due to NCSMDS_UP
2017-03-27 21:39:51 PL-5 osafamfnd[422]: NO 
'safSu=PL-5,safSg=NoRed,safApp=OpenSAF' Presence State UNINSTANTIATED => 
INSTANTIATING
2017-03-27 21:39:51 PL-5 osafamfnd[422]: NO 
'safSu=PL-5,safSg=NoRed,safApp=OpenSAF' Presence State INSTANTIATING => 
INSTANTIATED
2017-03-27 21:39:51 PL-5 osafamfnd[422]: NO Assigning 
'safSi=NoRed2,safApp=OpenSAF' ACTIVE to 'safSu=PL-5,safSg=NoRed,safApp=OpenSAF'
2017-03-27 21:39:51 PL-5 osafamfnd[422]: NO Assigned 
'safSi=NoRed2,safApp=OpenSAF' ACTIVE to 'safSu=PL-5,safSg=NoRed,safApp=OpenSAF'
2017-03-27 21:40:00 PL-5 osafamfnd[422]: NO AVD NEW_ACTIVE, adest:1
2017-03-27 21:40:15 PL-5 osafamfnd[422]: message repeated 2 times: [ NO AVD 
NEW_ACTIVE, adest:1]
2017-03-27 21:40:19 PL-5 osafamfnd[422]: WA AMF director unexpectedly crashed
2017-03-27 21:40:19 PL-5 osafamfnd[422]: NO Checking 
'safSu=PL-5,safSg=NoRed,safApp=OpenSAF' for pending messages
2017-03-27 21:40:35 PL-5 osafamfnd[422]: NO AVD NEW_ACTIVE, adest:1
2017-03-27 21:40:35 PL-5 osafamfnd[422]: NO saClmDispatch BAD_HANDLE
2017-03-27 21:40:35 PL-5 osafamfnd[422]: NO 1 SISU states sent
2017-03-27 21:40:35 PL-5 osafamfnd[422]: NO 1 SU states sent
2017-03-27 21:40:35 PL-5 osafamfnd[422]: NO 5 CSICOMP states sent
2017-03-27 21:40:35 PL-5 osafamfnd[422]: NO 5 COMP states sent
2017-03-27 21:40:35 PL-5 osafamfnd[422]: NO Sending node up due to 
NCSMDS_NEW_ACTIVE
2017-03-27 21:40:40 PL-5 osafamfnd[422]: NO AVD NEW_ACTIVE, adest:1
2017-03-27 21:41:11 PL-5 osafamfnd[422]: message repeated 3 times: [ NO AVD 
NEW_ACTIVE, adest:1]
2017-03-27 21:41:18 PL-5 osafamfnd[422]: WA AMF director unexpectedly crashed
2017-03-27 21:41:18 PL-5 osafamfnd[422]: NO Checking 
'safSu=PL-5,safSg=NoRed,safApp=OpenSAF' for pending messages
2017-03-27 21:41:35 PL-5 osafamfnd[422]: NO AVD NEW_ACTIVE, adest:1
2017-03-27 21:41:35 PL-5 osafamfnd[422]: NO saClmDispatch BAD_HANDLE
2017-03-27 21:41:35 PL-5 osafamfnd[422]: NO 1 SISU states sent
2017-03-27 21:41:35 PL-5 osafamfnd[422]: NO 1 SU states sent
2017-03-27 21:41:35 PL-5 osafamfnd[422]: NO 5 CSICOMP states sent
2017-03-27 21:41:35 PL-5 osafamfnd[422]: NO 5 COMP states sent
2017-03-27 21:41:35 PL-5 osafamfnd[422]: NO Sending node up due to 
NCSMDS_NEW_ACTIVE
2017-03-27 21:41:43 PL-5 osafamfnd[422]: WA AMF director unexpectedly crashed
2017-03-27 21:41:43 PL-5 osafamfnd[422]: NO Checking 
'safSu=PL-5,safSg=NoRed,safApp=OpenSAF' for pending messages
2017-03-27 21:42:02 PL-5 osafamfnd[422]: NO AVD NEW_ACTIVE, adest:1
2017-03-27 21:42:02 PL-5 osafamfnd[422]: NO saClmDispatch BAD_HANDLE
2017-03-27 21:42:02 PL-5 osafamfnd[422]: NO 1 SISU states sent
2017-03-27 21:42:02 PL-5 osafamfnd[422]: NO 1 SU states sent
2017-03-27 21:42:02 PL-5 osafamfnd[422]: NO 5 CSICOMP states sent
2017-03-27 21:42:02 PL-5 osafamfnd[422]: NO 5 COMP states sent
2017-03-27 21:42:02 PL-5 osafamfnd[422]: NO Sending node up due to 
NCSMDS_NEW_ACTIVE
2017-03-27 21:42:12 PL-5 osafamfnd[422]: NO AVD NEW_ACTIVE, adest:1
2017-03-27 21:42:12 PL-5 osafamfnd[422]: NO saClmDispatch BAD_HANDLE
2017-03-27 21:42:36 PL-5 osafamfnd[422]: NO AVD NEW_ACTIVE, adest:1
2017-03-27 21:42:36 PL-5 osafamfnd[422]: NO saClmDispatch BAD_HANDLE
2017-03-27 21:42:38 PL-5 osafamfnd[422]: Rebooting OpenSAF NodeId = 0 EE Name = 
No EE Mapped, Reason: Message ID mismatch, rec 1, expected 2, OwnNodeId = 
132367, SupervisionTime = 60




2017-03-27 21:40:53 SC-2 osafamfd[477]: Started
2017-03-27 21:40:53 SC-2 osafamfnd[485]: NO Start monitoring AMFD using 
/var/lib/opensaf/osafamfd.fifo
2017-03-27 21:40:56 SC-2 osafamfd[477]: NO Cold sync complete!
2017-03-27 21:41:00 SC-2 osafamfd[477]: NO FAILOVER Stand