[tickets] [opensaf:tickets] Re: #2648 smf: smfd crashes after cluster reboot when campaign is in ExecutionCompleted

[Rafael Odzakow via Opensaf-tickets]

That would work. As long as it is possible to rollback the campaign it 
is fine.


On 10/20/2017 03:18 PM, Alex Jones wrote:
>
> I understand the intention. It makes sense.
>
> One of the other solutions I had considered is to put a check at the 
> beginning of SmfCampaign::initExecution(). If the campaign state is 
> EXECUTION_COMPLETED, then just return. What is the point of 
> reexecuting a campaign that already completed?
>
> Are you OK with that?
>
> 
>
> *[tickets:#2648]  
> smf: smfd crashes after cluster reboot when campaign is in 
> ExecutionCompleted*
>
> *Status:* review
> *Milestone:* 5.17.10
> *Created:* Thu Oct 19, 2017 06:45 PM UTC by Alex Jones
> *Last Updated:* Fri Oct 20, 2017 10:04 AM UTC
> *Owner:* Alex Jones
>
> smfd crashes in updateImmAttr because it returns NO_RESOURCES. Here is 
> how to reproduce:
>
>  1. enable PBE, and make sure the "disable" flag is set in
> OpenSafSmfConfig
>  2. execute an upgrade campaign, and let it go to "execution
> completed", but don't commit it
>  3. reboot the entire cluster
>  4. only allow 1 system controller to come up
>  5. smfd will attempt to re-execute the campaign
>  6. any writes to IMM (like setting an error because the campaign file
> can't be found) will fail with NO_RESOURCES and smfd will assert
> and crash
>
> The reason for the assert and crash is because PBE has not been turned 
> off by smfd before the campaign has been inititialized.
>
> 
>
> Sent from sourceforge.net because you indicated interest in 
> https://sourceforge.net/p/opensaf/tickets/2648/
>
> To unsubscribe from further messages, please visit 
> https://sourceforge.net/auth/subscriptions/
>




---

** [tickets:#2648] smf: smfd crashes after cluster reboot when campaign is in 
ExecutionCompleted**

**Status:** review
**Milestone:** 5.17.10
**Created:** Thu Oct 19, 2017 06:45 PM UTC by Alex Jones
**Last Updated:** Fri Oct 20, 2017 01:18 PM UTC
**Owner:** Alex Jones


smfd crashes in updateImmAttr because it returns NO_RESOURCES. Here is how to 
reproduce:

1. enable PBE, and make sure the "disable" flag is set in OpenSafSmfConfig
2. execute an upgrade campaign, and let it go to "execution completed", but 
don't commit it
3. reboot the entire cluster
4. only allow 1 system controller to come up
5. smfd will attempt to re-execute the campaign
6. any writes to IMM (like setting an error because the campaign file can't be 
found) will fail with NO_RESOURCES and smfd will assert and crash

The reason for the assert and crash is because PBE has not been turned off by 
smfd before the campaign has been inititialized.


---

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] #2648 smf: smfd crashes after cluster reboot when campaign is in ExecutionCompleted

[Rafael Odzakow via Opensaf-tickets]

A rollback will not work if a unexpected cluster-reboot was done before PBE was 
enabled. SMF looses its runtime data in that case, so your patch would cause 
issues for rollback. The intention is to be able to test the system and then 
decide to proceed with rollback or commit. That means reboots are allowed once 
the campaign is completed together with rollback.

I think the issue you are having needs a solution preferably in SMF but I'm not 
sure how that would look yet.


---

** [tickets:#2648] smf: smfd crashes after cluster reboot when campaign is in 
ExecutionCompleted**

**Status:** review
**Milestone:** 5.17.10
**Created:** Thu Oct 19, 2017 06:45 PM UTC by Alex Jones
**Last Updated:** Fri Oct 20, 2017 01:34 AM UTC
**Owner:** Alex Jones


smfd crashes in updateImmAttr because it returns NO_RESOURCES. Here is how to 
reproduce:

1. enable PBE, and make sure the "disable" flag is set in OpenSafSmfConfig
2. execute an upgrade campaign, and let it go to "execution completed", but 
don't commit it
3. reboot the entire cluster
4. only allow 1 system controller to come up
5. smfd will attempt to re-execute the campaign
6. any writes to IMM (like setting an error because the campaign file can't be 
found) will fail with NO_RESOURCES and smfd will assert and crash

The reason for the assert and crash is because PBE has not been turned off by 
smfd before the campaign has been inititialized.


---

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] #2633 smf: refactor smfd folders

[Rafael Odzakow via Opensaf-tickets]

- **summary**: smf: refactor smfd directory structure --> smf: refactor smfd 
folders



---

** [tickets:#2633] smf: refactor smfd folders**

**Status:** unassigned
**Milestone:** 5.17.10
**Created:** Tue Oct 17, 2017 11:52 AM UTC by Rafael Odzakow
**Last Updated:** Tue Oct 17, 2017 11:52 AM UTC
**Owner:** nobody





---

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] #2633 smf: refactor smfd directory structure

[Rafael Odzakow via Opensaf-tickets]

---

** [tickets:#2633] smf: refactor smfd directory structure**

**Status:** unassigned
**Milestone:** 5.17.10
**Created:** Tue Oct 17, 2017 11:52 AM UTC by Rafael Odzakow
**Last Updated:** Tue Oct 17, 2017 11:52 AM UTC
**Owner:** nobody





---

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] #1572 smf: Node by node upgrade

[Rafael Odzakow via Opensaf-tickets]

- **status**: accepted --> fixed
- **Blocker**:  --> False
- **Milestone**: 5.17.08 --> future



---

** [tickets:#1572] smf: Node by node upgrade**

**Status:** fixed
**Milestone:** future
**Created:** Wed Oct 28, 2015 06:44 AM UTC by Ingvar Bergström
**Last Updated:** Mon Apr 10, 2017 01:40 PM UTC
**Owner:** Rafael Odzakow


The puropse of this ticket is to decrease campaign execution time, without 
rewriting the campaign.

If configured, smfd will automatically upgrade the nodes one by one in a 
rolling manner, with actions fetched from all rolling procedures in the 
campaign.xml.

This will prevent the campaigns different procedures to roll over one and the 
same node/nodes several times i.e. a node will never be 
locked/unlocked/rebooted more than once.

The procedures are not allowed to have order dependencies to each other.

Single step procedures are leaved "as is" and executed before the new "node by 
node" procedure.

This is the second step in a three step upgrade time improvement plan.
1) One step upgrade. Delivered with ticket #1401 in OpenSAF 4.7
2) Node by node upgrade. This ticket.
3) TBD, Upgrade several nodes at a time in a rolling manner


