[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 <rafael.odza...@ericsson.com>
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 = {
<std::allocator> = {
<__gnu_cxx::new_allocator> = {}, },
members of std::basic_string<char, std::char_traits, std::allocator 
>::_Alloc_hider:
_M_p = 0x7f048c12ae48 "SmfCampStateExecFailed"
}
}
oldState = {
static npos = ,
_M_dataplus = {
<std::allocator> = {
<__gnu_cxx::new_allocator> = {}, },
members of std::basic_string<char, std::char_traits, std::allocator 
>::_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 = {
<std::allocator> = {
<__gnu_cxx::new_allocator> = {}, },
members of std::basic_string<char, std::char_traits, std::allocator 
>::_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_m

[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 = {
<std::allocator> = {
<__gnu_cxx::new_allocator> = {}, },
members of std::basic_string<char, std::char_traits, std::allocator 
>::_Alloc_hider:
_M_p = 0x7f048c12ae48 "SmfCampStateExecFailed"
}
}
oldState = {
static npos = ,
_M_dataplus = {
<std::allocator> = {
<__gnu_cxx::new_allocator> = {}, },
members of std::basic_string<char, std::char_traits, std::allocator 
>::_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 = {
<std::allocator> = {
<__gnu_cxx::new_allocator> = {}, },
members of std::basic_string<char, std::char_traits, std::allocator 
>::_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 fail

[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 <rafael.odza...@ericsson.com>
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 <rafael.odza...@ericsson.com>
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 <rafael.odza...@ericsson.com>
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

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

[Rafael Odzakow]

- **status**: unassigned --> review



---

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

**Status:** review
**Milestone:** 5.17.08
**Created:** Fri May 19, 2017 10:55 AM UTC by Rafael Odzakow
**Last Updated:** Fri May 19, 2017 10:55 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] #2459 improve state report for opensafd

[Rafael Odzakow]

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



---

** [tickets:#2459] improve state report for opensafd**

**Status:** review
**Milestone:** 5.17.08
**Created:** Thu May 11, 2017 12:42 PM UTC by Rafael Odzakow
**Last Updated:** Thu May 11, 2017 12:43 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. 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"


---

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 improve state report for opensafd

[Rafael Odzakow]

- **summary**: graceful shutdown of opensafd --> improve state report for 
opensafd



---

** [tickets:#2459] improve state report for opensafd**

**Status:** assigned
**Milestone:** 5.17.08
**Created:** Thu May 11, 2017 12:42 PM UTC by Rafael Odzakow
**Last Updated:** Thu May 11, 2017 12:42 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. 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"


---

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 graceful shutdown of opensafd

[Rafael Odzakow]

---

** [tickets:#2459] graceful shutdown of opensafd**

**Status:** assigned
**Milestone:** 5.17.08
**Created:** Thu May 11, 2017 12:42 PM UTC by Rafael Odzakow
**Last Updated:** Thu May 11, 2017 12:42 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. 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"


---

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: #2419 smf: when fixing ticket #2145 a NBC problem was introduced

[Rafael Odzakow]

I consider the AMF objects as an interface and some external code outside of 
OpenSAF might be reading that campaignDN attribute.


---

** [tickets:#2419] smf: when fixing ticket #2145 a NBC problem was introduced**

**Status:** wontfix
**Milestone:** 5.2.0
**Created:** Mon Apr 10, 2017 11:11 AM UTC by elunlen
**Last Updated:** Mon Apr 24, 2017 07:53 PM UTC
**Owner:** nobody


Previous behavior:
The behavior was to ignore a fail to activate a component unless any secondary 
fault happened. This means that it was for example possible to complete a 
campaign even if a component failed to start and fix this problem after 
committing. No action to resume the campaign was needed.

After [#2145]:
The campaign will always suspend in case of component fail and a resume must be 
requested for the campaign to continue.

NBC:
The behavior has changed in such a way that it must be seen as a NBC. The #2145 
ticket corrects SMF behavior regarding AIS but is still NBC since the previous 
behavior is the legacy behavior in previous releases.

Proposal 1; Fix if not needed to change setting in runtime e.g. during an 
upgrade
Add a new configuration attribute to the SMF configuration class that makes it 
possible to select whether the behavior after #2145 shall be used or not. The 
default setting must be the previous behavior.
The setting must have the following properties:
- If the attribute does not exist (old model)   legacy behavior
- If the attribute value is not changed from defaultlegacy behavior
- If the attribute value is  or invalid  legacy behavior
- If the attribute value is a valid “ON” settingnew behavior
- A request to change the attribute in runtime shall always be rejected

Proposal 2; Fix if change has to be made during upgrade:
Add a new configuration attribute to the SMF configuration class that makes it 
possible to select whether the behavior after #2145 shall be used or not. The 
default setting must be the previous behavior.
The setting must have the following properties:
- If the attribute does not exist (old model)   legacy behavior
- If the attribute value is not changed from defaultlegacy behavior
- If the attribute value is  or invalid  legacy behavior
- If the attribute value is a valid “ON” settingnew behavior
- Attribute value must be possible to change in runtime in “idle” state (no 
campaign is executing)
- Attribute value must be possible to change in runtime in campaign init state. 
Note that if changed here
  the new setting must be used in the rest of the campaign



---

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] #2402 base: "hardening" use of lockfile in opensafd

[Rafael Odzakow]

- **status**: fixed --> unassigned
- **Blocker**:  --> False



---

** [tickets:#2402] base: "hardening" use of lockfile in opensafd**

**Status:** unassigned
**Milestone:** 5.2.RC2
**Created:** Wed Mar 29, 2017 10:40 AM UTC by Hans Nordebäck
**Last Updated:** Mon Apr 24, 2017 01:37 PM UTC
**Owner:** Hans Nordebäck


"hardening" use of lockfile in 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] #2402 base: "hardening" use of lockfile in opensafd

[Rafael Odzakow]

I have seen a issue with the lockfile. Here are some parts from the system log:

21:59:15 SC-1 opensafd: Starting OpenSAF Services(5.2.0 - 
8767:c1cc2a915e72:default) (Using TCP)

- Reboot command is issued from SC-2:
21:59:16 SC-2 osafsmfd[599]: NO STEP: Reboot node for removal 
safAmfNode=SC-1,safAmfCluster=myAmfCluster

- SC-1 is not finished with the start of opensaf. This line is missing from 
SC-1: opensafd: OpenSAF services successfully started

21:59:17 SC-1 opensafd: Stopping OpenSAF Services
21:59:17 SC-1 opensafd: opensafd start/stop already in progress. Unable to 
continue
21:59:17 SC-1 opensafd: To forcefully start/stop OpenSAF remove 
/var/lock/subsys/opensafd_inprogress
21:59:17 SC-1 osafamfwd[565]: exiting for shutdown
21:59:17 SC-1 osafamfnd[487]: NO Shutdown initiated



---

** [tickets:#2402] base: "hardening" use of lockfile in opensafd**

**Status:** fixed
**Milestone:** 5.2.RC2
**Created:** Wed Mar 29, 2017 10:40 AM UTC by Hans Nordebäck
**Last Updated:** Thu Mar 30, 2017 10:39 AM UTC
**Owner:** Hans Nordebäck


"hardening" use of lockfile in 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] Re: #2419 smf: when fixing ticket #2145 a NBC problem was introduced

[Rafael]

It is possible to do it both ways but I prefer to do this in AMF because it 
appears that the campaign dn was set on the objects before #2144 and #2145 were 
introduced. It was set by SMF and most likely the attribute was never used but 
I can't say for sure. The safe solution is to keep setting it just as it has 
been previously.

As for turning this on/off during a campaign. If someone external decides to 
change things in IMM during upgrade then we can not guarantee that the campaign 
will be successful. This is normal and it is understood that changes to the 
system configuration should not happen during a campaign (except from the 
campaign itself). It is left to the user to implement some kind of "maintenance 
lock" that could be taken by the campaign start.


---

** [tickets:#2419] smf: when fixing ticket #2145 a NBC problem was introduced**

**Status:** wontfix
**Milestone:** 5.2.0
**Created:** Mon Apr 10, 2017 11:11 AM UTC by elunlen
**Last Updated:** Sat Apr 22, 2017 09:56 AM UTC
**Owner:** nobody


Previous behavior:
The behavior was to ignore a fail to activate a component unless any secondary 
fault happened. This means that it was for example possible to complete a 
campaign even if a component failed to start and fix this problem after 
committing. No action to resume the campaign was needed.

After [#2145]:
The campaign will always suspend in case of component fail and a resume must be 
requested for the campaign to continue.

NBC:
The behavior has changed in such a way that it must be seen as a NBC. The #2145 
ticket corrects SMF behavior regarding AIS but is still NBC since the previous 
behavior is the legacy behavior in previous releases.

Proposal 1; Fix if not needed to change setting in runtime e.g. during an 
upgrade
Add a new configuration attribute to the SMF configuration class that makes it 
possible to select whether the behavior after #2145 shall be used or not. The 
default setting must be the previous behavior.
The setting must have the following properties:
- If the attribute does not exist (old model)   legacy behavior
- If the attribute value is not changed from defaultlegacy behavior
- If the attribute value is  or invalid  legacy behavior
- If the attribute value is a valid “ON” settingnew behavior
- A request to change the attribute in runtime shall always be rejected

Proposal 2; Fix if change has to be made during upgrade:
Add a new configuration attribute to the SMF configuration class that makes it 
possible to select whether the behavior after #2145 shall be used or not. The 
default setting must be the previous behavior.
The setting must have the following properties:
- If the attribute does not exist (old model)   legacy behavior
- If the attribute value is not changed from defaultlegacy behavior
- If the attribute value is  or invalid  legacy behavior
- If the attribute value is a valid “ON” settingnew behavior
- Attribute value must be possible to change in runtime in “idle” state (no 
campaign is executing)
- Attribute value must be possible to change in runtime in campaign init state. 
Note that if changed here
  the new setting must be used in the rest of the campaign



---

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] #2419 smf: when fixing ticket #2145 a NBC problem was introduced

[Rafael]

Suggestion is to disable setting the maintenance campaign attribute on the AMF 
object by default. And optionally have a setting to enable setting this 
attribute. This would disable possible AMF NBC as well as the SMF NBC for #2144 
and #2145


---

** [tickets:#2419] smf: when fixing ticket #2145 a NBC problem was introduced**

**Status:** unassigned
**Milestone:** 5.2.0
**Created:** Mon Apr 10, 2017 11:11 AM UTC by elunlen
**Last Updated:** Wed Apr 12, 2017 01:02 PM UTC
**Owner:** nobody


Previous behavior:
The behavior was to ignore a fail to activate a component unless any secondary 
fault happened. This means that it was for example possible to complete a 
campaign even if a component failed to start and fix this problem after 
committing. No action to resume the campaign was needed.

After [#2145]:
The campaign will always suspend in case of component fail and a resume must be 
requested for the campaign to continue.

NBC:
The behavior has changed in such a way that it must be seen as a NBC. The #2145 
ticket corrects SMF behavior regarding AIS but is still NBC since the previous 
behavior is the legacy behavior in previous releases.

Proposal 1; Fix if not needed to change setting in runtime e.g. during an 
upgrade
Add a new configuration attribute to the SMF configuration class that makes it 
possible to select whether the behavior after #2145 shall be used or not. The 
default setting must be the previous behavior.
The setting must have the following properties:
- If the attribute does not exist (old model)   legacy behavior
- If the attribute value is not changed from defaultlegacy behavior
- If the attribute value is  or invalid  legacy behavior
- If the attribute value is a valid “ON” settingnew behavior
- A request to change the attribute in runtime shall always be rejected

Proposal 2; Fix if change has to be made during upgrade:
Add a new configuration attribute to the SMF configuration class that makes it 
possible to select whether the behavior after #2145 shall be used or not. The 
default setting must be the previous behavior.
The setting must have the following properties:
- If the attribute does not exist (old model)   legacy behavior
- If the attribute value is not changed from defaultlegacy behavior
- If the attribute value is  or invalid  legacy behavior
- If the attribute value is a valid “ON” settingnew behavior
- Attribute value must be possible to change in runtime in “idle” state (no 
campaign is executing)
- Attribute value must be possible to change in runtime in campaign init state. 
Note that if changed here
  the new setting must be used in the rest of the campaign



---

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] #2419 smf: when fixing ticket #2145 a NBC problem was introduced

[Rafael]

- **Component**: unknown --> smf



---

** [tickets:#2419] smf: when fixing ticket #2145 a NBC problem was introduced**

**Status:** unassigned
**Milestone:** 5.2.0
**Created:** Mon Apr 10, 2017 11:11 AM UTC by elunlen
**Last Updated:** Mon Apr 10, 2017 08:09 PM UTC
**Owner:** nobody


Previous behavior:
The behavior was to ignore a fail to activate a component unless any secondary 
fault happened. This means that it was for example possible to complete a 
campaign even if a component failed to start and fix this problem after 
committing. No action to resume the campaign was needed.

After [#2145]:
The campaign will always suspend in case of component fail and a resume must be 
requested for the campaign to continue.

NBC:
The behavior has changed in such a way that it must be seen as a NBC. The #2145 
ticket corrects SMF behavior regarding AIS but is still NBC since the previous 
behavior is the legacy behavior in previous releases.

Proposal 1; Fix if not needed to change setting in runtime e.g. during an 
upgrade
Add a new configuration attribute to the SMF configuration class that makes it 
possible to select whether the behavior after #2145 shall be used or not. The 
default setting must be the previous behavior.
The setting must have the following properties:
- If the attribute does not exist (old model)   legacy behavior
- If the attribute value is not changed from defaultlegacy behavior
- If the attribute value is  or invalid  legacy behavior
- If the attribute value is a valid “ON” settingnew behavior
- A request to change the attribute in runtime shall always be rejected

Proposal 2; Fix if change has to be made during upgrade:
Add a new configuration attribute to the SMF configuration class that makes it 
possible to select whether the behavior after #2145 shall be used or not. The 
default setting must be the previous behavior.
The setting must have the following properties:
- If the attribute does not exist (old model)   legacy behavior
- If the attribute value is not changed from defaultlegacy behavior
- If the attribute value is  or invalid  legacy behavior
- If the attribute value is a valid “ON” settingnew behavior
- Attribute value must be possible to change in runtime in “idle” state (no 
campaign is executing)
- Attribute value must be possible to change in runtime in campaign init state. 
Note that if changed here
  the new setting must be used in the rest of the campaign



---

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] #2413 smf: coredump, suspend is issued at completed state

[Rafael]

---

** [tickets:#2413] smf: coredump, suspend is issued at completed state**

**Status:** unassigned
**Milestone:** 5.2.0
**Created:** Wed Apr 05, 2017 12:39 PM UTC by Rafael
**Last Updated:** Wed Apr 05, 2017 12:39 PM UTC
**Owner:** nobody
**Attachments:**

- 
[osafsmfd.9276.SC-2.core.txt](https://sourceforge.net/p/opensaf/tickets/2413/attachment/osafsmfd.9276.SC-2.core.txt)
 (15.4 kB; text/plain)


ticket #2145 looks to be causing this issue. 

coredump printout is attached.

Steps to reproduce: run a campaign and have AMF compenent fail at the campaign 
completed state. This triggers a event in SMF which tries to suspend a 
completed campaign.

Function handleAmfObjectStateChangeNotification will try to call asyncFailure() 
which is the same as suspend() because the campaign is completed and commited 
this is not a valid transition. The campaign state instance is most likely 
deleted therefore we get a coredump.

For reference refer to figures 5, 6, 7 in SMF AIS. Starting from section 5.1.3


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
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] #2288 smf: admin owner err_exist on parallel procedures

[Rafael]

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



---

** [tickets:#2288] smf: admin owner err_exist on parallel procedures**

**Status:** fixed
**Milestone:** 5.2.FC
**Created:** Fri Feb 03, 2017 01:42 PM UTC by Rafael
**Last Updated:** Thu Feb 23, 2017 12:57 PM UTC
**Owner:** Rafael


Create a campaign containing several single step procedures that install 
several bundles. If the procedures are on the same saSmfExecLevel the campaign 
will sometimes fail because of conflicting admin owner on IMM object. 

[SmfImmOperation.cc:0445] TR 
SmfImmCreateOperation::execute:saImmOmAdminOwnerSet failed SA_AIS_ERR_EXIST




---

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] #2288 smf: admin owner err_exist on parallel procedures

[Rafael]

Pushed to default branch:

HG changeset patch
 User Rafael Odzakow <rafael.odza...@ericsson.com>
 Date 1487853466 -3600
  Thu Feb 23 13:37:46 2017 +0100
 Node ID 12d8b8f1e18240dc285df481baaf6acddc6511e8
 Parent  15ea36eab4835ed048e4f1d28013d27888437d9b
smf: admin owner err_exist on parallel procedures [#2288]



---

** [tickets:#2288] smf: admin owner err_exist on parallel procedures**

**Status:** assigned
**Milestone:** 5.2.FC
**Created:** Fri Feb 03, 2017 01:42 PM UTC by Rafael
**Last Updated:** Fri Feb 03, 2017 02:02 PM UTC
**Owner:** Rafael


Create a campaign containing several single step procedures that install 
several bundles. If the procedures are on the same saSmfExecLevel the campaign 
will sometimes fail because of conflicting admin owner on IMM object. 

[SmfImmOperation.cc:0445] TR 
SmfImmCreateOperation::execute:saImmOmAdminOwnerSet failed SA_AIS_ERR_EXIST




---

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] #2288 smf: admin owner err_exist on parallel procedures

[Rafael]

campaign example:

  

  
  


  
  


  
  
 same for all BundleB and so on ...

 

  

  
  


  

  


  

  
  

  


   
  


  

  
  
... same for other procedures just change safAmfNode but keep execLevel ...




---

** [tickets:#2288] smf: admin owner err_exist on parallel procedures**

**Status:** assigned
**Milestone:** 5.2.FC
**Created:** Fri Feb 03, 2017 01:42 PM UTC by Rafael
**Last Updated:** Fri Feb 03, 2017 01:42 PM UTC
**Owner:** Rafael


Create a campaign containing several single step procedures that install 
several bundles. If the procedures are on the same saSmfExecLevel the campaign 
will sometimes fail because of conflicting admin owner on IMM object. 

[SmfImmOperation.cc:0445] TR 
SmfImmCreateOperation::execute:saImmOmAdminOwnerSet failed SA_AIS_ERR_EXIST




---

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] #2288 smf: admin owner err_exist on parallel procedures

[Rafael]

---

** [tickets:#2288] smf: admin owner err_exist on parallel procedures**

**Status:** assigned
**Milestone:** 5.2.FC
**Created:** Fri Feb 03, 2017 01:42 PM UTC by Rafael
**Last Updated:** Fri Feb 03, 2017 01:42 PM UTC
**Owner:** Rafael


Create a campaign containing several single step procedures that install 
several bundles. If the procedures are on the same saSmfExecLevel the campaign 
will sometimes fail because of conflicting admin owner on IMM object. 

[SmfImmOperation.cc:0445] TR 
SmfImmCreateOperation::execute:saImmOmAdminOwnerSet failed SA_AIS_ERR_EXIST




---

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] #1897 Incorrect ER messages in syslog

[Rafael]

Consider to change LOG_NO to TRACE in case multiple try again would spam the 
system log.


---

** [tickets:#1897] Incorrect ER messages in syslog**

**Status:** fixed
**Milestone:** 5.0.2
**Created:** Tue Jun 28, 2016 07:51 AM UTC by elunlen
**Last Updated:** Fri Jan 20, 2017 05:18 AM UTC
**Owner:** Gary Lee


Several incorrectly prioritized syslog messages found in SG_2N::si_swap in 
sg_2n_fsm.cc
LOG_ER is used when problem is easily recoverable e.g. return value is 
SA_AIS_ERR_TRY_AGAIN


---

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] #2264 SI SWAP returns try-again but logs an error

[Rafael]

Consider to change LOG_NO to TRACE in case multiple try again would spam the 
system log.


---

** [tickets:#2264] SI SWAP returns try-again but logs an error**

**Status:** unassigned
**Milestone:** 5.2.FC
**Created:** Fri Jan 13, 2017 01:58 PM UTC by Rafael
**Last Updated:** Fri Jan 13, 2017 01:58 PM UTC
**Owner:** nobody


in si.cc:

LOG_ER("%s SWAP failed - Cold sync in progress", name.c_str());
rc = SA_AIS_ERR_TRY_AGAIN;

The log is indicating an error but a TRY_AGAIN is returned and the next try is 
succesful. Looks like LOG_ER needs to be changed to LOG_NO


---

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.--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2264 SI SWAP returns try-again but logs an error

[Rafael]

---

** [tickets:#2264] SI SWAP returns try-again but logs an error**

**Status:** unassigned
**Milestone:** 5.2.FC
**Created:** Fri Jan 13, 2017 01:58 PM UTC by Rafael
**Last Updated:** Fri Jan 13, 2017 01:58 PM UTC
**Owner:** nobody


in si.cc:

LOG_ER("%s SWAP failed - Cold sync in progress", name.c_str());
rc = SA_AIS_ERR_TRY_AGAIN;

The log is indicating an error but a TRY_AGAIN is returned and the next try is 
succesful. Looks like LOG_ER needs to be changed to LOG_NO


---

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.--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2226 smf: failed one-step upgrade between opensaf versions

[Rafael]

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

Node ID dbf9c402bf53bb55ff3e391367a920d41b44
Parent  64e012a5a2339d0a6cdc69d909e69b49e7238ab7
smf: failed one-step upgrade between opensaf versions [#2226]


Branch opensaf-5.1.x
Node ID 29382f7ef68538236b8010db4e595336fab09e0b
Parent  121329984ff02ca8aacaddf4e938fe5931e953f5
smf: failed one-step upgrade between opensaf versions [#2226]




---

** [tickets:#2226] smf: failed one-step upgrade between opensaf versions**

**Status:** fixed
**Milestone:** 5.1.1
**Created:** Mon Dec 12, 2016 03:00 PM UTC by Rafael
**Last Updated:** Thu Jan 05, 2017 12:40 PM UTC
**Owner:** Rafael


When upgrading with one-step mode from a version before SmfExecControlHdl.cc 
was introduced to a version using it upgrade fails. Reason for the failure is 
that SMF tries to read "procExecMode" from "openSafSmfExecControl=SmfHdlCopy" 
but this object is only created during init in a version using 
SmfExecControlHdl.cc.

Solution is to read in the original value of procExecMode if the copy is 
missing. Drawback of this solution is that changing procExecMode during a 
running campaign but after init phase will cause errors.


---

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.--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2226 smf: failed one-step upgrade between opensaf versions

[Rafael]

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



---

** [tickets:#2226] smf: failed one-step upgrade between opensaf versions**

**Status:** assigned
**Milestone:** 5.1.1
**Created:** Mon Dec 12, 2016 03:00 PM UTC by Rafael
**Last Updated:** Mon Dec 12, 2016 03:00 PM UTC
**Owner:** Rafael


When upgrading with one-step mode from a version before SmfExecControlHdl.cc 
was introduced to a version using it upgrade fails. Reason for the failure is 
that SMF tries to read "procExecMode" from "openSafSmfExecControl=SmfHdlCopy" 
but this object is only created during init in a version using 
SmfExecControlHdl.cc.

Solution is to read in the original value of procExecMode if the copy is 
missing. Drawback of this solution is that changing procExecMode during a 
running campaign but after init phase will cause errors.


---

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] #2242 smf: builds on ubuntu 16.04 cause segmentation fault

[Rafael]

---

** [tickets:#2242] smf: builds on ubuntu 16.04 cause segmentation fault**

**Status:** assigned
**Milestone:** 5.2.FC
**Created:** Thu Dec 22, 2016 12:49 PM UTC by Rafael
**Last Updated:** Thu Dec 22, 2016 12:49 PM UTC
**Owner:** Rafael


The following message in core dump

438 Program terminated with signal SIGSEGV, Segmentation fault.
439 #0  __memcmp_sse2 () at ../sysdeps/x86_64/multiarch/../memcmp.S:276

called from function: SmfUpgradeProcedure::addStepModificationsNode

on this usage:

... = i_newStep->getActivationUnitList().front().name;

When the list is empty on ubuntu 16 builds it will case a segfault. Solution is 
to check size before assignment. 


---

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.--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2226 smf: failed one-step upgrade between opensaf versions

[Rafael]

---

** [tickets:#2226] smf: failed one-step upgrade between opensaf versions**

**Status:** unassigned
**Milestone:** 5.1.1
**Created:** Mon Dec 12, 2016 03:00 PM UTC by Rafael
**Last Updated:** Mon Dec 12, 2016 03:00 PM UTC
**Owner:** Rafael


When upgrading with one-step mode from a version before SmfExecControlHdl.cc 
was introduced to a version using it upgrade fails. Reason for the failure is 
that SMF tries to read "procExecMode" from "openSafSmfExecControl=SmfHdlCopy" 
but this object is only created during init in a version using 
SmfExecControlHdl.cc.

Solution is to read in the original value of procExecMode if the copy is 
missing. Drawback of this solution is that changing procExecMode during a 
running campaign but after init phase will cause errors.


---

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.--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2152 smf: describe rollback limitation in balanced upgrade

[Rafael]

document for review


Attachments:

- 
[OpenSAF_SMFSv_PR.odt](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/27a54b29/6d7c/attachment/OpenSAF_SMFSv_PR.odt)
 (429.2 kB; application/vnd.oasis.opendocument.text)


---

** [tickets:#2152] smf: describe rollback limitation in balanced upgrade**

**Status:** unassigned
**Milestone:** 5.1.1
**Created:** Mon Oct 31, 2016 12:06 PM UTC by Rafael
**Last Updated:** Mon Oct 31, 2016 12:06 PM UTC
**Owner:** Rafael


Rollback is not tested or implemented to work in the balanced upgrade type of 
execution. Describe this in the SMF PR document.


---

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.--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2147 smf: balanced upgrade, modifications missing after reboot

[Rafael]

changeset:   8280:c20d8c0a6717
parent:  8278:043297f42a74
user:Rafael Odzakow <rafael.odza...@ericsson.com>
date:Fri Oct 28 12:14:53 2016 +0200
summary: smf: balanced upgrade, modifications missing after reboot [#2147]
 Node ID c20d8c0a6717a89e76a969200d26484abdd45ea3
 Parent  043297f42a74f7edf9a258032c755c3594e9d204


changeset:   8279:7609bf0ca8b8
branch:  opensaf-5.1.x
parent:  8270:e0f8874243f7
user:    Rafael Odzakow <rafael.odza...@ericsson.com>
date:Fri Oct 28 12:14:53 2016 +0200
summary: smf: balanced upgrade, modifications missing after reboot [#2147]
 Node ID 7609bf0ca8b8814184bec243be0e6a010e7e658a
 Parent  e0f8874243f740e5c275814e806d60933fdc11af



---

** [tickets:#2147] smf: balanced upgrade, modifications missing after reboot**

**Status:** review
**Milestone:** 5.1.1
**Created:** Fri Oct 28, 2016 10:13 AM UTC by Rafael
**Last Updated:** Mon Oct 31, 2016 11:25 AM UTC
**Owner:** Rafael


The issue happens duing balanced upgrade when doing an SI SWAP on the 
controllers just before starting the balanced procedures. In this case SMF 
normally would read the IMM data for any step modifications ticket [#906] 
changed that to not read any modifications when the procedures are in COMPLETE 
state. Solution is to keep the behaviour in a non balanced upgrade. When 
executing a balanced upgrade the modifications are read and a error check 
(forAddRemove and forModify) is skipped.


---

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.--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2147 smf: balanced upgrade, modifications missing after reboot

[Rafael]

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



---

** [tickets:#2147] smf: balanced upgrade, modifications missing after reboot**

**Status:** fixed
**Milestone:** 5.1.1
**Created:** Fri Oct 28, 2016 10:13 AM UTC by Rafael
**Last Updated:** Wed Nov 02, 2016 10:06 AM UTC
**Owner:** Rafael


The issue happens duing balanced upgrade when doing an SI SWAP on the 
controllers just before starting the balanced procedures. In this case SMF 
normally would read the IMM data for any step modifications ticket [#906] 
changed that to not read any modifications when the procedures are in COMPLETE 
state. Solution is to keep the behaviour in a non balanced upgrade. When 
executing a balanced upgrade the modifications are read and a error check 
(forAddRemove and forModify) is skipped.


---

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.--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2126 smf: balanced upgrade, no activation/deactivation done

[Rafael]

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



---

** [tickets:#2126] smf: balanced upgrade, no activation/deactivation done**

**Status:** fixed
**Milestone:** 5.1.1
**Created:** Wed Oct 19, 2016 11:31 AM UTC by Rafael
**Last Updated:** Wed Nov 02, 2016 10:04 AM UTC
**Owner:** Rafael


During balanced upgrade it was observed that a software bundle was unable to be 
deleted from IMM. Looking in the saLog a message saying "admin state is not 
locked instantiaion" shows that no deactivation/activation was not done for the 
node.


---

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.--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2126 smf: balanced upgrade, no activation/deactivation done

[Rafael]

changeset:   8282:04bc7063f380
tag: tip
parent:  8280:c20d8c0a6717
user:Rafael Odzakow <rafael.odza...@ericsson.com>
date:Fri Oct 28 14:12:37 2016 +0200
summary: smf:balanced upgrade, no activation/deactivation done [#2126]
 Node ID 04bc7063f3805a858be32319a6aaab21b4c31d91
 Parent  c20d8c0a6717a89e76a969200d26484abdd45ea3


changeset:   8281:70b1faf3a330
branch:  opensaf-5.1.x
parent:  8279:7609bf0ca8b8
user:    Rafael Odzakow <rafael.odza...@ericsson.com>
date:Fri Oct 28 14:12:37 2016 +0200
summary: smf:balanced upgrade, no activation/deactivation done [#2126]
 Node ID 70b1faf3a33025b362cd8de34b7a71df412d4f83
 Parent  7609bf0ca8b8814184bec243be0e6a010e7e658a




---

** [tickets:#2126] smf: balanced upgrade, no activation/deactivation done**

**Status:** review
**Milestone:** 5.1.1
**Created:** Wed Oct 19, 2016 11:31 AM UTC by Rafael
**Last Updated:** Fri Oct 28, 2016 01:50 PM UTC
**Owner:** Rafael


During balanced upgrade it was observed that a software bundle was unable to be 
deleted from IMM. Looking in the saLog a message saying "admin state is not 
locked instantiaion" shows that no deactivation/activation was not done for the 
node.


---

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.--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2154 smf: non backward compatible name change for ExecCtrlCopy

[Rafael]

- **status**: assigned --> invalid



---

** [tickets:#2154] smf: non backward compatible name change for ExecCtrlCopy**

**Status:** invalid
**Milestone:** 5.1.1
**Created:** Mon Oct 31, 2016 03:18 PM UTC by Rafael
**Last Updated:** Mon Oct 31, 2016 03:34 PM UTC
**Owner:** Rafael


there was a name change introduced in patch for ticket [#2114]. This changed 
the name of the object openSafSmfExecControl_copy to 
openSafSmfExecControl=SmfHdlCopy. This change causes the upgrades between these 
two versions to fail.


---

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.--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2154 smf: non backward compatible name change for ExecCtrlCopy

[Rafael]

- Description has changed:

Diff:



--- old
+++ new
@@ -1 +1 @@
-there was a name change introduced in patch for ticket #2114. This changed the 
name of the object openSafSmfExecControl_copy to 
openSafSmfExecControl=SmfHdlCopy. This causes the new upgrades between these 
two versions to fail.
+there was a name change introduced in patch for ticket #2114. This changed the 
name of the object openSafSmfExecControl_copy to 
openSafSmfExecControl=SmfHdlCopy. This change causes the upgrades between these 
two versions to fail.






---

** [tickets:#2154] smf: non backward compatible name change for ExecCtrlCopy**

**Status:** unassigned
**Milestone:** 5.1.1
**Created:** Mon Oct 31, 2016 03:18 PM UTC by Rafael
**Last Updated:** Mon Oct 31, 2016 03:18 PM UTC
**Owner:** Rafael


there was a name change introduced in patch for ticket #2114. This changed the 
name of the object openSafSmfExecControl_copy to 
openSafSmfExecControl=SmfHdlCopy. This change causes the upgrades between these 
two versions to fail.


---

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.--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2154 smf: non backward compatible name change for ExecCtrlCopy

[Rafael]

---

** [tickets:#2154] smf: non backward compatible name change for ExecCtrlCopy**

**Status:** unassigned
**Milestone:** 5.1.1
**Created:** Mon Oct 31, 2016 03:18 PM UTC by Rafael
**Last Updated:** Mon Oct 31, 2016 03:18 PM UTC
**Owner:** Rafael


there was a name change introduced in patch for ticket #2114. This changed the 
name of the object openSafSmfExecControl_copy to 
openSafSmfExecControl=SmfHdlCopy. This causes the new upgrades between these 
two versions to fail.


---

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.--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2152 smf: describe rollback limitation in balanced upgrade

[Rafael]

---

** [tickets:#2152] smf: describe rollback limitation in balanced upgrade**

**Status:** unassigned
**Milestone:** 5.1.1
**Created:** Mon Oct 31, 2016 12:06 PM UTC by Rafael
**Last Updated:** Mon Oct 31, 2016 12:06 PM UTC
**Owner:** Rafael


Rollback is not tested or implemented to work in the balanced upgrade type of 
execution. Describe this in the SMF PR document.


---

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.--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2126 smf: balanced upgrade, no activation/deactivation done

[Rafael]

- **Milestone**: 5.2.FC --> 5.1.1



---

** [tickets:#2126] smf: balanced upgrade, no activation/deactivation done**

**Status:** assigned
**Milestone:** 5.1.1
**Created:** Wed Oct 19, 2016 11:31 AM UTC by Rafael
**Last Updated:** Wed Oct 19, 2016 11:31 AM UTC
**Owner:** Rafael


During balanced upgrade it was observed that a software bundle was unable to be 
deleted from IMM. Looking in the saLog a message saying "admin state is not 
locked instantiaion" shows that no deactivation/activation was not done for the 
node.


---

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] #2126 smf: balanced upgrade, no activation/deactivation done

[Rafael]

---

** [tickets:#2126] smf: balanced upgrade, no activation/deactivation done**

**Status:** assigned
**Milestone:** 5.2.FC
**Created:** Wed Oct 19, 2016 11:31 AM UTC by Rafael
**Last Updated:** Wed Oct 19, 2016 11:31 AM UTC
**Owner:** Rafael


During balanced upgrade it was observed that a software bundle was unable to be 
deleted from IMM. Looking in the saLog a message saying "admin state is not 
locked instantiaion" shows that no deactivation/activation was not done for the 
node.


---

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] #2114 smf: balanced upgrade, missing removal of exectrl copy

[Rafael]

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

changeset:   8219:d4c05e5a66e5
branch:  opensaf-5.1.x
summary: smf: balanced upgrade, missing removal of exectrl copy [#2114]
 Branch opensaf-5.1.x
 Node ID d4c05e5a66e5431f1edffd22d1f5bc2527df36f0
 Parent  f86e8509a000626632fac108c38a86950bf2ef96

changeset:   8218:3565b16a8f88
summary: smf: balanced upgrade, missing removal of exectrl copy [#2114]
 Node ID 3565b16a8f889bd13e8b2ebc18ebce7d94beb2de
 Parent  90192f4b8e9830dfb5cdbc61fc1a77b532494968





---

** [tickets:#2114] smf: balanced upgrade, missing removal of exectrl copy**

**Status:** fixed
**Milestone:** 5.1.1
**Created:** Wed Oct 12, 2016 11:01 AM UTC by Rafael
**Last Updated:** Wed Oct 12, 2016 11:01 AM UTC
**Owner:** Rafael


When doing several bisu upgrades it was noticed that a IMM copy of execControl 
object was not removed after a upgrade. Looking into the code there is a bug 
which would case SMF to never remove this execControl copy. Then the copy would 
be reused in the next campaign if it did an SI swap.


---

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] #2114 smf: balanced upgrade, missing removal of exectrl copy

[Rafael]

---

** [tickets:#2114] smf: balanced upgrade, missing removal of exectrl copy**

**Status:** assigned
**Milestone:** 5.1.1
**Created:** Wed Oct 12, 2016 11:01 AM UTC by Rafael
**Last Updated:** Wed Oct 12, 2016 11:01 AM UTC
**Owner:** Rafael


When doing several bisu upgrades it was noticed that a IMM copy of execControl 
object was not removed after a upgrade. Looking into the code there is a bug 
which would case SMF to never remove this execControl copy. Then the copy would 
be reused in the next campaign if it did an SI swap.


---

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] #2080 smf: balanced upgrade software bundle missmatch

[Rafael]

- **status**: accepted --> fixed



---

** [tickets:#2080] smf: balanced upgrade software bundle missmatch**

**Status:** fixed
**Milestone:** 5.1.1
**Created:** Thu Sep 29, 2016 07:50 AM UTC by Rafael
**Last Updated:** Fri Sep 30, 2016 08:18 AM UTC
**Owner:** Rafael


When merging steps for the BALANCED_MODE execution there is a missmatch in how 
the software bundles are added to the new step. The problem will show when 
nodes have different software installed and not all of those nodes are included 
in the balanced list.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2080 smf: balanced upgrade software bundle missmatch

[Rafael]

changeset:   8177:d70633d36e89
branch:  opensaf-5.1.x
parent:  8173:2e102946fdfb
summary: smf: balanced upgrade software bundle missmatch [#2080]
Node ID d70633d36e89aed4454dba9097ec3e5e0df50f52


changeset:   8176:e27693353f50
summary: smf: balanced upgrade software bundle missmatch [#2080]
Node ID e27693353f50f56ffd42722c0343eb2a577f4d00





---

** [tickets:#2080] smf: balanced upgrade software bundle missmatch**

**Status:** accepted
**Milestone:** 5.1.1
**Created:** Thu Sep 29, 2016 07:50 AM UTC by Rafael
**Last Updated:** Thu Sep 29, 2016 07:50 AM UTC
**Owner:** Rafael


When merging steps for the BALANCED_MODE execution there is a missmatch in how 
the software bundles are added to the new step. The problem will show when 
nodes have different software installed and not all of those nodes are included 
in the balanced list.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2083 amf: error in syslog when initiating SI SWAP

[Rafael]

---

** [tickets:#2083] amf: error in syslog when initiating SI SWAP**

**Status:** unassigned
**Milestone:** future
**Created:** Thu Sep 29, 2016 12:01 PM UTC by Rafael
**Last Updated:** Thu Sep 29, 2016 12:01 PM UTC
**Owner:** nobody


SMF initiates an SI SWAP which fails but then the retry is succesful. The error 
result should not be logged as an error in syslog.

osafamfd[473]: ER safSi=SC-2N,safApp=OpenSAF SWAP failed - only one assignment
osafrded[407]: NO Peer up on node 0x2020f
osafrded[407]: NO Got peer info request from node 0x2020f with role STANDBY
osafrded[407]: NO Got peer info response from node 0x2020f with role STANDBY
osafimmd[426]: NO MDS event from svc_id 24 (change:5, dest:13)
osafimmnd[436]: NO Implementer (applier) connected: 49 (@safAmfService2020f) 
<0, 2020f>
osafimmnd[436]: NO Implementer (applier) connected: 50 (@OpenSafImmReplicatorB) 
<0, 2020f>
osafamfd[473]: ER safSi=SC-2N,safApp=OpenSAF SWAP failed - Cold sync in progress
osafamfd[473]: NO safSi=SC-2N,safApp=OpenSAF Swap initiated



---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2080 smf: balanced upgrade software bundle missmatch

[Rafael]

---

** [tickets:#2080] smf: balanced upgrade software bundle missmatch**

**Status:** accepted
**Milestone:** 5.1.1
**Created:** Thu Sep 29, 2016 07:50 AM UTC by Rafael
**Last Updated:** Thu Sep 29, 2016 07:50 AM UTC
**Owner:** Rafael


When merging steps for the BALANCED_MODE execution there is a missmatch in how 
the software bundles are added to the new step. The problem will show when 
nodes have different software installed and not all of those nodes are included 
in the balanced list.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2017 Update the SMF PR document with information about faster upgrade

[Rafael]

- **status**: accepted --> fixed
- **Comment**:

changeset:   197:bb8308b1b865
tag: tip
user:    Rafael Odzakow <rafael.odza...@ericsson.com>
date:Fri Sep 23 14:49:20 2016 +0200
summary: smf: update PR with information about faster upgrade [#2017]

Node ID bb8308b1b865b5dbdaccae90f7ad2684e0918fc5
Parent  22151aff279d6fbc4a7251613ba1a63738dc4fe4




---

** [tickets:#2017] Update the SMF PR document with information about faster 
upgrade**

**Status:** fixed
**Milestone:** 5.1.0
**Created:** Fri Sep 09, 2016 12:22 PM UTC by elunlen
**Last Updated:** Wed Sep 21, 2016 12:35 PM UTC
**Owner:** elunlen


Update the SMF PR document with information about:
* Balanced In Service Upgrade (BISU) [#1685]
* Parallel swBundle removal and installation [#1633]
* NG lock and unlock in single step upgrade [#1634]


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2017 Update the SMF PR document with information about faster upgrade

[Rafael]

Document for review, fix spelling misstakes and add minor clarifications


Attachments:

- 
[OpenSAF_SMFSv_PR-1.odt](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/073b9a04/8f3d/attachment/OpenSAF_SMFSv_PR-1.odt)
 (429.9 kB; application/vnd.oasis.opendocument.text)


---

** [tickets:#2017] Update the SMF PR document with information about faster 
upgrade**

**Status:** accepted
**Milestone:** 5.1.0
**Created:** Fri Sep 09, 2016 12:22 PM UTC by elunlen
**Last Updated:** Tue Sep 20, 2016 05:34 PM UTC
**Owner:** elunlen


Update the SMF PR document with information about:
* Balanced In Service Upgrade (BISU) [#1685]
* Parallel swBundle removal and installation [#1633]
* NG lock and unlock in single step upgrade [#1634]


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2017 Update the SMF PR document with information about faster upgrade

[Rafael]

Document for review


Attachments:

- 
[OpenSAF_SMFSv_PR_2.odt](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/073b9a04/8f1d/attachment/OpenSAF_SMFSv_PR_2.odt)
 (430.0 kB; application/vnd.oasis.opendocument.text)


---

** [tickets:#2017] Update the SMF PR document with information about faster 
upgrade**

**Status:** accepted
**Milestone:** 5.1.RC2
**Created:** Fri Sep 09, 2016 12:22 PM UTC by elunlen
**Last Updated:** Tue Sep 13, 2016 10:05 AM UTC
**Owner:** elunlen


Update the SMF PR document with information about:
* Balanced In Service Upgrade (BISU) [#1685]
* Parallel swBundle removal and installation [#1633]
* NG lock and unlock in single step upgrade [#1634]


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1685 smfd: Merge rolling to singlestep procedures for several nodes

[Rafael]

changeset:   8053:774cfc4342ba
branch: opensaf-5.1.x
parent: 8050:602e4938d0c3
user: Rafael Odzakow <rafael.odza...@ericsson.com>
date: Mon Sep 12 09:58:57 2016 +0200
summary: Merge rolling to singlestep procedures for several nodes [#1685]

Node ID 774cfc4342bafae3f77ba229bf05ce2091192a04
Parent  602e4938d0c3a3243e379f415695d727223b4923

changeset:   8052:31f199f17fba
user:     Rafael Odzakow <rafael.odza...@ericsson.com>
date: Mon Sep 12 09:58:57 2016 +0200
summary: Merge rolling to singlestep procedures for several nodes [#1685]

Node ID 31f199f17fba1a19128edc49746b4f4b6df74499
Parent  2c08aa065812a805e5efc13e0ac34721460821df


---

** [tickets:#1685] smfd: Merge rolling to singlestep procedures for several 
nodes**

**Status:** review
**Milestone:** 5.1.RC1
**Created:** Wed Mar 02, 2016 09:20 AM UTC by Rafael
**Last Updated:** Tue Aug 30, 2016 08:58 AM UTC
**Owner:** Rafael


By extending SMF configuration we allow SMF to execute procedures in a 
optimised way. Today SMF can merge rolling procedures into one single step to 
minimize reboots. This new ticket would give SMF the additional possibility to 
have multiple single steps produced from rolling upgrades. This is in order to 
keep some services up while still reducing the amount of reboots.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1685 smfd: Merge rolling to singlestep procedures for several nodes

[Rafael]

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



---

** [tickets:#1685] smfd: Merge rolling to singlestep procedures for several 
nodes**

**Status:** assigned
**Milestone:** 5.1.FC
**Created:** Wed Mar 02, 2016 09:20 AM UTC by Rafael
**Last Updated:** Tue Jun 28, 2016 09:47 AM UTC
**Owner:** Rafael


By extending SMF configuration we allow SMF to execute procedures in a 
optimised way. Today SMF can merge rolling procedures into one single step to 
minimize reboots. This new ticket would give SMF the additional possibility to 
have multiple single steps produced from rolling upgrades. This is in order to 
keep some services up while still reducing the amount of reboots.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1685 smfd: Merge rolling to singlestep procedures for several nodes

[Rafael]

- **Milestone**: future --> 5.1.FC



---

** [tickets:#1685] smfd: Merge rolling to singlestep procedures for several 
nodes**

**Status:** unassigned
**Milestone:** 5.1.FC
**Created:** Wed Mar 02, 2016 09:20 AM UTC by Rafael
**Last Updated:** Tue Jun 28, 2016 08:24 AM UTC
**Owner:** Rafael


By extending SMF configuration we allow SMF to execute procedures in a 
optimised way. Today SMF can merge rolling procedures into one single step to 
minimize reboots. This new ticket would give SMF the additional possibility to 
have multiple single steps produced from rolling upgrades. This is in order to 
keep some services up while still reducing the amount of reboots.


---

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.--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1685 smfd: Merge rolling to singlestep procedures for several nodes

[Rafael]

The OpenSafSmfExecControl object is extended with additional attributes to 
support grouping of nodes. These additional attributes are valid when 
procExecMode is set to a integer mapped to the BALANCED_UPGRADE function.

Additional attributes for OpenSafSmfExecControl

nodesForSingleStep 
numberOfSingleSteps

For now there are two limitations in this functionality:

SMF only supports one active OpenSafSmfExecControl object.

The list of nodes in nodesForSingleStep must be of the payload type.


---

** [tickets:#1685] smfd: Merge rolling to singlestep procedures for several 
nodes**

**Status:** unassigned
**Milestone:** future
**Created:** Wed Mar 02, 2016 09:20 AM UTC by Rafael
**Last Updated:** Wed Mar 02, 2016 09:20 AM UTC
**Owner:** Rafael


By extending SMF configuration we allow SMF to execute procedures in a 
optimised way. Today SMF can merge rolling procedures into one single step to 
minimize reboots. This new ticket would give SMF the additional possibility to 
have multiple single steps produced from rolling upgrades. This is in order to 
keep some services up while still reducing the amount of reboots.


---

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.--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1825 MDS: When saImmOmInitialize was invoked, MDS sent ‘pid = 0’ in MDS_CALLBACK_RECEIVE_INFO.

[Rafael]

The test-case (simplified);

1. Start a virtual cluster

2. Installs the SW-under-test with a "campaign" with cluster reboot ~02:19, SAF 
started ~02:20:09

3. Performs some tests (most likely not related)

4. Starts a "scale-out" by starting 2 new VM's in the cluster ~02:30

5. The new VM's boots using a "proble-kernel"

6. SAF is made aware of the new VM's and are supposed to include them in the 
SAF cluster ~02:31


I think the logs at ~2:20 is turbulence from the install and SAF start.


The fault is intermittent and occurs around 1 out of 20 nightly tests so we 
can't give
an instruction how to reproduce it. It does however re-occurs so if we can look 
for something
in particular or turn on some extra logging we can do so and provide the 
information.




---

** [tickets:#1825] MDS: When saImmOmInitialize was invoked, MDS sent ‘pid = 0’ 
in MDS_CALLBACK_RECEIVE_INFO.**

**Status:** unassigned
**Milestone:** 4.7.2
**Created:** Fri May 13, 2016 12:34 PM UTC by Rafael
**Last Updated:** Mon May 16, 2016 03:54 AM UTC
**Owner:** nobody
**Attachments:**

- 
[sc2_mds.log](https://sourceforge.net/p/opensaf/tickets/1825/attachment/sc2_mds.log)
 (2.6 MB; text/x-log)


This happens only some of the time. 

First this is called from an application:

saImmOmInitialize(immHandle, NULL, )

Then the system log shows this error:

May 13 02:31:53 sc2 osafimmnd[6042]: WA immnd_evt_proc_imm_init: PID 0 
(7150) for 2020fb1d13cb8, MDS problem?
 May 13 02:31:53 sc2 osafimmnd[6042]: WA immnd_evt_proc_imm_init: PID 0 
(7150) for 2020fb1d13cb8, MDS problem?
 May 13 02:31:55 sc2 osafimmnd[6042]: NO Ccb 176 COMMITTED (LDE)
 May 13 02:31:55 sc2 osafimmnd[6042]: WA immnd_evt_proc_imm_init: PID 0 
(7150) for 2020fb1d13cb8, MDS problem?
 May 13 02:31:55 sc2 osafimmnd[6042]: WA immnd_evt_proc_imm_init: PID 0 
(7150) for 2020fb1d13cb8, MDS problem?


---

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.--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1825 MDS: When saImmOmInitialize was invoked, MDS sent ‘pid = 0’ in MDS_CALLBACK_RECEIVE_INFO.

[Rafael]

---

** [tickets:#1825] MDS: When saImmOmInitialize was invoked, MDS sent ‘pid = 0’ 
in MDS_CALLBACK_RECEIVE_INFO.**

**Status:** unassigned
**Milestone:** 4.7.2
**Created:** Fri May 13, 2016 12:34 PM UTC by Rafael
**Last Updated:** Fri May 13, 2016 12:34 PM UTC
**Owner:** nobody
**Attachments:**

- 
[sc2_mds.log](https://sourceforge.net/p/opensaf/tickets/1825/attachment/sc2_mds.log)
 (2.6 MB; text/x-log)


This happens only some of the time. 

First this is called from an application:

saImmOmInitialize(immHandle, NULL, )

Then the system log shows this error:

May 13 02:31:53 sc2 osafimmnd[6042]: WA immnd_evt_proc_imm_init: PID 0 
(7150) for 2020fb1d13cb8, MDS problem?
 May 13 02:31:53 sc2 osafimmnd[6042]: WA immnd_evt_proc_imm_init: PID 0 
(7150) for 2020fb1d13cb8, MDS problem?
 May 13 02:31:55 sc2 osafimmnd[6042]: NO Ccb 176 COMMITTED (LDE)
 May 13 02:31:55 sc2 osafimmnd[6042]: WA immnd_evt_proc_imm_init: PID 0 
(7150) for 2020fb1d13cb8, MDS problem?
 May 13 02:31:55 sc2 osafimmnd[6042]: WA immnd_evt_proc_imm_init: PID 0 
(7150) for 2020fb1d13cb8, MDS problem?


---

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.--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1802 amf upgrade fails

[Rafael]

Maybe someone else can help you with the trace and logs. I am not able to 
reproduce it on my system. It seems this also shows in a failover case of the 
active SC without doing any SMF upgrade.


---

** [tickets:#1802] amf upgrade fails**

**Status:** accepted
**Milestone:** 5.0.GA
**Created:** Mon May 02, 2016 05:44 PM UTC by Rafael
**Last Updated:** Tue May 03, 2016 09:54 AM UTC
**Owner:** Nagendra Kumar


When running an SMF upgrade of AMF the following happens:

SC-2-1 osafsmfd[4296]: NO STEP: Online installation of new software
(this step is succesful)
SC-2-1 osafsmfd[4296]: NO STEP: Lock deactivation units
SC-2-1 osafamfd[4120]: NO Node is locked, no SI unassigned alarm will be sent
SC-2-1 osafsmfd[4296]: NO STEP: Terminate deactivation units
SC-2-1 osafamfd[4120]: WA avd_msg_sanity_chk: invalid msg id 219, msg type 8, 
from 2020f should be 218
... (this repeats a number of times)

osafsmfd[4296]: NO Fail to invoke admin operation, rc=SA_AIS_ERR_TIMEOUT (5). 
dn=[safAmfNode=SC-2,safAmfCluster=myAmfCluster], opId=[3]
osafsmfd[4296]: NO Failed to call admin operation 3 on 
safAmfNode=SC-2,safAmfCluster=myAmfCluster
 
Is AMF handling a upgrade properly? Seems that the msg id is missmatched here.



---

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.--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1802 amf upgrade fails

[Rafael]

---

** [tickets:#1802] amf upgrade fails**

**Status:** unassigned
**Milestone:** 5.0.GA
**Created:** Mon May 02, 2016 05:44 PM UTC by Rafael
**Last Updated:** Mon May 02, 2016 05:44 PM UTC
**Owner:** nobody


When running an SMF upgrade of AMF the following happens:

SC-2-1 osafsmfd[4296]: NO STEP: Online installation of new software
(this step is succesful)
SC-2-1 osafsmfd[4296]: NO STEP: Lock deactivation units
SC-2-1 osafamfd[4120]: NO Node is locked, no SI unassigned alarm will be sent
SC-2-1 osafsmfd[4296]: NO STEP: Terminate deactivation units
SC-2-1 osafamfd[4120]: WA avd_msg_sanity_chk: invalid msg id 219, msg type 8, 
from 2020f should be 218
... (this repeats a number of times)

osafsmfd[4296]: NO Fail to invoke admin operation, rc=SA_AIS_ERR_TIMEOUT (5). 
dn=[safAmfNode=SC-2,safAmfCluster=myAmfCluster], opId=[3]
osafsmfd[4296]: NO Failed to call admin operation 3 on 
safAmfNode=SC-2,safAmfCluster=myAmfCluster
 
Is AMF handling a upgrade properly? Seems that the msg id is missmatched here.



---

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.--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1771 smfd: single step rollback does not call bundle scripts

[Rafael]

HG changeset patch
User Rafael Odzakow <rafael.odza...@ericsson.com>
Date 1461249771 -7200
 Thu Apr 21 16:42:51 2016 +0200
Branch opensaf-5.0.x
Node ID fd28b88ddbd45d17563c543020161fbc47c3015e
Parent  860c6d50a28625bad0aa9be9a64984cd29a2530e



---

** [tickets:#1771] smfd: single step rollback does not call bundle scripts**

**Status:** fixed
**Milestone:** 5.0.RC2
**Created:** Tue Apr 19, 2016 08:08 AM UTC by Rafael
**Last Updated:** Thu Apr 21, 2016 02:47 PM UTC
**Owner:** Rafael


This is a bug introduced with opensaf change: 7354. The effect of the bug is 
that bundle scripts do not get executed when rolling back. In the software 
loading thread a variable does not get initialized when called in the rollback 
stage.


---

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.--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1787 smf: single step with reboot activation

[Rafael]

---

** [tickets:#1787] smf: single step with reboot activation**

**Status:** unassigned
**Milestone:** future
**Created:** Wed Apr 27, 2016 11:10 AM UTC by Rafael
**Last Updated:** Wed Apr 27, 2016 11:10 AM UTC
**Owner:** nobody


Today in SMF there is no support to activate a SU when doing a single step with 
reboot. A campaign is forced to do workarounds such as manually unlocking SUs 
at procWrapup or adding additional procedures that unlock SUs. 

Proposal is to extend the existing OpenSAF extension to SMF specification. This 
extension allowed reboot upgrades during single step. Then this ticket would 
allow these reboot upgrades to handle unlocking of SUs.




---

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.--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1771 smfd: single step rollback does not call bundle scripts

[Rafael]

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

changeset:   7520:4c44fe2abdee
tag: tip
user:    Rafael Odzakow <rafael.odza...@ericsson.com>
date:Thu Apr 21 16:42:51 2016 +0200
summary: Fixes a bug introduced with opensaf change: 7354.

Node ID 4c44fe2abdee104902f227f15bb92b248365988b
Parent  08ba368f1d859f841d261fd5dc39ed9122dd99be





---

** [tickets:#1771] smfd: single step rollback does not call bundle scripts**

**Status:** fixed
**Milestone:** 5.0.RC2
**Created:** Tue Apr 19, 2016 08:08 AM UTC by Rafael
**Last Updated:** Tue Apr 19, 2016 08:08 AM UTC
**Owner:** Rafael


This is a bug introduced with opensaf change: 7354. The effect of the bug is 
that bundle scripts do not get executed when rolling back. In the software 
loading thread a variable does not get initialized when called in the rollback 
stage.


---

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.--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1714 Increase ClcCliTimeout to avoid registration timeout

[Rafael]

changeset:   7509:fcbbcec13f98
tag: tip
user:Rafael Odzakow <rafael.odza...@ericsson.com>
date:Thu Apr 21 10:15:59 2016 +0200
summary: smf: Increase ClcCliTimeout to avoid registration timeout [1714]

Node ID fcbbcec13f9800fa653d473bd40ba63afae2fee3



---

** [tickets:#1714] Increase ClcCliTimeout to avoid registration timeout**

**Status:** fixed
**Milestone:** future
**Created:** Mon Apr 04, 2016 03:00 PM UTC by Rafael
**Last Updated:** Thu Apr 21, 2016 08:32 AM UTC
**Owner:** Rafael


Increase ClcCliTimeout to avoid registration timeout on slow machines. Timeout 
is increased from 10 seconds to 100 seconds. saAmfCtDefClcCliTimeout is set in 
the SaAmfCompType object and is used as the "parent" value for the following 
SaAmfComp attributes:

saAmfCompInstantiateTimeout
saAmfCompCleanupTimeout
saAmfCompAmStartTimeout
saAmfCompAmStopTimeout

Above attributes can override the saAmfCtDefClcCliTimeout.


---

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.--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1714 Increase ClcCliTimeout to avoid registration timeout

[Rafael]

- **status**: unassigned --> fixed



---

** [tickets:#1714] Increase ClcCliTimeout to avoid registration timeout**

**Status:** fixed
**Milestone:** future
**Created:** Mon Apr 04, 2016 03:00 PM UTC by Rafael
**Last Updated:** Mon Apr 04, 2016 03:00 PM UTC
**Owner:** Rafael


Increase ClcCliTimeout to avoid registration timeout on slow machines. Timeout 
is increased from 10 seconds to 100 seconds. saAmfCtDefClcCliTimeout is set in 
the SaAmfCompType object and is used as the "parent" value for the following 
SaAmfComp attributes:

saAmfCompInstantiateTimeout
saAmfCompCleanupTimeout
saAmfCompAmStartTimeout
saAmfCompAmStopTimeout

Above attributes can override the saAmfCtDefClcCliTimeout.


---

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.--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1771 smfd: single step rollback does not call bundle scripts

[Rafael]

---

** [tickets:#1771] smfd: single step rollback does not call bundle scripts**

**Status:** assigned
**Milestone:** 5.0.RC2
**Created:** Tue Apr 19, 2016 08:08 AM UTC by Rafael
**Last Updated:** Tue Apr 19, 2016 08:08 AM UTC
**Owner:** Rafael


This is a bug introduced with opensaf change: 7354. The effect of the bug is 
that bundle scripts do not get executed when rolling back. In the software 
loading thread a variable does not get initialized when called in the rollback 
stage.


---

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.--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1714 Increase ClcCliTimeout to avoid registration timeout

[Rafael]

---

** [tickets:#1714] Increase ClcCliTimeout to avoid registration timeout**

**Status:** unassigned
**Milestone:** future
**Created:** Mon Apr 04, 2016 03:00 PM UTC by Rafael
**Last Updated:** Mon Apr 04, 2016 03:00 PM UTC
**Owner:** Rafael


Increase ClcCliTimeout to avoid registration timeout on slow machines. Timeout 
is increased from 10 seconds to 100 seconds. saAmfCtDefClcCliTimeout is set in 
the SaAmfCompType object and is used as the "parent" value for the following 
SaAmfComp attributes:

saAmfCompInstantiateTimeout
saAmfCompCleanupTimeout
saAmfCompAmStartTimeout
saAmfCompAmStopTimeout

Above attributes can override the saAmfCtDefClcCliTimeout.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1685 smfd: Merge rolling to singlestep procedures for several nodes

[Rafael]

---

** [tickets:#1685] smfd: Merge rolling to singlestep procedures for several 
nodes**

**Status:** unassigned
**Milestone:** future
**Created:** Wed Mar 02, 2016 09:20 AM UTC by Rafael
**Last Updated:** Wed Mar 02, 2016 09:20 AM UTC
**Owner:** Rafael


By extending SMF configuration we allow SMF to execute procedures in a 
optimised way. Today SMF can merge rolling procedures into one single step to 
minimize reboots. This new ticket would give SMF the additional possibility to 
have multiple single steps produced from rolling upgrades. This is in order to 
keep some services up while still reducing the amount of reboots.


---

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.--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1569 pyosaf: add sample script to scale opensaf configuration

[Rafael]

---

** [tickets:#1569] pyosaf: add sample script to scale opensaf configuration**

**Status:** unassigned
**Milestone:** 4.5.2
**Created:** Mon Oct 26, 2015 09:20 AM UTC by Rafael
**Last Updated:** Mon Oct 26, 2015 09:20 AM UTC
**Owner:** Rafael





---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1569 pyosaf: add sample script to scale opensaf configuration

[Rafael]

- Description has changed:

Diff:



--- old
+++ new
@@ -0,0 +1,3 @@
+Sample that uses the pyosaf API to scale-out/in nodes in the cluster. The 
script will create objects in IMM using a provided node as a template. It will 
create the AMF configuration objects needed for a node to be included in the 
cluster. It is assumed that the binaries are already installed on the new node. 
Object creation or deletion is done in one CCB.
+
+Example scale-out: python scaling.py --hostname TEST



- **status**: unassigned --> review
- **Milestone**: 4.5.2 --> 5.0



---

** [tickets:#1569] pyosaf: add sample script to scale opensaf configuration**

**Status:** review
**Milestone:** 5.0
**Created:** Mon Oct 26, 2015 09:20 AM UTC by Rafael
**Last Updated:** Mon Oct 26, 2015 09:20 AM UTC
**Owner:** Rafael


Sample that uses the pyosaf API to scale-out/in nodes in the cluster. The 
script will create objects in IMM using a provided node as a template. It will 
create the AMF configuration objects needed for a node to be included in the 
cluster. It is assumed that the binaries are already installed on the new node. 
Object creation or deletion is done in one CCB.

Example scale-out: python scaling.py --hostname TEST


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

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

[Rafael]

---

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

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


To reproduce it run:

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

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

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



---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets