[tickets] [opensaf:tickets] #2065 amf: support for SA_AMF_CLUSTER_RESET recommended recovery

2017-01-09 Thread Praveen
- **status**: unassigned --> accepted
- **assigned_to**: Praveen



---

** [tickets:#2065] amf: support for SA_AMF_CLUSTER_RESET recommended recovery**

**Status:** accepted
**Milestone:** 5.2.FC
**Created:** Fri Sep 23, 2016 11:54 AM UTC by Mathi Naickan
**Last Updated:** Fri Sep 23, 2016 11:54 AM UTC
**Owner:** Praveen


Support for the SA_AMF_CLUSTER_RESET = 7, Recommended recovery - both as 
configuration and for error reporting via saAmfComponentErrorReport



---

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] #2239 log: no housekeeping for cfg files

2017-01-09 Thread A V Mahesh (AVM)
- **status**: unassigned --> accepted
- **assigned_to**: A V Mahesh (AVM)
- **Comment**:


>
>
> On 1/9/2017 6:43 PM, Lennart Lund wrote:
>> Hi
>>
>> A .cfg file is created when a stream is created and it belongs to the log 
>> files owned by that stream. If the stream (application runtime) is closed by 
>> all the clients the stream is deleted an all its files are closed including 
>> the current log  file. The files are not deleted and can be seen as a 
>> package of log records that includes the .cfg file and all log files that 
>> belonged to the stream. The .cfg file is still valid and contains 
>> information about how to read the log files. In this case the .cfg file 
>> cannot be removed.
>>
>> If a configuration of a stream is changed (configuration stream) a new .cfg 
>> file is created. Also the current log file is closed and a new current log 
>> file is created. Logging is now based on the new settings. The old log files 
>> however is not deleted and the old .cfg file is still needed since it 
>> contains information about how to read the old log files (file before the 
>> change). In this case the old log files will eventually be replaced by log 
>> files with the new setting since they are still part of the file rotation. 
>> This means that when the last old log file has been rotated out also the old 
>> .cfg file can be removed (but not before that).
>>
>> Regards
>> Lennart 


On 1/10/2017 9:31 AM, A V Mahesh wrote:
> Hi Lennart,
>
> Thanks for the inputs.
>
> I did also went through SAI-AIS-LOG-A.02.01 specification to 
> finalized/decided approach on .cfg ROTATE,
> I did find  cfg File Naming Rules are defined in the specification but not 
> the ROTATE /polices/for .cfg.
>
> So it is now up to implementation to define , as you suggested the .cfg file
> can also be ROTATED concurrently whenever the log files with the same 
>  suffix
> is being ROTATED and it looks idle implementation and better approach.
>
> -AVM



---

** [tickets:#2239] log: no housekeeping for cfg files**

**Status:** accepted
**Milestone:** 5.2.FC
**Created:** Wed Dec 21, 2016 08:19 AM UTC by Vu Minh Nguyen
**Last Updated:** Wed Dec 21, 2016 08:19 AM UTC
**Owner:** A V Mahesh (AVM)


At the moment, LOGsv takes care of the housekeeping of the log files, but not 
for cfg files.

So, if we play with log streams in a long time, or we encounter an cyclic 
reboots of SCs, 
a large numbers of cfg files are generated even log files that go along with 
them have been removed due to rotation.


---

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] #2228 amfd: incorrect presence and readiness state

2017-01-09 Thread Gary Lee
- **status**: review --> fixed



---

** [tickets:#2228] amfd: incorrect presence and readiness state**

**Status:** fixed
**Milestone:** 5.0.2
**Created:** Wed Dec 14, 2016 12:51 AM UTC by Gary Lee
**Last Updated:** Mon Jan 09, 2017 03:00 AM UTC
**Owner:** Gary Lee


fm2 is shutting down while fm1 starting up. After the cluster is stable, 
amf-state shows:

safSu=SC-1,safSg=2N,safApp=YYY-ZZZ PresenceState INSTANTIATING
safSu=SC-1,safSg=2N,safApp=YYY-ZZZ ReadinessState OUT_OF_SERVICE 

It seems MBC updates for the above (to INSTANTIATED/IN_SERVICE) are either: not 
sent from fm2 to fm1 in time, or dropped by fm1 as cold sync has not completed.

fm2:

2016-12-09T13:37:30.428212+01:00 local0.notice fm2 osafimmnd[2529]: exiting for 
shutdown
2016-12-09T13:37:31.329933+01:00 local0.notice fm2 osafamfd[2606]: 
safSu=SC-1,safSg=2N,safApp=YYY-ZZZ PresenceState INSTANTIATING => INSTANTIATED
2016-12-09T13:37:31.329997+01:00 local0.notice fm2 osafamfd[2606]: 
safSu=SC-1,safSg=2N,safApp=YYY-ZZZ ReadinessState OUT_OF_SERVICE => IN_SERVICE
2016-12-09T13:37:32.259769+01:00 local0.notice fm2 osafamfd[2606]: Cold sync 
complete of 2010f
2016-12-09T13:37:33.117060+01:00 local0.notice fm2 osafamfd[2606]: exiting for 
shutdown

fm1:

2016-12-09T13:37:32.260405+01:00 local0.notice fm1 osafamfd[2572]: NO Cold sync 
complete!
2016-12-09T13:37:38.336357+01:00 local0.notice fm1 osafamfd[2572]: NO FAILOVER 
StandBy --> Active



---

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] #2255 amf: change saAmfCompCmdEnv attribute to writable

