[tickets] [opensaf:tickets] #2600 log: logsv doesn't provide enough info when lgsv is busy in case change root directory

[Canh Truong via Opensaf-tickets]

---

** [tickets:#2600] log: logsv doesn't provide enough info when lgsv is busy in 
case change root directory **

**Status:** accepted
**Milestone:** 5.17.10
**Created:** Thu Sep 28, 2017 04:09 AM UTC by Canh Truong
**Last Updated:** Thu Sep 28, 2017 04:09 AM UTC
**Owner:** Canh Truong


In case change root directory (immcfg -a logRootDirectory=NEW_ROOT 
logConfig=1,safApp=safLogService), The "NEW_ROOT" need to be verify if it is 
writeable  in ccb_completed_callback by log server. But log server is busy in 
sometime, and log server does not provide info that user know to try again 
later.

This problem is happen sometime in test case logtest 5 2


---

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] #2599 smf: remove cascading delete for runtime objects

[Rafael Odzakow via Opensaf-tickets]

- Description has changed:

Diff:



--- old
+++ new
@@ -1,4 +1,6 @@
 Investigation needed. There is a lot of log spam on large installations when 
deleting these objects. It could be caused by SMF deleting individual elements 
instead of a parent root.
+
+Posted by Zoran from IMM:
 
 > The problem comes with cascade delete of SMF objects which contain many 
 > thousand objects.
 > When cascade delete is invoked, it shouldn't be deleted more than 1 
 > objects at once.






---

** [tickets:#2599] smf: remove cascading delete for runtime objects**

**Status:** unassigned
**Milestone:** 5.17.10
**Created:** Wed Sep 27, 2017 12:01 PM UTC by Rafael Odzakow
**Last Updated:** Wed Sep 27, 2017 12:01 PM UTC
**Owner:** Rafael Odzakow


Investigation needed. There is a lot of log spam on large installations when 
deleting these objects. It could be caused by SMF deleting individual elements 
instead of a parent root.

Posted by Zoran from IMM:

> The problem comes with cascade delete of SMF objects which contain many 
> thousand objects.
> When cascade delete is invoked, it shouldn't be deleted more than 1 
> objects at once.
> 
> All this is explained in IMM PR document, chapter 3.4, point 6.
> https://sourceforge.net/p/opensaf/documentation/ci/default/tree/OpenSAF_IMMSv_PR.odt
> 
> Adding Rafael Odzakow


---

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] #2599 smf: remove cascading delete for runtime objects

[Rafael Odzakow via Opensaf-tickets]

- Description has changed:

Diff:



--- old
+++ new
@@ -1,4 +1,3 @@
-
 Investigation needed. There is a lot of log spam on large installations when 
deleting these objects. It could be caused by SMF deleting individual elements 
instead of a parent root.
 
 > The problem comes with cascade delete of SMF objects which contain many 
 > thousand objects.



- **assigned_to**: Rafael Odzakow
- **Component**: unknown --> smf
- **Part**: - --> d
- **Priority**: major --> minor



---

** [tickets:#2599] smf: remove cascading delete for runtime objects**

**Status:** unassigned
**Milestone:** 5.17.10
**Created:** Wed Sep 27, 2017 12:01 PM UTC by Rafael Odzakow
**Last Updated:** Wed Sep 27, 2017 12:01 PM UTC
**Owner:** Rafael Odzakow


Investigation needed. There is a lot of log spam on large installations when 
deleting these objects. It could be caused by SMF deleting individual elements 
instead of a parent root.

> The problem comes with cascade delete of SMF objects which contain many 
> thousand objects.
> When cascade delete is invoked, it shouldn't be deleted more than 1 
> objects at once.
> 
> All this is explained in IMM PR document, chapter 3.4, point 6.
> https://sourceforge.net/p/opensaf/documentation/ci/default/tree/OpenSAF_IMMSv_PR.odt
> 
> Adding Rafael Odzakow


---

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] #2599 smf: remove cascading delete for runtime objects

[Rafael Odzakow via Opensaf-tickets]

---