---

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] #2622 base: double start failed

[Rafael Odzakow via Opensaf-tickets]

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



---

** [tickets:#2622] base: double start failed**

**Status:** fixed
**Milestone:** 5.17.10
**Created:** Tue Oct 10, 2017 11:29 AM UTC by Rafael Odzakow
**Last Updated:** Mon Oct 16, 2017 12:41 PM UTC
**Owner:** Rafael Odzakow


Previously named function "check_env" deletes pid file. Move it to after 
running pidofproc for amfnd pid.


---

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] #2622 base: double start failed

[Rafael Odzakow via Opensaf-tickets]

issue was found on ubuntu 14.04 where subsys folder is not created by default. 
Move the pid removal to be called after pidofproc.


---

** [tickets:#2622] base: double start failed**

**Status:** review
**Milestone:** 5.17.10
**Created:** Tue Oct 10, 2017 11:29 AM UTC by Rafael Odzakow
**Last Updated:** Tue Oct 10, 2017 11:31 AM UTC
**Owner:** Rafael Odzakow


Previously named function "check_env" deletes pid file. Move it to after 
running pidofproc for amfnd pid.


---

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] #2555 smf: execLevel for balanced upgrade

[Rafael Odzakow via Opensaf-tickets]

- **status**: assigned --> fixed



---

** [tickets:#2555] smf: execLevel for balanced upgrade**

**Status:** fixed
**Milestone:** 5.17.10
**Created:** Wed Aug 16, 2017 11:39 AM UTC by Rafael Odzakow
**Last Updated:** Fri Aug 18, 2017 03:57 PM UTC
**Owner:** Rafael Odzakow


Currently the SMF created balanced procedures get the highest execLevel and are 
therefore executed last in the chain. There are cases where it is needed to 
execute procedures after the balanced procedures are completed. To offer this 
feature SMF can check which execLevel existing procedures that are used for 
balanced upgrade have. Inserting the balanced procedure one step after the 
highest of those procedures. This would allow to configure procedures that are 
not part of the balanced group to be executed after a balanced procedure.


---

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] #2622 base: double start failed

[Rafael Odzakow via Opensaf-tickets]

- Description has changed:

Diff:



--- old
+++ new
@@ -1 +1 @@
-Previously named function "check_env" overwrites pid file. Move it to after 
running pidofproc for amfnd pid.
+Previously named function "check_env" deletes pid file. Move it to after 
running pidofproc for amfnd pid.






---

** [tickets:#2622] base: double start failed**

**Status:** review
**Milestone:** 5.17.10
**Created:** Tue Oct 10, 2017 11:29 AM UTC by Rafael Odzakow
**Last Updated:** Tue Oct 10, 2017 11:30 AM UTC
**Owner:** Rafael Odzakow


Previously named function "check_env" deletes pid file. Move it to after 
running pidofproc for amfnd pid.


---

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] #2622 double start failed

[Rafael Odzakow via Opensaf-tickets]

---

** [tickets:#2622] double start failed**

**Status:** review
**Milestone:** 5.17.10
**Created:** Tue Oct 10, 2017 11:29 AM UTC by Rafael Odzakow
**Last Updated:** Tue Oct 10, 2017 11:29 AM UTC
**Owner:** Rafael Odzakow


Previously named function "check_env" overwrites pid file. Move it to after 
running pidofproc for amfnd pid.


---

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] #2622 [base] double start failed

[Rafael Odzakow via Opensaf-tickets]

- **summary**: double start failed --> [base] double start failed



---

** [tickets:#2622] [base] double start failed**

**Status:** review
**Milestone:** 5.17.10
**Created:** Tue Oct 10, 2017 11:29 AM UTC by Rafael Odzakow
**Last Updated:** Tue Oct 10, 2017 11:29 AM UTC
**Owner:** Rafael Odzakow


Previously named function "check_env" overwrites pid file. Move it to after 
running pidofproc for amfnd pid.


---

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

[Rafael Odzakow via Opensaf-tickets]

- **status**: wontfix --> review
- **Comment**:

Seen again as protecting with mutexes and try again loops in opensafd nid 
script does not solve for when triggering node reboot as other services will be 
shutting down and causing unexpected errors. 



---

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

**Status:** review
**Milestone:** 5.17.10
**Created:** Fri May 19, 2017 10:55 AM UTC by Rafael Odzakow
**Last Updated:** Mon Aug 14, 2017 11:22 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] #2555 smf: execLevel for balanced upgrade

[Rafael Odzakow via Opensaf-tickets]

- Description has changed:

Diff:



--- old
+++ new
@@ -1 +1 @@
-Currently the SMF created balanced procedures get the highest execLevel and 
are therefore executed last in the chain. There are cases where it is needed to 
execute procedures after the balanced procedures are completed. To offer this 
feature SMF can check which execLevel existing procedures have and inserting 
the balanced procedures one step after those.
+Currently the SMF created balanced procedures get the highest execLevel and 
are therefore executed last in the chain. There are cases where it is needed to 
execute procedures after the balanced procedures are completed. To offer this 
feature SMF can check which execLevel existing procedures that are used for 
balanced upgrade have. Inserting the balanced procedure one step after the 
highest of those procedures. This would allow to configure procedures that are 
not part of the balanced group to be executed after a balanced procedure.






---

** [tickets:#2555] smf: execLevel for balanced upgrade**

**Status:** assigned
**Milestone:** 5.17.10
**Created:** Wed Aug 16, 2017 11:39 AM UTC by Rafael Odzakow
**Last Updated:** Thu Aug 17, 2017 10:18 AM UTC
**Owner:** Rafael Odzakow


Currently the SMF created balanced procedures get the highest execLevel and are 
therefore executed last in the chain. There are cases where it is needed to 
execute procedures after the balanced procedures are completed. To offer this 
feature SMF can check which execLevel existing procedures that are used for 
balanced upgrade have. Inserting the balanced procedure one step after the 
highest of those procedures. This would allow to configure procedures that are 
not part of the balanced group to be executed after a balanced procedure.


---

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] #2555 smf: execLevel for balanced upgrade

[Rafael Odzakow via Opensaf-tickets]

- **status**: unassigned --> assigned
- **assigned_to**: Rafael Odzakow



---

** [tickets:#2555] smf: execLevel for balanced upgrade**

**Status:** assigned
**Milestone:** 5.17.10
**Created:** Wed Aug 16, 2017 11:39 AM UTC by Rafael Odzakow
**Last Updated:** Wed Aug 16, 2017 11:39 AM UTC
**Owner:** Rafael Odzakow


Currently the SMF created balanced procedures get the highest execLevel and are 
therefore executed last in the chain. There are cases where it is needed to 
execute procedures after the balanced procedures are completed. To offer this 
feature SMF can check which execLevel existing procedures have and inserting 
the balanced procedures one step after those.


---

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] #2555 smf: execLevel for balanced upgrade

[Rafael Odzakow via Opensaf-tickets]

---

** [tickets:#2555] smf: execLevel for balanced upgrade**

**Status:** unassigned
**Milestone:** 5.17.10
**Created:** Wed Aug 16, 2017 11:39 AM UTC by Rafael Odzakow
**Last Updated:** Wed Aug 16, 2017 11:39 AM UTC
**Owner:** nobody


Currently the SMF created balanced procedures get the highest execLevel and are 
therefore executed last in the chain. There are cases where it is needed to 
execute procedures after the balanced procedures are completed. To offer this 
feature SMF can check which execLevel existing procedures have and inserting 
the balanced procedures one step after those.


---

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 --> wontfix
- **Comment**:

solved in base opensaf

commit a051496719a3c862594af17d88b082031dd53b33 (ticket-2459)



---

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

**Status:** wontfix
**Milestone:** 5.17.10
**Created:** Fri May 19, 2017 10:55 AM UTC by Rafael Odzakow
**Last Updated:** Fri Jul 28, 2017 08:24 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] #2441 smf: coredump and syslog flood after immnd crash

[Rafael Odzakow via Opensaf-tickets]

- **Comment**:

Setting it to minor until it shows up again.



---