2017-01-09 Thread Long HB Nguyen
- **status**: unassigned --> assigned
- **assigned_to**: Long HB Nguyen



---

** [tickets:#2255] amf: change saAmfCompCmdEnv attribute to writable**

**Status:** assigned
**Milestone:** 5.2.FC
**Created:** Mon Jan 09, 2017 10:29 AM UTC by Long HB Nguyen
**Last Updated:** Mon Jan 09, 2017 10:29 AM UTC
**Owner:** Long HB Nguyen


Description:
Current OpenSAF implementation defines the attribute saAmfCompCmdEnv in the 
SaAmfComp object as non-writable according to last AMF specification. This 
restriction doesn’t allow to upgrade environment attributes defined at 
component instance and, to remove it, the attribute was made writable in an 
errata to the model. OpenSAF should comply to this definition in the errata 
(www.saforum.org/HOA/assn16627/images/SAI-IM-XMI-A.04.02.errata.xml.zip) of the 
AMF specification to enable the upgrade of environment attributes defined at 
component instance level.


---

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

2017-01-09 Thread 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] #2162 AMF: Headless recovery failed if SC failover during headless sync

2017-01-09 Thread Nagendra Kumar
I am reviewing it.
Thanks
-Nagu


---

** [tickets:#2162] AMF: Headless recovery failed if SC failover during headless 
sync**

**Status:** review
**Milestone:** 5.2.FC
**Labels:** headless recovery 
**Created:** Thu Nov 03, 2016 11:01 AM UTC by Minh Hon Chau
**Last Updated:** Tue Nov 08, 2016 03:29 AM UTC
**Owner:** Minh Hon Chau
**Attachments:**

- [log.tgz](https://sourceforge.net/p/opensaf/tickets/2162/attachment/log.tgz) 
(1.4 MB; application/x-compressed)


Test steps:
- Set up 2N assignment, PL4 hosts SU4 (active assignment), PL5 host SU5 
(standby assignment)
- Stop SCs
- Stop PL4
- Restart SC1
- Restart SC2
- Since PL4 is stopped, headless sync will be time out in 10 secs. During this 
10 secs, reboot SC1 to trigger SC failover
Observation: SC2 becomes active controller, cold sync complete, but SU5 still 
has standby assignment.

When SC2 becomes active controller, the part of code that performs headless 
recovery is not executed (function failover_absent_assignment()). Therefore, 
the transient assignments remain after SC failover.

Log/trace are attached.


---

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] #2255 amf: change saAmfCompCmdEnv attribute to writable

2017-01-09 Thread Long HB Nguyen



---

** [tickets:#2255] amf: change saAmfCompCmdEnv attribute to writable**

**Status:** unassigned
**Milestone:** 5.2.FC
**Created:** Mon Jan 09, 2017 10:29 AM UTC by Long HB Nguyen
**Last Updated:** Mon Jan 09, 2017 10:29 AM UTC
**Owner:** nobody


Description:
Current OpenSAF implementation defines the attribute saAmfCompCmdEnv in the 
SaAmfComp object as non-writable according to last AMF specification. This 
restriction doesn’t allow to upgrade environment attributes defined at 
component instance and, to remove it, the attribute was made writable in an 
errata to the model. OpenSAF should comply to this definition in the errata 
(www.saforum.org/HOA/assn16627/images/SAI-IM-XMI-A.04.02.errata.xml.zip) of the 
AMF specification to enable the upgrade of environment attributes defined at 
component instance level.


---

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] #89 AMF - SI lock does not honour dependencies

2017-01-09 Thread Praveen
- **status**: assigned --> unassigned



---

** [tickets:#89] AMF - SI lock does not honour dependencies**

**Status:** unassigned
**Milestone:** future
**Labels:** SI Dep 
**Created:** Mon May 13, 2013 04:51 AM UTC by Nagendra Kumar
**Last Updated:** Tue Jul 22, 2014 10:48 AM UTC
**Owner:** Praveen
**Attachments:**

- [89.patch](https://sourceforge.net/p/opensaf/tickets/89/attachment/89.patch) 
(8.5 kB; application/octet-stream)


Migrated from http://devel.opensaf.org/ticket/2501

Consider, SI C depends on B depends on A, tol tmr zero
When locking A the expected sequence should be:
C quiesced/removed
B quiesced/removed
B quiesced/removed

See  http://list.opensaf.org/pipermail/devel/2012-February/021627.html



---

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