[tickets] [opensaf:tickets] #2315 amfnd: invalid read in compdb.cc

2017-02-20 Thread Gary Lee 
- Description has changed:

Diff:



--- old
+++ new
@@ -14,7 +14,7 @@
 
 Possible fix:
 
-'''
+```
 diff --git a/src/amf/amfnd/compdb.cc b/src/amf/amfnd/compdb.cc
 --- a/src/amf/amfnd/compdb.cc
 +++ b/src/amf/amfnd/compdb.cc
@@ -26,4 +26,4 @@
  
if 
(immutil_getAttr(const_cast("saAmfCtDefInstantiationLevel"), 
attributes, 0, >saAmfCtDefInstantiationLevel) != SA_AIS_OK)
compt->saAmfCtDefInstantiationLevel = 0;
-'''
+```






---

** [tickets:#2315] amfnd: invalid read in compdb.cc**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Tue Feb 21, 2017 07:33 AM UTC by Gary Lee
**Last Updated:** Tue Feb 21, 2017 07:33 AM UTC
**Owner:** nobody


==500== Thread 1:
==500== Invalid read of size 8
==500==at 0x1939DD: avnd_comptype_delete(amf_comp_type*) (compdb.cc:751)
==500==by 0x196534: avnd_comptype_create(unsigned long long, std::string 
const&) (compdb.cc:948)
==500==by 0x197E6B: comp_init(avnd_comp_tag*, SaImmAttrValuesT_2 const**) 
(compdb.cc:1226)
==500==by 0x1995BC: avnd_comp_create(std::string const&, SaImmAttrValuesT_2 
const**, avnd_su_tag*) (compdb.cc:1422)
==500==by 0x19A347: avnd_comp_config_get_su(avnd_su_tag*) (compdb.cc:1558)
==500==by 0x1DF9B6: avnd_evt_avd_reg_su_evh(avnd_cb_tag*, avnd_evt_tag*) 
(su.cc:161)
==500==by 0x1C0DBC: avnd_evt_process(avnd_evt_tag*) (main.cc:667)
==500==by 0x1C098E: avnd_main_process() (main.cc:618)
==500==by 0x1BE7DD: main (main.cc:206)
==500==  Address 0x0 is not stack'd, malloc'd or (recently) free'd


Possible fix:

```
diff --git a/src/amf/amfnd/compdb.cc b/src/amf/amfnd/compdb.cc
--- a/src/amf/amfnd/compdb.cc
+++ b/src/amf/amfnd/compdb.cc
@@ -852,6 +852,7 @@ static amf_comp_type_t *avnd_comptype_cr
compt->saAmfCtDefInstantiateCmdArgv[i] = StrDup(str);
osafassert(compt->saAmfCtDefInstantiateCmdArgv[i]);
}
+   compt->saAmfCtDefInstantiateCmdArgv[i] = nullptr;
 
if 
(immutil_getAttr(const_cast("saAmfCtDefInstantiationLevel"), 
attributes, 0, >saAmfCtDefInstantiationLevel) != SA_AIS_OK)
compt->saAmfCtDefInstantiationLevel = 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.--
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] #2315 amfnd: invalid read in compdb.cc

2017-02-20 Thread Gary Lee 



---