** [tickets:#2441] smf: coredump and syslog flood after immnd crash**

**Status:** unassigned
**Milestone:** 5.17.10
**Created:** Thu Apr 27, 2017 09:05 AM UTC by Rafael Odzakow
**Last Updated:** Mon Aug 14, 2017 11:23 AM UTC
**Owner:** Rafael Odzakow


Seen in opensaf version: 183d7c379a8f
short ID: 8190

SMF shall handle the return code ERR_BAD_HANDLE in a better way probably by 
reinitializing and creating a new handle. ERR_BAD_HANDLE can happen when IMMND 
crashes and is still reinitializing.


These lines are flooding the system and trace log:
~~~
5:09:43.862034 osafsmfd 
[27207:../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/smfd_main.c:0107]
 WA Lock failed eith EBUSY pthread_mutex_trylock for imm 16
5:09:43.862042 osafsmfd 
[27207:../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/smfd_main.c:0101]
 >> smfd_imm_trylock
~~~


SMF backtrace

~~~
### BT FULL ###
#0 0x7f04a27e50c7 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x7f04a27e6478 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x7f04a4d1afee in __osafassert_fail (__file=, 
__line=, __func=, __assertion=) at 
../../../../../../opensaf/osaf/libs/core/leap/sysf_def.c:281
No locals.
#3 0x00411f8f in updateImmAttr (dn=, 
attributeName=0x47db5b "saSmfCmpgElapsedTime", 
attrValueType=SA_IMM_ATTR_SATIMET, value=0x1d89cb8) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/smfd_campaign_oi.cc:773
rc = SA_AIS_ERR_BAD_OPERATION
__FUNCTION__ = "updateImmAttr"
#4 0x0040f129 in SmfCampaign::updateElapsedTime 
(this=this@entry=0x1d89c90) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfCampaign.cc:930
updateTime = 
diffTime = 
timeStamp = {
tv_sec = 1490843664,
tv_usec = 109102
}
#5 0x0040f169 in SmfCampaign::stopElapsedTime (this=0x1d89c90) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfCampaign.cc:958
No locals.
#6 0x00440bee in SmfCampState::changeState 
(this=this@entry=0x7f048c014b70, i_camp=i_camp@entry=0x7f048c001220, 
i_state=0x7f048c00d3d0) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfCampState.cc:224
__FUNCTION__ = "changeState"
newState = {
static npos = ,
_M_dataplus = {
 = {
<__gnu_cxx::new_allocator> = {}, },
members of std::basic_string::_Alloc_hider:
_M_p = 0x7f048c12ae48 "SmfCampStateExecFailed"
}
}
oldState = {
static npos = ,
_M_dataplus = {
 = {
<__gnu_cxx::new_allocator> = {}, },
members of std::basic_string::_Alloc_hider:
_M_p = 0x7f048c02f108 "SmfCampStateExecuting"
}
}
#7 0x00443faa in SmfCampStateExecuting::procResult 
(this=0x7f048c014b70, i_camp=0x7f048c001220, i_procedure=, 
i_result=) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfCampState.cc:947
error = {
static npos = ,
_M_dataplus = {
 = {
<__gnu_cxx::new_allocator> = {}, },
members of std::basic_string::_Alloc_hider:
_M_p = 0x7f048c010f48 "Procedure safSmfProc=SingleStep_upgrade_SCs failed"
}
}
__FUNCTION__ = "procResult"
result = 
#8 0x0042500a in SmfUpgradeCampaign::procResult (this=0x7f048c001220, 
i_procedure=0x7f048c10afe0, i_result=SMF_PROC_FAILED) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc:955
__FUNCTION__ = "procResult"
campResult = 
#9 0x0040cdb1 in SmfCampaignThread::processEvt (this=0x1d8d310) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc:653
evt = 0x7f0490001b40
#10 0x0040cf48 in SmfCampaignThread::handleEvents 
(this=this@entry=0x1d8d310) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc:699
ret = 
__FUNCTION__ = "handleEvents"
fds = {{
fd = 25,
events = 1,
revents = 1
}}
#11 0x00408253 in SmfCampaignThread::main (this=this@entry=0x1d8d310) 
at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc:760
__FUNCTION__ = "main"
#12 0x00408352 in SmfCampaignThread::main (info=0x1d8d310) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc:109
__FUNCTION__ = "main"
self = 0x1d8d310
#13 0x7f04a3a110a4 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#14 0x7f04a289502d in clone () from /lib64/libc.so.6
No symbol table info available.

The following lines flooded all syslog messages of SC-1
Mar 30 5:09:43.862001 osafsmfd 
[27207:../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/smfd_main.c:0101]
 >> smfd_imm_trylock
Mar 30 5:09:43.862034 osafsmfd 
[27207:../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/smfd_main.c:0107]
 WA Lock failed eith EBUSY pthread_mutex_trylock for imm 16

Coredump happened:
Mar 30 5:14:24.109139 osafsmfd 

[tickets] [opensaf:tickets] #2441 smf: coredump and syslog flood after immnd crash

[Rafael Odzakow via Opensaf-tickets]

- **Priority**: major --> minor



---