** [tickets:#2599] smf: remove cascading delete for runtime objects**

**Status:** unassigned
**Milestone:** 5.17.10
**Created:** Wed Sep 27, 2017 12:01 PM UTC by Rafael Odzakow
**Last Updated:** Wed Sep 27, 2017 12:01 PM UTC
**Owner:** nobody



Investigation needed. There is a lot of log spam on large installations when 
deleting these objects. It could be caused by SMF deleting individual elements 
instead of a parent root.

> The problem comes with cascade delete of SMF objects which contain many 
> thousand objects.
> When cascade delete is invoked, it shouldn't be deleted more than 1 
> objects at once.
> 
> All this is explained in IMM PR document, chapter 3.4, point 6.
> https://sourceforge.net/p/opensaf/documentation/ci/default/tree/OpenSAF_IMMSv_PR.odt
> 
> Adding Rafael Odzakow


---

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] #2464 smf: try to wait for opensafd status before executing reboot

[Rafael Odzakow via Opensaf-tickets]

- **status**: review --> fixed
- **Comment**:

commit f3ef8eebf44f0eab4dcc65f83fe3119a77ef5067 (HEAD -> develop, 
origin/develop)
Author: Rafael Odzakow 
Date:   Mon Sep 25 13:52:03 2017 +0200

smf: try to wait for opensafd status before reboot [#2464]



---

** [tickets:#2464] smf: try to wait for opensafd status before executing reboot 
**

**Status:** fixed
**Milestone:** 5.17.10
**Created:** Fri May 19, 2017 10:55 AM UTC by Rafael Odzakow
**Last Updated:** Tue Sep 19, 2017 11:56 AM UTC
**Owner:** Rafael Odzakow


There are cases when opensafd startup is still ongoing and SMF will send out a 
reboot command for a node. Because opensafd has taken a lock the reboot command 
will not be able to call opensafd stop. It is suggested that SMF tries to wait 
for the release of the lock with "opensafd status". The waiting time is short 
and SMF continues with reboot even if the lock is not released.

ticket [#2459] allows SMF to query the status of opensafd. 


---

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

[Gary Lee via Opensaf-tickets]

- **status**: accepted --> review



---

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

**Status:** review
**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] #1443 log: service is crashed if creating and deleting conf obj class continuously

[Srinivas Siva Mangipudy via Opensaf-tickets]

- **status**: unassigned --> assigned
- **assigned_to**: Srinivas Siva Mangipudy
- **Blocker**:  --> False



---

** [tickets:#1443] log: service is crashed if creating and deleting conf obj 
class continuously**

**Status:** assigned
**Milestone:** future
**Created:** Tue Aug 11, 2015 07:37 AM UTC by Vu Minh Nguyen
**Last Updated:** Tue Sep 20, 2016 06:04 PM UTC
**Owner:** Srinivas Siva Mangipudy


When creating application object class and deleting it continuously, log 
service could be crashed.

To reproduce this case, perform following command.

> for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20; do immcfg -c 
> SaLogStreamConfig safLgStrCfg=TestLog -a saLogStreamPathName=. -a 
> saLogStreamFileName=TestLog; echo "create ($i) - $?"; immcfg -d 
> safLgStrCfg=TestLog; echo "Delete ($i) - $?"; done

Output something likes:
> create (1) - 0
> Delete (1) - 0
> create (2) - 0
> error - saImmOmCcbObjectDelete for 'safLgStrCfg= TestLog' FAILED: 
> SA_AIS_ERR_FAILED_OPERATION (21)
> error - saImmOmCcbApply FAILED: SA_AIS_ERR_FAILED_OPERATION (21)
> Delete (2) - 1
> error - saImmOmCcbObjectCreate_2 FAILED with SA_AIS_ERR_EXIST (14)
> create (3) - 1
> reboot: Restarting system

Here is the analysis:

1. When creating obj class is done by IMM, but logsv have not finished the 
`apply callback` job yet. 
In this case, it needs to update a run-time attribute ` 
saLogStreamCreationTimestamp`.
This is done in main thread.

2. If deleting this obj class comes before `apply callback` job finishes, IMM 
will
mark that obj class as `IMM_DELETE_LOCK` and call respective callbacks to logsv
and *wait for response*, but logsv is busy in doing `apply callback` in (1).

When the request `update runtime attribute` to IMM by logsv, IMM will returns 
TRY_AGAIN.

IMM waits for logsv response to release “IMM_DELETE_LOCK”, while logsv still 
get stuck
in `update rt attribute` as getting TRY_AGAIN. 

Consequently, logsv might be terminated if number of try-again is reached or 
delete action gets failed. 



---

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