** [tickets:#2315] amfnd: invalid read in compdb.cc**

**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Tue Feb 21, 2017 07:33 AM UTC by Gary Lee
**Last Updated:** Tue Feb 21, 2017 07:33 AM UTC
**Owner:** nobody


==500== Thread 1:
==500== Invalid read of size 8
==500==at 0x1939DD: avnd_comptype_delete(amf_comp_type*) (compdb.cc:751)
==500==by 0x196534: avnd_comptype_create(unsigned long long, std::string 
const&) (compdb.cc:948)
==500==by 0x197E6B: comp_init(avnd_comp_tag*, SaImmAttrValuesT_2 const**) 
(compdb.cc:1226)
==500==by 0x1995BC: avnd_comp_create(std::string const&, SaImmAttrValuesT_2 
const**, avnd_su_tag*) (compdb.cc:1422)
==500==by 0x19A347: avnd_comp_config_get_su(avnd_su_tag*) (compdb.cc:1558)
==500==by 0x1DF9B6: avnd_evt_avd_reg_su_evh(avnd_cb_tag*, avnd_evt_tag*) 
(su.cc:161)
==500==by 0x1C0DBC: avnd_evt_process(avnd_evt_tag*) (main.cc:667)
==500==by 0x1C098E: avnd_main_process() (main.cc:618)
==500==by 0x1BE7DD: main (main.cc:206)
==500==  Address 0x0 is not stack'd, malloc'd or (recently) free'd


Possible fix:

'''
diff --git a/src/amf/amfnd/compdb.cc b/src/amf/amfnd/compdb.cc
--- a/src/amf/amfnd/compdb.cc
+++ b/src/amf/amfnd/compdb.cc
@@ -852,6 +852,7 @@ static amf_comp_type_t *avnd_comptype_cr
compt->saAmfCtDefInstantiateCmdArgv[i] = StrDup(str);
osafassert(compt->saAmfCtDefInstantiateCmdArgv[i]);
}
+   compt->saAmfCtDefInstantiateCmdArgv[i] = nullptr;
 
if 
(immutil_getAttr(const_cast("saAmfCtDefInstantiationLevel"), 
attributes, 0, >saAmfCtDefInstantiationLevel) != SA_AIS_OK)
compt->saAmfCtDefInstantiationLevel = 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.--
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] #1640 Integrate IMM service with CLM

2017-02-20 Thread Neelakanta Reddy 
- **status**: accepted --> review
- **Comment**:

https://sourceforge.net/p/opensaf/mailman/message/35678680/



---

** [tickets:#1640] Integrate IMM service with CLM**

**Status:** review
**Milestone:** 5.2.FC
**Created:** Tue Dec 15, 2015 08:32 AM UTC by Mathi Naickan
**Last Updated:** Mon Jan 16, 2017 06:14 AM UTC
**Owner:** Neelakanta Reddy


IMM Behavior of CLM integration:
1.  section 3.3 of IMM Spec (A.02.01).
2.  SA_AIS_ERR_UNAVAILABLE return code for APIs in IMM Spec.

IMMA:
New IMMA version A.2.18 wil be introduced for the CLMS integration with IMMA.
SA_AIS_ERR_UNAVAILABLE will be returned when the CLMS service is not available,
as per the IMM specification.

IMMND:
Register for CLM Track callback. From the callback, CLM status information
will be sent to IMMA.

IMMD:
Register for CLM Track callback. When the CLM node leaves the cluster, the 
IMMND is 
removed from the IMMD internal database. IMMND node down is broadcasted to 
remaining 
IMMNDs in the cluster.


---

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] #2133 AMF: Rollback admin shutdown/lock SI operation if node failover

2017-02-20 Thread Nagendra Kumar 
- **status**: review --> fixed
- **Comment**:

changeset:   8592:f13798019501
tag: tip
user:Nagendra Kumar
date:Tue Feb 21 10:01:48 2017 +0530
summary: amfd: return TRY_AGAIN on rollback of shutdown admin op [#2133]

[staging:f13798]

Documentation Changes:
changeset:   208:f21e52b1f0d1
tag: tip
user:Nagendra Kumar
date:Tue Feb 21 10:28:42 2017 +0530
summary: amf: deviations on SI shutdown [#2133]

[staging:f21e52]




---

** [tickets:#2133] AMF: Rollback admin shutdown/lock SI operation if node 
failover**

**Status:** fixed
**Milestone:** 5.2.FC
**Created:** Thu Oct 20, 2016 06:49 PM UTC by Minh Hon Chau
**Last Updated:** Tue Feb 07, 2017 07:14 AM UTC
**Owner:** Nagendra Kumar


In scenario of shut down SI, delay QUIESCING csi callback, then reboot the node 
that hosting SU having pending this csi callback. The result of this operation 
looks differently between SGs
- For 2N: the SI Admin state is rollbacked to UNLOCK 
- For Nway: the SI Admin state moves to LOCKED
- In NpM: Haven't tested just browsing SG_NPM::node_fail_si_oper, looks SI 
Admin states rollbacks to UNLOCK

My question is whether the result of these scenario should be consistent? And 
what's the expected outcome?
Also, the handling of node_fail_si_oper for admin lock is not consistent. For 
2N, Admin state remains LOCKED, NpM rollbacks to UNLOCK


---

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] #2259 amf: support for si-swap admin op for N+M model.

2017-02-20 Thread Praveen 
- **status**: accepted --> review



---

** [tickets:#2259] amf: support for si-swap admin op for N+M model.**

**Status:** review
**Milestone:** 5.2.FC
**Created:** Wed Jan 11, 2017 06:13 AM UTC by Praveen
**Last Updated:** Mon Feb 20, 2017 08:59 AM UTC
**Owner:** Praveen


As per spec, SI_SWAP admin operation is applicable to a SI which is protected 
by SG of 2N, NWAY or NPM model. Current OpenSAF implementation already supports 
2N and N-WAY model.This enhancements is for supporting the admin operation on 
SI of N+M model SG. 

AMF B.04.01 spec writes about SI_SWAP armin operation for applicable red model 
in the section  "9.4.8 SA_AMF_ADMIN_SI_SWAP" page 386 of B.04.01 spec.  For N+M 
model, spec states that:
"If the designated SI is protected by a service group whose redundancy model is 
N+M,
the invocation of this administrative operation results in a complete swap of 
all active
and standby CSIs belonging to not just the designated SI but also to any other 
SI that
is assigned active to a service unit to which the designated SI is assigned 
active.
Application of this operation on an SI may potentially modify the standby 
assignments
of other SIs that are protected by the same service group, but are not assigned 
to the
service unit to which the SI in question is assigned active."

**Example configuration N+1 given in spec:**
In the same paragraph above in section 9.4.8 SA_AMF_ADMIN_SI_SWAP, one example 
is given how SI_SWAP will proceed in N+M model.
1) Four nodes U, V, W and X hosts S1, S2, S3 and S4 respectively.
2) There are three SIs SIA, SIB and SIC.
3) SIA is active in S1, SIB is active in S2 and SIC is active in S3.
4) All SIs are standby in S4.
5) SI_SWAP admin operation Flow for above configuration: As per spec , 
"If the swap operation is applied on SI A, the active assignment
for SI A shall be moved to Service Unit S4 on Node X, and the standby 
assignments
for SI A as well as that of SI C and SI B will be moved to Service Unit S1 on
Node U. The active assignments of SI C and SI B will remain on Service Unit S3 
(on
Node W) and Service Unit S2 (on Node V), respectively"
Here SU S1 will become quiesced for all active SIs  (only one SIA in this 
example). At this point of time, SU S4 is standby for SIB and SIC also but SU1 
is not quiesced for these two SIs. Due to this,  SIB and SIC will be removed 
from SU S4 and it will become active for SIA. Now SU S1 will be made standby 
for all quiesced SIs (only one SIA in this example).  Since standby assignments 
from SIB and SIC are getting removed during the course of this operation, SU S1 
will make standby for SIB and SIC by giving fresh assignments.
So in contrast to 2N redudancy model, flow of SI_SWAP operation in N+M 
model can lead to removal of standby assignments and also fresh assignments. 

**Notes on implementation: **
1)SI_SWAP operation will not be allowed if SI Equal distribution feature is 
enabled in the SG.
2)Since SI dep within SU is not suported in N+M model, AMF will not honour SI 
dep within SU while assigning Active or Quiesced HA state  during the admin 
operation.
3)Since Operation will lead to swap of all SIs assgined to the active SU, 
operation will be rejected if anyone of these SIs does not have standby 
assignments in some SU.
4) Operation will not be allowed if it will lead to violation of SG 
configuration attrbiutes: saAmfSGMaxActiveSIsperSU, saAmfSGMaxStandbySIsperSU, 
saAmfSGNumPrefActiveSUs and saAmfSGNumPrefStandbySUs.

**Changes in sg_npm_fsm.cc:** Some code related to switch operation is already 
present. The same code will resued and enhanced for implementation. Most of the 
code is under SI_OPER state of SG.

To be updated with more example configuration..


---

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] #2233 AMF: SG is unstable after component failover recovery

2017-02-20 Thread Minh Hon Chau 
- Description has changed:

Diff:



--- old
+++ new
@@ -1,7 +1,7 @@
 This issue occurs as component failover recovery in context of locking node.
 
 **Configuration and steps:**
-1- Set up 2N model, PL4 hosts SU4, PL5 hosts SU5, PL3 hosts SU5B. Si deps 
safSi=AmfDemoTwon2 depends safSi=AmfDemoTwon1 depends safSi=AmfDemoTwon
+1- Set up 2N model, PL4 hosts SU4, PL5 hosts SU5, PL3 hosts SU5B. 
 2- Bring up 2N app, SU4 has active assignment, SU5 has standby assignment
 3- Lock PL4
 4- Set a few seconds delay csi remove callback in component of SU4






---

** [tickets:#2233] AMF: SG is unstable after component failover recovery**

**Status:** review
**Milestone:** 5.0.2
**Labels:** unstable sg 
**Created:** Tue Dec 20, 2016 03:00 AM UTC by Minh Hon Chau
**Last Updated:** Mon Feb 20, 2017 12:59 AM UTC
**Owner:** Minh Hon Chau


This issue occurs as component failover recovery in context of locking node.

**Configuration and steps:**
1- Set up 2N model, PL4 hosts SU4, PL5 hosts SU5, PL3 hosts SU5B. 
2- Bring up 2N app, SU4 has active assignment, SU5 has standby assignment
3- Lock PL4
4- Set a few seconds delay csi remove callback in component of SU4
5- Set a few seconds delay quiesced csi set callback in component of SU5
6- When SU5 finishes active assignment, SU4 now receives assignment removal 
from amfd. In mean time, component failover report is triggered by component of 
SU5.
7- Now SU5 receives quiesced csi set callback from amfd
8- Release both callback in step 4 and 5

**Observation: **
SG unstable, could not repair failed SU (SU5) or lock/unlock any entities

At the time amfd process quiesced assignment response in REALIGN state, no 
action from amfd
> Dec 20 13:23:22.272043 osafamfd [487:sg_2n_fsm.cc:1448] >> 
> susi_success_sg_realign: 'safSu=SU5,safSg=AmfDemoTwon,safApp=AmfDemoTwon' 
> act=5, state=3
> Dec 20 13:23:22.272048 osafamfd [487:sg.cc:1756] TR 
> safSu=SU5,safSg=AmfDemoTwon,safApp=AmfDemoTwon found in 
> safSg=AmfDemoTwon,safApp=AmfDemoTwon
> Dec 20 13:23:22.272054 osafamfd [487:sg_2n_fsm.cc:0477] >> 
> avd_sg_2n_act_susi: 'safSg=AmfDemoTwon,safApp=AmfDemoTwon'
> Dec 20 13:23:22.272059 osafamfd [487:sg_2n_fsm.cc:0486] TR 
> si'safSi=AmfDemoTwon,safApp=AmfDemoTwon', 
> su'safSu=SU5,safSg=AmfDemoTwon,safApp=AmfDemoTwon', 
> si'safSi=AmfDemoTwon,safApp=AmfDemoTwon'
> Dec 20 13:23:22.272065 osafamfd [487:sg_2n_fsm.cc:0486] TR 
> si'safSi=AmfDemoTwonDep1,safApp=AmfDemoTwon', 
> su'safSu=SU5,safSg=AmfDemoTwon,safApp=AmfDemoTwon', 
> si'safSi=AmfDemoTwonDep1,safApp=AmfDemoTwon'
> Dec 20 13:23:22.272071 osafamfd [487:sg_2n_fsm.cc:0486] TR 
> si'safSi=AmfDemoTwonDep2,safApp=AmfDemoTwon', 
> su'safSu=SU5,safSg=AmfDemoTwon,safApp=AmfDemoTwon', 
> si'safSi=AmfDemoTwonDep2,safApp=AmfDemoTwon'
> Dec 20 13:23:22.272076 osafamfd [487:sg_2n_fsm.cc:0501] TR 
> su_1'safSu=SU5,safSg=AmfDemoTwon,safApp=AmfDemoTwon', su_2'(null)'
> Dec 20 13:23:22.272082 osafamfd [487:sg_2n_fsm.cc:0555] << 
> avd_sg_2n_act_susi: act: 'safSu=SU5,safSg=AmfDemoTwon,safApp=AmfDemoTwon', 
> stdby: '(null)'
> Dec 20 13:23:22.272087 osafamfd [487:sg_2n_fsm.cc:1862] << 
> susi_success_sg_realign: rc:1

In this sg fsm function, SU5 is expected as OUT_OF_SERVICE, but SU5 is 
currently IN_SERVICE
SU5 firstly is reported as OUT_OF_SERVICE from message su_oper_state[DISABLED] 
as part of component failover report
Dec 20 13:22:56.241508 osafamfd [487:sgproc.cc:0656] >> avd_su_oper_state_evh: 
id:56, node:2050f, 'safSu=SU5,safSg=AmfDemoTwon,safApp=AmfDemoTwon' state:2

The failed component is instantiated again, and generates another message 
su_oper_state[ENABLED], it sets SU5 back to IN_SERVICE
Dec 20 13:22:58.481319 osafamfd [487:sgproc.cc:0656] >> avd_su_oper_state_evh: 
id:62, node:2050f, 'safSu=SU5,safSg=AmfDemoTwon,safApp=AmfDemoTwon' state:1

SU5 should be OUT_OF_SERVICE when amfd orchestrates component failover 
recovery, which initiates QUIESCED assignment of SU5 first. If re-instantiation 
of failed component happens faster as in this test then the sg fsm results in 
unexpected sequence.



---

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] #2314 base: ncs_edp_sanamet doesn't handle arrays

2017-02-20 Thread Alex Jones 
- **status**: accepted --> review



---

** [tickets:#2314] base: ncs_edp_sanamet doesn't handle arrays**

**Status:** review
**Milestone:** 5.2.FC
**Created:** Mon Feb 20, 2017 07:19 PM UTC by Alex Jones
**Last Updated:** Mon Feb 20, 2017 07:19 PM UTC
**Owner:** Alex Jones


A recent change to ncs_edp_sanamet broke encode/decode for SaNameT arrays. 
These are used by PLM and MSG. PLM and MSG standby no longer come up in 5.1.0.

This ticket proposes to put back the old functionality for arrays, until it is 
clear how to properly solve this issue.


---

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] #2314 base: ncs_edp_sanamet doesn't handle arrays

2017-02-20 Thread Alex Jones 



---

** [tickets:#2314] base: ncs_edp_sanamet doesn't handle arrays**

**Status:** accepted
**Milestone:** 5.2.FC
**Created:** Mon Feb 20, 2017 07:19 PM UTC by Alex Jones
**Last Updated:** Mon Feb 20, 2017 07:19 PM UTC
**Owner:** Alex Jones


A recent change to ncs_edp_sanamet broke encode/decode for SaNameT arrays. 
These are used by PLM and MSG. PLM and MSG standby no longer come up in 5.1.0.

This ticket proposes to put back the old functionality for arrays, until it is 
clear how to properly solve this issue.


---

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] #2313 osaf: saflog function does not handle long record

2017-02-20 Thread Nguyen TK Luu 
- **status**: unassigned --> assigned
- **assigned_to**: Nguyen TK Luu



---

** [tickets:#2313] osaf: saflog function does not handle long record**

**Status:** assigned
**Milestone:** 5.0.2
**Created:** Fri Feb 17, 2017 06:45 AM UTC by Vu Minh Nguyen
**Last Updated:** Fri Feb 17, 2017 09:48 AM UTC
**Owner:** Nguyen TK Luu


`saflog` is a utility function provided for other OpenSAF services to write an 
log record to OpenSAF LOG.
The `logBuf` in that function is only limited to 255 bytes.

So, if writing an log record more than 255 bytes, the log record will be 
truncated and `logBufSize` will hold the string length of the log record it 
would have been written to. As the result, it leads to incosistence in 
`logBufSize` and `logBuf`, eventually getting `SA_AIS_INVALID_PARAM`.

So, to solve the problem, `logBuf` capacity should be extended to maximum log 
record size (65Kb) so that it can avoid log record truncation.


---

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] #2259 amf: support for si-swap admin op for N+M model.

2017-02-20 Thread Praveen 
Attached is version 1 of the patch (01_2259.patch) and a test configuration 
test_conf.xml.
This version works for the simple case when all SIs which are active in the 
designated SU ( where Si to be swaped is active)  have their standbys on same 
SU including the designated SI.
Only some successful swap operation is tested on this patch. Will be testing 
fault test cases from today. So there is possibility of improvement in this 
version 1 also.
Also working on an improved version 2 which will consider the case when active 
SIs of designated SU have their standbys on different SUs.


Attachments:

- 
[01_2259.patch](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/4013838e/fcd3/attachment/01_2259.patch)
 (11.6 kB; application/octet-stream)
- 
[test_conf.xml](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/4013838e/fcd3/attachment/test_conf.xml)
 (13.3 kB; text/xml)


---

** [tickets:#2259] amf: support for si-swap admin op for N+M model.**

**Status:** accepted
**Milestone:** 5.2.FC
**Created:** Wed Jan 11, 2017 06:13 AM UTC by Praveen
**Last Updated:** Tue Feb 07, 2017 08:48 AM UTC
**Owner:** Praveen


As per spec, SI_SWAP admin operation is applicable to a SI which is protected 
by SG of 2N, NWAY or NPM model. Current OpenSAF implementation already supports 
2N and N-WAY model.This enhancements is for supporting the admin operation on 
SI of N+M model SG. 

AMF B.04.01 spec writes about SI_SWAP armin operation for applicable red model 
in the section  "9.4.8 SA_AMF_ADMIN_SI_SWAP" page 386 of B.04.01 spec.  For N+M 
model, spec states that:
"If the designated SI is protected by a service group whose redundancy model is 
N+M,
the invocation of this administrative operation results in a complete swap of 
all active
and standby CSIs belonging to not just the designated SI but also to any other 
SI that
is assigned active to a service unit to which the designated SI is assigned 
active.
Application of this operation on an SI may potentially modify the standby 
assignments
of other SIs that are protected by the same service group, but are not assigned 
to the
service unit to which the SI in question is assigned active."

**Example configuration N+1 given in spec:**
In the same paragraph above in section 9.4.8 SA_AMF_ADMIN_SI_SWAP, one example 
is given how SI_SWAP will proceed in N+M model.
1) Four nodes U, V, W and X hosts S1, S2, S3 and S4 respectively.
2) There are three SIs SIA, SIB and SIC.
3) SIA is active in S1, SIB is active in S2 and SIC is active in S3.
4) All SIs are standby in S4.
5) SI_SWAP admin operation Flow for above configuration: As per spec , 
"If the swap operation is applied on SI A, the active assignment
for SI A shall be moved to Service Unit S4 on Node X, and the standby 
assignments
for SI A as well as that of SI C and SI B will be moved to Service Unit S1 on
Node U. The active assignments of SI C and SI B will remain on Service Unit S3 
(on
Node W) and Service Unit S2 (on Node V), respectively"
Here SU S1 will become quiesced for all active SIs  (only one SIA in this 
example). At this point of time, SU S4 is standby for SIB and SIC also but SU1 
is not quiesced for these two SIs. Due to this,  SIB and SIC will be removed 
from SU S4 and it will become active for SIA. Now SU S1 will be made standby 
for all quiesced SIs (only one SIA in this example).  Since standby assignments 
from SIB and SIC are getting removed during the course of this operation, SU S1 
will make standby for SIB and SIC by giving fresh assignments.
So in contrast to 2N redudancy model, flow of SI_SWAP operation in N+M 
model can lead to removal of standby assignments and also fresh assignments. 

**Notes on implementation: **
1)SI_SWAP operation will not be allowed if SI Equal distribution feature is 
enabled in the SG.
2)Since SI dep within SU is not suported in N+M model, AMF will not honour SI 
dep within SU while assigning Active or Quiesced HA state  during the admin 
operation.
3)Since Operation will lead to swap of all SIs assgined to the active SU, 
operation will be rejected if anyone of these SIs does not have standby 
assignments in some SU.
4) Operation will not be allowed if it will lead to violation of SG 
configuration attrbiutes: saAmfSGMaxActiveSIsperSU, saAmfSGMaxStandbySIsperSU, 
saAmfSGNumPrefActiveSUs and saAmfSGNumPrefStandbySUs.

**Changes in sg_npm_fsm.cc:** Some code related to switch operation is already 
present. The same code will resued and enhanced for implementation. Most of the 
code is under SI_OPER state of SG.

To be updated with more example configuration..


---

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