** [tickets:#2441] smf: coredump and syslog flood after immnd crash**

**Status:** unassigned
**Milestone:** 5.17.10
**Created:** Thu Apr 27, 2017 09:05 AM UTC by Rafael Odzakow
**Last Updated:** Fri Jul 28, 2017 08:25 AM UTC
**Owner:** Rafael Odzakow


Seen in opensaf version: 183d7c379a8f
short ID: 8190

SMF shall handle the return code ERR_BAD_HANDLE in a better way probably by 
reinitializing and creating a new handle. ERR_BAD_HANDLE can happen when IMMND 
crashes and is still reinitializing.


These lines are flooding the system and trace log:
~~~
5:09:43.862034 osafsmfd 
[27207:../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/smfd_main.c:0107]
 WA Lock failed eith EBUSY pthread_mutex_trylock for imm 16
5:09:43.862042 osafsmfd 
[27207:../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/smfd_main.c:0101]
 >> smfd_imm_trylock
~~~


SMF backtrace

~~~
### BT FULL ###
#0 0x7f04a27e50c7 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x7f04a27e6478 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x7f04a4d1afee in __osafassert_fail (__file=, 
__line=, __func=, __assertion=) at 
../../../../../../opensaf/osaf/libs/core/leap/sysf_def.c:281
No locals.
#3 0x00411f8f in updateImmAttr (dn=, 
attributeName=0x47db5b "saSmfCmpgElapsedTime", 
attrValueType=SA_IMM_ATTR_SATIMET, value=0x1d89cb8) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/smfd_campaign_oi.cc:773
rc = SA_AIS_ERR_BAD_OPERATION
__FUNCTION__ = "updateImmAttr"
#4 0x0040f129 in SmfCampaign::updateElapsedTime 
(this=this@entry=0x1d89c90) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfCampaign.cc:930
updateTime = 
diffTime = 
timeStamp = {
tv_sec = 1490843664,
tv_usec = 109102
}
#5 0x0040f169 in SmfCampaign::stopElapsedTime (this=0x1d89c90) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfCampaign.cc:958
No locals.
#6 0x00440bee in SmfCampState::changeState 
(this=this@entry=0x7f048c014b70, i_camp=i_camp@entry=0x7f048c001220, 
i_state=0x7f048c00d3d0) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfCampState.cc:224
__FUNCTION__ = "changeState"
newState = {
static npos = ,
_M_dataplus = {
 = {
<__gnu_cxx::new_allocator> = {}, },
members of std::basic_string::_Alloc_hider:
_M_p = 0x7f048c12ae48 "SmfCampStateExecFailed"
}
}
oldState = {
static npos = ,
_M_dataplus = {
 = {
<__gnu_cxx::new_allocator> = {}, },
members of std::basic_string::_Alloc_hider:
_M_p = 0x7f048c02f108 "SmfCampStateExecuting"
}
}
#7 0x00443faa in SmfCampStateExecuting::procResult 
(this=0x7f048c014b70, i_camp=0x7f048c001220, i_procedure=, 
i_result=) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfCampState.cc:947
error = {
static npos = ,
_M_dataplus = {
 = {
<__gnu_cxx::new_allocator> = {}, },
members of std::basic_string::_Alloc_hider:
_M_p = 0x7f048c010f48 "Procedure safSmfProc=SingleStep_upgrade_SCs failed"
}
}
__FUNCTION__ = "procResult"
result = 
#8 0x0042500a in SmfUpgradeCampaign::procResult (this=0x7f048c001220, 
i_procedure=0x7f048c10afe0, i_result=SMF_PROC_FAILED) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc:955
__FUNCTION__ = "procResult"
campResult = 
#9 0x0040cdb1 in SmfCampaignThread::processEvt (this=0x1d8d310) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc:653
evt = 0x7f0490001b40
#10 0x0040cf48 in SmfCampaignThread::handleEvents 
(this=this@entry=0x1d8d310) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc:699
ret = 
__FUNCTION__ = "handleEvents"
fds = {{
fd = 25,
events = 1,
revents = 1
}}
#11 0x00408253 in SmfCampaignThread::main (this=this@entry=0x1d8d310) 
at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc:760
__FUNCTION__ = "main"
#12 0x00408352 in SmfCampaignThread::main (info=0x1d8d310) at 
../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc:109
__FUNCTION__ = "main"
self = 0x1d8d310
#13 0x7f04a3a110a4 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#14 0x7f04a289502d in clone () from /lib64/libc.so.6
No symbol table info available.

The following lines flooded all syslog messages of SC-1
Mar 30 5:09:43.862001 osafsmfd 
[27207:../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/smfd_main.c:0101]
 >> smfd_imm_trylock
Mar 30 5:09:43.862034 osafsmfd 
[27207:../../../../../../../opensaf/osaf/services/saf/smfsv/smfd/smfd_main.c:0107]
 WA Lock failed eith EBUSY pthread_mutex_trylock for imm 16

Coredump happened:
Mar 30 5:14:24.109139 osafsmfd 
[27207:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_oi_api.c:2519]

[tickets] [opensaf:tickets] #2541 nid: order of system log print out is not correct

[Rafael Odzakow via Opensaf-tickets]

---

** [tickets:#2541] nid: order of system log print out is not correct**

**Status:** review
**Milestone:** 5.17.10
**Created:** Wed Aug 02, 2017 07:52 AM UTC by Rafael Odzakow
**Last Updated:** Wed Aug 02, 2017 07:52 AM UTC
**Owner:** Rafael Odzakow


using echo -n in opensafd causes delay write to log in a systemd environment 
causing unconsistent order of the logs. "Starting opensaf" will end up after 
"Startup finished" in the system log.


---

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] #2521 smf: no node locking when procedures are empty

[Rafael Odzakow via Opensaf-tickets]

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



---

** [tickets:#2521] smf: no node locking when procedures are empty**

**Status:** fixed
**Milestone:** 5.17.10
**Created:** Wed Jul 05, 2017 09:13 AM UTC by Rafael Odzakow
**Last Updated:** Wed Jul 19, 2017 10:08 AM UTC
**Owner:** Rafael Odzakow


procedures can be empty to improve uptime SMF should not lock nodes in that 
case.


---

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] #2521 smf: no node locking when procedures are empty

[Rafael Odzakow via Opensaf-tickets]

for rolling upgrades only

commit 653edb5d9b217f1a3280b5aed8597fb53ffa5f61



---

** [tickets:#2521] smf: no node locking when procedures are empty**

**Status:** review
**Milestone:** 5.17.10
**Created:** Wed Jul 05, 2017 09:13 AM UTC by Rafael Odzakow
**Last Updated:** Thu Jul 13, 2017 03:20 PM UTC
**Owner:** Rafael Odzakow


procedures can be empty to improve uptime SMF should not lock nodes in that 
case.


---

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] #2451 clm: Make the cluster reset admin op safe

[Rafael Odzakow via Opensaf-tickets]

For rolling upgrades only

commit 653edb5d9b217f1a3280b5aed8597fb53ffa5f61 (HEAD -> develop, 
origin/develop, ticket-2521)
Author: Rafael Odzakow 
Date:   Wed Jul 19 11:52:57 2017 +0200

smf: no node locking when procedures are empty [#2521]



---

** [tickets:#2451] clm: Make the cluster reset admin op safe**

**Status:** unassigned
**Milestone:** 5.17.10
**Created:** Wed May 03, 2017 10:51 AM UTC by Anders Widell
**Last Updated:** Sat Jul 01, 2017 04:15 PM UTC
**Owner:** nobody


The cluster reset admin operation that was implemented in ticket [#2053] is not 
safe: if a node reboots very fast it can come up again and join the old cluster 
before other nodes have rebooted. See mail discussion:

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

This can be solved by implementing a two-phase cluster reset or by introducing 
a cluster generation number which is increased at each cluster reset (maybe 
both ordered an spontaneous cluster resets). A node will not be allowed to join 
the cluster with a different cluster genration without first rebooting.


---

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] #2521 smf: no node locking when procedures are empty

[Rafael Odzakow via Opensaf-tickets]

- **status**: assigned --> review



---

** [tickets:#2521] smf: no node locking when procedures are empty**

**Status:** review
**Milestone:** 5.17.10
**Created:** Wed Jul 05, 2017 09:13 AM UTC by Rafael Odzakow
**Last Updated:** Thu Jul 13, 2017 03:20 PM UTC
**Owner:** Rafael Odzakow


procedures can be empty to improve uptime SMF should not lock nodes in that 
case.


---

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] #2521 smf: no node locking when procedures are empty

[Rafael Odzakow via Opensaf-tickets]

- **summary**: smf: remove node locking with empty procedures --> smf: no node 
locking when procedures are empty
- Description has changed:

Diff:



--- old
+++ new
@@ -0,0 +1 @@
+procedures can be empty to improve uptime SMF should not lock nodes in that 
case.






---

** [tickets:#2521] smf: no node locking when procedures are empty**

**Status:** assigned
**Milestone:** 5.17.10
**Created:** Wed Jul 05, 2017 09:13 AM UTC by Rafael Odzakow
**Last Updated:** Fri Jul 07, 2017 08:29 AM UTC
**Owner:** Rafael Odzakow


procedures can be empty to improve uptime SMF should not lock nodes in that 
case.


---

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] #2521 smf: remove node locking with empty procedures

[Rafael Odzakow via Opensaf-tickets]

- **status**: unassigned --> assigned



---

** [tickets:#2521] smf: remove node locking with empty procedures**

**Status:** assigned
**Milestone:** 5.17.10
**Created:** Wed Jul 05, 2017 09:13 AM UTC by Rafael Odzakow
**Last Updated:** Wed Jul 05, 2017 09:13 AM UTC
**Owner:** 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] #2521 smf: remove node locking with empty procedures

[Rafael Odzakow via Opensaf-tickets]

---

** [tickets:#2521] smf: remove node locking with empty procedures**

**Status:** unassigned
**Milestone:** 5.17.10
**Created:** Wed Jul 05, 2017 09:13 AM UTC by Rafael Odzakow
**Last Updated:** Wed Jul 05, 2017 09:13 AM UTC
**Owner:** 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] #2499 SMF: 20 seconds timeout in getting node destination is not enough

[Rafael Odzakow via Opensaf-tickets]

- **status**: unassigned --> fixed
- **assigned_to**: Rafael Odzakow
- **Comment**:

fixed in 
commit 3e1d1091270fa83cb8efe5458d6050b56f41f001
Author: Rafael Odzakow 
Date:   Fri Jun 30 10:57:36 2017 +0200

smf: 20 seconds timeout in getting node destination is not enough [#2499]




---

** [tickets:#2499] SMF: 20 seconds timeout in getting node destination is not 
enough**

**Status:** fixed
**Milestone:** 5.17.08
**Created:** Fri Jun 16, 2017 08:04 AM UTC by Tai Dinh
**Last Updated:** Wed Jun 28, 2017 02:21 PM UTC
**Owner:** Rafael Odzakow


We're now using a hard coded timeout value (20 seconds) in getting node 
destination.
This is sometimes not enough especially in cluster reboot procedure. Controller 
may come up first and continue the campaign without waiting for the rest to be 
up.
This can make the getNodeDestination() fail sometimes, especially for a large 
cluster.
In our case, it needs 3 more seconds.

I guess this timeout need to be increased or should be configurable.
Reuse some existing attribute for this purpose is also fine, e.g: 
smfRebootTimeout.

/Tai


---

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] #2451 clm: Make the cluster reset admin op safe

[Rafael Odzakow via Opensaf-tickets]

For the node that is not allowed to join the CLM cluster will this solution 
also block IMM (and other services) from starting up?


---

** [tickets:#2451] clm: Make the cluster reset admin op safe**

**Status:** unassigned
**Milestone:** 5.17.08
**Created:** Wed May 03, 2017 10:51 AM UTC by Anders Widell
**Last Updated:** Wed May 03, 2017 10:51 AM UTC
**Owner:** nobody


The cluster reset admin operation that was implemented in ticket [#2053] is not 
safe: if a node reboots very fast it can come up again and join the old cluster 
before other nodes have rebooted. See mail discussion:

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

This can be solved by implementing a two-phase cluster reset or by introducing 
a cluster generation number which is increased at each cluster reset (maybe 
both ordered an spontaneous cluster resets). A node will not be allowed to join 
the cluster with a different cluster genration without first rebooting.


---

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] #2499 SMF: 20 seconds timeout in getting node destination is not enough

[Rafael Odzakow via Opensaf-tickets]

This issue is as far as I could see a bug. In other campaign sequences SMF will 
wait with rebootTimeout before doing any operation after reboot. In this 
campaign sequence the first operation type after a reboot was to to a CLI 
command on a payload node. This timed out because the CLI command is not 
wrapped in a retry using the rebootTimeout of SMF. 

SMF does not keep track of all nodes after a cluster reboot therefore the 
mechanism for handling a cluster reboot is to wrap any operations that is done 
after a reboot in a retry loop.



---

** [tickets:#2499] SMF: 20 seconds timeout in getting node destination is not 
enough**

**Status:** unassigned
**Milestone:** 5.17.08
**Created:** Fri Jun 16, 2017 08:04 AM UTC by Tai Dinh
**Last Updated:** Wed Jun 21, 2017 03:58 AM UTC
**Owner:** nobody


We're now using a hard coded timeout value (20 seconds) in getting node 
destination.
This is sometimes not enough especially in cluster reboot procedure. Controller 
may come up first and continue the campaign without waiting for the rest to be 
up.
This can make the getNodeDestination() fail sometimes, especially for a large 
cluster.
In our case, it needs 3 more seconds.

I guess this timeout need to be increased or should be configurable.
Reuse some existing attribute for this purpose is also fine, e.g: 
smfRebootTimeout.

/Tai


---

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] #2459 try-again for opensafd stop

[Rafael Odzakow via Opensaf-tickets]

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

commit a051496719a3c862594af17d88b082031dd53b33 (ticket-2459)

base: Try again for opensafd stop [#2459]

Internally opensafd creates a mutex during start/stop to avoid parallel
execution. Makes mutex more robust and add a short retry if mutex is
taken.

















---

** [tickets:#2459] try-again for opensafd stop**

**Status:** fixed
**Milestone:** 5.17.08
**Created:** Thu May 11, 2017 12:42 PM UTC by Rafael Odzakow
**Last Updated:** Tue Jun 13, 2017 08:01 AM UTC
**Owner:** Rafael Odzakow


Today there is no way for SMF (or others) to know when opensafd start is 
completed. Calling stop when a start is ongoing will not stop opensafd so the 
reboot will not shutdown opensafd. Resulting in errors reports from several 
components.

Internally opensafd creates a lock file during start/stop. Internally implement 
a try-again loop that will use the opensafd lockfile.


---

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] Re: #2499 SMF: 20 seconds timeout in getting node destination is not enough

[Rafael Odzakow via Opensaf-tickets]

Going for a short vacation, here is the untested patch. Use rebootTimeout to 
increase the timeout for it.

commit 2ffbd1c5cd3f4193fd631130eef60b17c92892e6 (HEAD -> ticket-2499)
Author: Rafael Odzakow 
Date:   Tue Jun 20 16:10:12 2017 +0200

smf: 20 seconds timeout in getting node destination is not enough [#2499]

diff --git a/src/smf/smfd/SmfUpgradeStep.cc b/src/smf/smfd/SmfUpgradeStep.cc
index 2ffeab110..a99c7661a 100644
--- a/src/smf/smfd/SmfUpgradeStep.cc
+++ b/src/smf/smfd/SmfUpgradeStep.cc
@@ -1966,7 +1966,7 @@ bool SmfUpgradeStep::callActivationCmd() {
   TRACE("Get node destination for %s", getSwNode().c_str());
   uint32_t rc;

-  if (!getNodeDestination(getSwNode(), , NULL, -1)) {
+  if (!waitForNodeDestination(getSwNode(), )) {
 LOG_NO("no node destination found for node %s", getSwNode().c_str());
 result = false;
 goto done;



---

** [tickets:#2499] SMF: 20 seconds timeout in getting node destination is not 
enough**

**Status:** unassigned
**Milestone:** 5.17.08
**Created:** Fri Jun 16, 2017 08:04 AM UTC by Tai Dinh
**Last Updated:** Tue Jun 20, 2017 03:03 AM UTC
**Owner:** nobody


We're now using a hard coded timeout value (20 seconds) in getting node 
destination.
This is sometimes not enough especially in cluster reboot procedure. Controller 
may come up first and continue the campaign without waiting for the rest to be 
up.
This can make the getNodeDestination() fail sometimes, especially for a large 
cluster.
In our case, it needs 3 more seconds.

I guess this timeout need to be increased or should be configurable.
Reuse some existing attribute for this purpose is also fine, e.g: 
smfRebootTimeout.

/Tai


---

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] Re: #2499 SMF: 20 seconds timeout in getting node destination is not enough

[Rafael Odzakow via Opensaf-tickets]

It should be enough to wrap getNodeDestination in waitForGetNodeDestination in 
SmfCliCommandAction::execute(). Other getNodeDestination calls are not needing 
to wait for nodes or have custom code for retry.


---

** [tickets:#2499] SMF: 20 seconds timeout in getting node destination is not 
enough**

**Status:** unassigned
**Milestone:** 5.17.08
**Created:** Fri Jun 16, 2017 08:04 AM UTC by Tai Dinh
**Last Updated:** Tue Jun 20, 2017 03:03 AM UTC
**Owner:** nobody


We're now using a hard coded timeout value (20 seconds) in getting node 
destination.
This is sometimes not enough especially in cluster reboot procedure. Controller 
may come up first and continue the campaign without waiting for the rest to be 
up.
This can make the getNodeDestination() fail sometimes, especially for a large 
cluster.
In our case, it needs 3 more seconds.

I guess this timeout need to be increased or should be configurable.
Reuse some existing attribute for this purpose is also fine, e.g: 
smfRebootTimeout.

/Tai


---

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] Re: #2499 SMF: 20 seconds timeout in getting node destination is not enough

[Rafael Odzakow via Opensaf-tickets]

If you have the logs please send them my way. 


---

** [tickets:#2499] SMF: 20 seconds timeout in getting node destination is not 
enough**

**Status:** unassigned
**Milestone:** 5.17.08
**Created:** Fri Jun 16, 2017 08:04 AM UTC by Tai Dinh
**Last Updated:** Tue Jun 20, 2017 03:03 AM UTC
**Owner:** nobody


We're now using a hard coded timeout value (20 seconds) in getting node 
destination.
This is sometimes not enough especially in cluster reboot procedure. Controller 
may come up first and continue the campaign without waiting for the rest to be 
up.
This can make the getNodeDestination() fail sometimes, especially for a large 
cluster.
In our case, it needs 3 more seconds.

I guess this timeout need to be increased or should be configurable.
Reuse some existing attribute for this purpose is also fine, e.g: 
smfRebootTimeout.

/Tai


---

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] #2499 SMF: 20 seconds timeout in getting node destination is not enough

[Rafael Odzakow via Opensaf-tickets]

waitForNodeDestination already uses smfRebootTimeout. Is it still timing out or 
was getNodeDestination called without the waitFor wrapper?


---

** [tickets:#2499] SMF: 20 seconds timeout in getting node destination is not 
enough**

**Status:** unassigned
**Milestone:** 5.17.08
**Created:** Fri Jun 16, 2017 08:04 AM UTC by Tai Dinh
**Last Updated:** Fri Jun 16, 2017 08:04 AM UTC
**Owner:** nobody


We're now using a hard coded timeout value (20 seconds) in getting node 
destination.
This is sometimes not enough especially in cluster reboot procedure. Controller 
may come up first and continue the campaign without waiting for the rest to be 
up.
This can make the getNodeDestination() fail sometimes, especially for a large 
cluster.
In our case, it needs 3 more seconds.

I guess this timeout need to be increased or should be configurable.
Reuse some existing attribute for this purpose is also fine, e.g: 
smfRebootTimeout.

/Tai


---

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] #2459 try-again for opensafd stop

[Rafael Odzakow via Opensaf-tickets]

- **summary**: improve state report for opensafd --> try-again for opensafd stop
- Description has changed:

Diff:



--- old
+++ new
@@ -1,3 +1,3 @@
 Today there is no way for SMF (or others) to know when opensafd start is 
completed. Calling stop when a start is ongoing will not stop opensafd so the 
reboot will not shutdown opensafd. Resulting in errors reports from several 
components.
 
-Internally opensafd creates a lock file during start/stop. To allow SMF and 
others to query the state this ticket will use the opensafd lockfile to report 
the status of start/stop when requested with "opensafd status"
+Internally opensafd creates a lock file during start/stop. Internally 
implement a try-again loop that will use the opensafd lockfile.






---

** [tickets:#2459] try-again for opensafd stop**

**Status:** review
**Milestone:** 5.17.08
**Created:** Thu May 11, 2017 12:42 PM UTC by Rafael Odzakow
**Last Updated:** Mon May 15, 2017 01:56 PM UTC
**Owner:** Rafael Odzakow


Today there is no way for SMF (or others) to know when opensafd start is 
completed. Calling stop when a start is ongoing will not stop opensafd so the 
reboot will not shutdown opensafd. Resulting in errors reports from several 
components.

Internally opensafd creates a lock file during start/stop. Internally implement 
a try-again loop that will use the opensafd lockfile.


---

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