I the defect only occurs in a headless system, then I think the ticket slogan,
or at least the description sholud say so.
---
** [tickets:#2418] imm: Info of dead IMMND remains in standby IMMD**
**Status:** review
**Milestone:** 5.0.2
**Created:** Mon Apr 10, 2017 10:23 AM UTC by Hung Nguyen
TRY_AGAIN ok.
But ERR_TIMEOUT ? Not sure what you are doing here.
The two error codes are different in meaning.
TRY_AGAIN means the client KNOWS that the call was NOT processed.
TIMEOUT mens the client does NOT KNOW if the call was processed in the server
or not.
TIMEOUT may be (is
Note also that the IMMD does not "crash", it exits.
Mar 23 11:06:12 SO-SLOT-1 osafimmd[2138]: ER IMM RELOAD with NO persistent back
end => ensure cluster restart by IMMD exit at both SCs, exiting
---
** [tickets:#2393] Immd got crashed on Active as immnd restarted on Active with
cluster
- **Comment**:
Unless this ticket describes system that has been configured to allow a
headless/SC-absence, then the above is expected behavior and this ticket is
invalid.
I see no mention of headless/sc-absence mentioned.
The cluster has to reload because the IMMND at a payload can not take
First, this ticket should not be a defect.
The log level of the ccb commit messages is intentional, the motive being to
have a record of if and when a CCB was committed.
Second, having a record o configuration changes at hte OpensAF level is
normally necesssary
for analyzing a reproted problem
The slogan of this ticket and the analysis done in this ticket was missleading
since the observed
error really had nothing specifically to do to with deltion of objects, but
rather with the setting of
adminOwner over many objects.
Most likely that confusion stems from observations done using
To summarize, the 10k limit is not per CCB but per adminOwnerSet call.
The limit has nothing to do with avoiding "corruption in IMM".
It simply has to do with the size of some messages being sent over the system.
The ticket needs to be re-writen/re-defined. Best probably to close this one
and
Note also that it is adminOwnerSet that fails with ERR_LIBRARY
saImmOmAdminOwnerSet FAILED: SA_AIS_ERR_LIBRARY (2
and not saImmOmCcbObjectDelete.
---
** [tickets:#2284] IMM: Improper return code without any error string while
deleting large number of objects**
**Status:** unassigned
I am not aware of any size limitation for CCBs in IMM as such. Even if there
was, exeeding it would result in some kind of explicit resource/timeout error
for that case and absolutely not
"database corruption".
There IS a size limitation for the database total number of objects. If I
- **summary**: imm: CCB operations fail after SC absence --> imm: CCB
operations fail after SC absence (Headless)
- **Comment**:
Added "headless" clarification because "AC absence" can be missunderstood as
just one (out of normally two) SCs being absent.
---
** [tickets:#2323] imm: CCB
- **Comment**:
I have a several problems wiith this ticket.
First, the problem description is both incorrect and incomplete.
Point 7 is incorrect because the alternative and simplest way to clear the
issue is to
re-enable the PBE. It even says so in the pasted warning message in the ticket.
- **Comment**:
Instead of seing this as a minor defect, it could seen as being part of
enhancement #56.
There are a lot of "missleading" log messages when shutting down OpenSAF. The
main reason is that OpenSAFs intended normal use is to never shut down (except
during testing).
---
**
- **status**: accepted --> assigned
- **assigned_to**: Anders Bjornerstedt --> Zoran Milinkovic
---
** [tickets:#48] IMM: Support for transactionally safe reads**
**Status:** assigned
**Milestone:** 5.0.FC
**Created:** Wed May 08, 2013 07:48 AM UTC by Anders Bjornerstedt
**Last Updated:
- Description has changed:
Diff:
--- old
+++ new
@@ -1,4 +1,4 @@
-When CCB is applied, the CCB may receive multiple error strings from more OIs.
-Ticket #744 implemented validation/resource abort error strings in the way
that the precedence has the first receiving error string. Other
I see this as a duplicate of #1291, which is closed as invalid.
The basic problem is communication overload.
The only available current solution for deployments that see this issue is to
reduce the
value for the opensafImmSyncBatchSize config attribute in the OpensAF IMM
service object:
- **status**: review --> accepted
- **Comment**:
I nack'ed the patch because the imm service already has a restart mechanism for
the PBE if
it gets stuck and the symptom shown here must result from a bug (if this truly
is on 1PBE).
If there is not enough information to locate the bug, then the
Question: How can this case happen for the 1PBE case when there is only one
user thread using the sqlite instance ?
Another relevant question is why/when do you observe this now ?
The test case or test setup must be special somehow.
With only one thread this case should be impossible.
It
I looked at the code and the error message is correct but the "lock" is the PBE
"spin lock" created
for handling 2PBE. The fact that it finds it locked in 1PBE means there is a
logical bug somewhere
in 1PBE.
Most likely some error case where there is a bailout from commit processing
without
I guess it could be that the pbe level message "Sqlite db locked by other
thread" is plain wrong,
i.e. missleading.
---
** [tickets:#1526] imm: exit the 1PBE when pbeBeginTrans sees db as locked**
**Status:** review
**Milestone:** 4.5.2
**Created:** Wed Oct 07, 2015 09:43 AM UTC by
- **summary**: imm: exit the 1PBE when pbeBeginTrans sees db as locked -->
imm: 1PBE can see db as locked
- **Comment**:
Changed ticket slogan to describe the problem.
---
** [tickets:#1526] imm: 1PBE can see db as locked**
**Status:** review
**Milestone:** 4.5.2
**Created:** Wed Oct 07,
- **status**: review --> fixed
- **Comment**:
changeset: 6979:2a5befe801cf
tag: tip
parent: 6977:93c7269c4797
user: Anders Bjornerstedt <anders.bjornerst...@ericsson.com>
date:Wed Oct 07 12:42:52 2015 +0200
summary: IMM: Update immsv/README descr
- **status**: review --> accepted
---
** [tickets:#1499] IMM: Update immsv/README describing imm enhancements in 4.7**
**Status:** accepted
**Milestone:** 4.7.RC1
**Created:** Thu Sep 24, 2015 10:55 AM UTC by Anders Bjornerstedt
**Last Updated:** Fri Oct 02, 2015 11:04 AM UTC
**Ow
- **status**: accepted --> review
---
** [tickets:#1499] IMM: Update immsv/README describing imm enhancements in 4.7**
**Status:** review
**Milestone:** 4.7.RC1
**Created:** Thu Sep 24, 2015 10:55 AM UTC by Anders Bjornerstedt
**Last Updated:** Mon Oct 05, 2015 08:27 AM UTC
**Owner:** And
The is also a timeout on the OI callback (the create callback harboring the
Augmentation).
Normally the OI timeout is shorter than the IMMA_SYNCR_TIMEOUT and so normally
the
OM client should get an error on the ccb-create downcall before timeout.
But if the OM lcient has erduced the syncr
Yes I forgot that the OI callback timeout gets disabled by a ccb augmentation
inside
the callback.
---
** [tickets:#1503] IMM: Augumented CCb client went down the OM client should
get err**
**Status:** assigned
**Milestone:** 4.5.2
**Created:** Fri Sep 25, 2015 09:18 AM UTC by Neelakanta
- **status**: accepted --> review
---
** [tickets:#1499] IMM: Update immsv/README describing imm enhancements in 4.7**
**Status:** review
**Milestone:** 4.7.RC1
**Created:** Thu Sep 24, 2015 10:55 AM UTC by Anders Bjornerstedt
**Last Updated:** Thu Oct 01, 2015 02:37 PM UTC
**Owner:** And
- **status**: assigned --> unassigned
- **Milestone**: future --> 5.0
---
** [tickets:#1425] IMM: Add attribute def flag SA_IMM_ATTR_STRONG_DEFAULT**
**Status:** unassigned
**Milestone:** 5.0
**Created:** Fri Jul 24, 2015 12:49 PM UTC by Anders Bjornerstedt
**Last Updated:** Wed Sep 23
- **status**: unassigned --> accepted
---
** [tickets:#1425] IMM: Add attribute def flag SA_IMM_ATTR_STRONG_DEFAULT**
**Status:** accepted
**Milestone:** 5.0
**Created:** Fri Jul 24, 2015 12:49 PM UTC by Anders Bjornerstedt
**Last Updated:** Thu Oct 01, 2015 10:38 AM UTC
**Owner:** H
- **Comment**:
I have a problem with this ticket.
Appliers are intentionally not synced.
They should not need to be synced.
The question here is how you manage to execute a sync with a ccb being active.
Non empty Ccbs are terminated before the actual sync can start.
So there seems to have been
With the above solution there is the issue that the check is then not done in
fevs order.
By the time the implementer-set arrives over fevs at all nodes, there may have
been creaed a
ccb-operation that interferes, resulting in the implementer-set having to be
aborted anyway.
The local immnd
- **summary**: imm: Appliers for classes and objects are not synced to
sync-client --> imm: Implicit class/object-applier checked by OiImplementeSet
is incorrect
---
** [tickets:#1504] imm: Implicit class/object-applier checked by
OiImplementeSet is incorrect**
**Status:** assigned
The applier-names are synced but the class/object-applier data is not sync-ed.
That is intentional and I dont want a solution that tries to sync all applier
information to all nodes.
The class-applier and object-applier mechanism is inherrently local, i.e. only
used at the node where
the
The problem is the feature of *implicit* class-implementer-set and *implicit*
object-implementer-set.
Ironically this feature is parctically useless for appliers.
One possible (and relatively simple) solution would be to only do the ccb
interference checks for
*appliers* at the node where the
- **status**: unassigned --> duplicate
- **Component**: osaf --> log
- **Version**: 4.6 FC --> 4.6
- **Milestone**: 4.5.1 --> never
- **Comment**:
Duplicate of #1452 which is fixed.
https://sourceforge.net/p/opensaf/tickets/1452/
---
** [tickets:#1313] osaf: opensaf does not start when long
- **Version**: --> 4.7
---
** [tickets:#1494] imm: missmatch in obj_create_rsp event type**
**Status:** review
**Milestone:** 4.7.FC
**Created:** Tue Sep 22, 2015 05:52 AM UTC by Neelakanta Reddy
**Last Updated:** Tue Sep 22, 2015 06:06 AM UTC
**Owner:** Neelakanta Reddy
immnd_evt.c:3756:
- **status**: unassigned --> invalid
- **Comment**:
If the problem is to be declared as a configuration error, i.e. solvable by
adjusting one or more
configuration values that are documented by OpenSAF, then the ticket should be
closed as
invalid.
---
** [tickets:#1291] IMM: IMMD
- **Milestone**: 4.7.FC --> future
---
** [tickets:#1269] IMM: Library side behavior at failure to allocatge memory
needs to be consistent**
**Status:** assigned
**Milestone:** future
**Created:** Tue Mar 17, 2015 10:24 AM UTC by Anders Bjornerstedt
**Last Updated:** Tue Aug 25, 2015 04
- **status**: unassigned --> assigned
- **assigned_to**: Hung Nguyen
---
** [tickets:#1474] imm: Assigning default value to no-dangling attributes make
cluster fail to start**
**Status:** assigned
**Milestone:** 4.5.2
**Created:** Thu Sep 10, 2015 02:27 PM UTC by Hung Nguyen
**Last
- **Priority**: major --> critical
- **Comment**:
Raising severity to critical since the symptom caused by this defect is severe.
I propose that the solution is to not allow default values to be defined for
attributes flagged with NO_DANGLING in the class definition.
---
** [tickets:#1474]
- **Priority**: major --> critical
- **Comment**:
Raising severity to critical for this ticket since the symptom is an
inconsistency in the imm database between nodes.
---
** [tickets:#1472] imm: Default values are assigned to empty-valued attributes
when sync**
**Status:** review
for this to be a defect.
[tickets:#1448]http://sourceforge.net/p/opensaf/tickets/1448/ smf: Make
campaigns less fragile by retrying on ERR_NO_RESOURCES
Status: unassigned
Milestone: future
Created: Fri Aug 14, 2015 07:09 AM UTC by Anders Bjornerstedt
Last Updated: Tue Aug 25
this treatment for OI APIs?
[tickets:#1448]http://sourceforge.net/p/opensaf/tickets/1448/ smf: Make
campaigns less fragile by retrying on ERR_NO_RESOURCES
Status: unassigned
Milestone: future
Created: Fri Aug 14, 2015 07:09 AM UTC by Anders Bjornerstedt
Last Updated: Tue Aug
- **summary**: Not possible to add/remove configuration for one node in one
single CCB -- AMF: Not possible to add/remove configuration for one node in
one single CCB
---
** [tickets:#1458] AMF: Not possible to add/remove configuration for one node
in one single CCB**
**Status:** accepted
:** future
**Created:** Fri Aug 14, 2015 07:09 AM UTC by Anders Bjornerstedt
**Last Updated:** Tue Aug 25, 2015 09:28 AM UTC
**Owner:** nobody
The SMF service is a heavy user of the IMM service.
The IMM has an established client pattern for ERR_TRY_AGAIN which allows an
application realtime
control
.
---
** [tickets:#1448] smf: Make campaigns less fragile by retrying on
ERR_NO_RESOURCES**
**Status:** unassigned
**Milestone:** future
**Created:** Fri Aug 14, 2015 07:09 AM UTC by Anders Bjornerstedt
**Last Updated:** Tue Aug 25, 2015 10:56 AM UTC
**Owner:** nobody
The SMF service is a heavy user
- **status**: unassigned -- invalid
- **Milestone**: 4.5.2 -- 4.7-Tentative
- **Comment**:
This behavior is well documented in the immsv README (and should also be so in
the IMMSV_PR) since OpenSAF4.3. It has worked this way since OpenSAF was
created.
My opinion is that the real problem is the
- **summary**: imm: Don't check for pending fevs when updating pure runtime
attributes -- imm: Don't check for pending fevs when only updating pure
runtime attributes
- **Comment**:
The optimization is only for the pure and local case.
This should typically be the case for a pure RTA update,
- **status**: unassigned -- assigned
- **assigned_to**: Zoran Milinkovic
---
** [tickets:#1449] IMM: CCB interface for probing abort reason (validation
error or resource error)**
**Status:** assigned
**Milestone:** 4.7-Tentative
**Created:** Fri Aug 14, 2015 08:33 AM UTC by Anders
- **Component**: imm -- mds
- **Comment**:
The IMMD is blocked on the (asyncronous) broadcast of *one* fevs message for
more than 3 minutes. Changing component to MDS.
A reelvant question is what is otherwise special about this test.
Is MDS TCP used and not TIPC (MDS broadcast uses TIPC
Ok but then the question simply becomes why does the healthcheck callback not
reach the IMMND or why does the IMMND reply
not reach the AMFND ?
/AndersBj
From: Sirisha Alla [mailto:al...@users.sf.net]
Sent: den 19 augusti 2015 10:50
To: [opensaf:tickets]
Subject: [opensaf:tickets] #1291 IMM:
The IMMD sends one fevs message at a time for each poll cycle.
Also in each poll cycle it checks the AMF descriptor for healthcheck callbacks.
This means that the IMMD is blocked for more than 3 minutes on broadcasting one
fevs message.
The IMMSV_DEFAULT_FEVS_MAX_PENDING) affects the IMMND
Changeset 6744 is generated today.
So I assume this means you reproduced this today.
The IMMND main poll handling processes in sequence on each descriptor, so it
should not be possible
For traffic on one descriptor to starve out a job on another.
/AndersBj
From: Anders Bjornerstedt
controller rebooted in middle of IMMND sync
Yes, I tried this today. The healthcheck timeout happened on IMMD not on IMMND.
/Sirisha
On Wednesday 19 August 2015 02:28 PM, Anders Bjornerstedt wrote:
Changeset 6744 is generated today.
So I assume this means you reproduced this today.
The IMMND
- **Comment**:
I propose that we increase the saAmfHctDefMaxDuration value from 3 minutes to
5 minutes in:
safHealthcheckKey=Default,safVersion=4.0.0,safCompType=OpenSafCompTypeIMMND
This is the only thing that can be done in the IMMSv.
The other alternatives are:
(1)
Place the ticket on
Possibly yes.
You could look at it this way.
Every application is free to perform unnecessarily inefficient searches.
A global search actually causes the local IMMND to copy the entire database.
In this case the LOg subtree probably contains less than 10 objects.
In general yes optimizations are
regardless of any
changes of handling long DNs that may be done in the future. This will not
change any behavior of the log service except that it maybe will start a little
bit faster and use less resources.
/Lennart
From: Anders Bjornerstedt [mailto:ander...@users.sf.net]
Sent: den 17 augusti 2015
Yes in my opinion.
But maybe we need a vote :)
/AndersBj
From: elunlen [mailto:elun...@users.sf.net]
Sent: den 17 augusti 2015 15:04
To: [opensaf:tickets]
Subject: [opensaf:tickets] #1452 LOG: Use root name when searching for stream
objects
Is it Ok then to push this fix to all active
I suggest we close this defect ticket as not reproducible.
That is unless someone can reproduce it.
My best guess is that this is yet another side effect of testing an overloaded
system.
Since we have no load regulation mechanism and no overload protection mechanism,
it is relatively easy to
- **Type**: defect -- enhancement
- **Milestone**: 4.5.2 -- 4.7-Tentative
- **Comment**:
This is an enhancement not a defect.
There is no vilation of interface or behavior on the imm part related to this
ticket.
Any IMM call can result in TRY_AGAIN and particularly calls going remote.
This call
---
** [tickets:#1448] smf: Make campaigns less fragile by retrying on
ERR_NO_RESOURCES**
**Status:** unassigned
**Milestone:** future
**Created:** Fri Aug 14, 2015 07:09 AM UTC by Anders Bjornerstedt
**Last Updated:** Fri Aug 14, 2015 07:09 AM UTC
**Owner:** nobody
The SMF service
- **Milestone**: future -- 4.6.1
---
** [tickets:#58] IMM: IMM internally should create CCB error strings**
**Status:** fixed
**Milestone:** 4.6.1
**Created:** Wed May 08, 2013 08:35 AM UTC by Anders Bjornerstedt
**Last Updated:** Fri Aug 14, 2015 08:04 AM UTC
**Owner:** nobody
Migrated
---
** [tickets:#1449] IMM: CCB interface for probing abort reason (validation
error or resource error)**
**Status:** unassigned
**Milestone:** 4.7-Tentative
**Created:** Fri Aug 14, 2015 08:33 AM UTC by Anders Bjornerstedt
**Last Updated:** Fri Aug 14, 2015 08:33 AM UTC
**Owner:** nobody
(validation
error or resource error)**
**Status:** unassigned
**Milestone:** 4.7-Tentative
**Created:** Fri Aug 14, 2015 08:33 AM UTC by Anders Bjornerstedt
**Last Updated:** Fri Aug 14, 2015 08:33 AM UTC
**Owner:** nobody
Suggested interface, closely related to saImmOmCcbGetErrorStrings
May 08, 2013 08:35 AM UTC by Anders Bjornerstedt
**Last Updated:** Wed May 08, 2013 08:35 AM UTC
**Owner:** nobody
Migrated from:
http://devel.opensaf.org/ticket/2712
For example in this case:
Jul 3 12:39:55.177799 osafimmnd [17744:ImmModel.cc:5146] T7
ERR_NOT_EXIST: object 'safSmfBundle=XXX
for
this to be used for programmable handling of abort reason. A separate ticket
will be created for that.
---
** [tickets:#744] IMM: Use error string to classify cause for aborted CCB.**
**Status:** unassigned
**Milestone:** future
**Created:** Thu Jan 23, 2014 12:17 PM UTC by Anders
- **Milestone**: future -- 4.7-Tentative
---
** [tickets:#744] IMM: Use error string to classify cause for aborted CCB.**
**Status:** unassigned
**Milestone:** 4.7-Tentative
**Created:** Thu Jan 23, 2014 12:17 PM UTC by Anders Bjornerstedt
**Last Updated:** Fri Aug 14, 2015 08:13 AM UTC
- **Comment**:
I think this ticket should be closed as invalid.
The mechanism works as documented.
The only relevant defect related to this incident is #1430 and it has been
fixed.
https://sourceforge.net/p/opensaf/tickets/1430/
That is an application that does a search with a scope that does
It makes absolutely no sense to have a defect ticket on a future release.
/AndersBj
From: A V Mahesh (AVM) [mailto:avmah...@users.sf.net]
Sent: den 6 augusti 2015 06:22
To: [opensaf:tickets]
Subject: [opensaf:tickets] #246 cpsv: Section create fails with random return
values when mulitple
From: Anders Bjornerstedt [mailto:ander...@users.sf.net]
Sent: den 10 augusti 2015 09:02
To: [opensaf:tickets]
Subject: [opensaf:tickets] Re: #246 cpsv: Section create fails with random
return values when mulitple processes try to create sections in the same
checkpoint 70 node setup.
It makes
- **Milestone**: 4.7-Tentative -- 4.6.1
---
** [tickets:#1436] MDS (TCP transport) fragment gets dropped, not received on
standby node**
**Status:** unassigned
**Milestone:** 4.6.1
**Created:** Thu Aug 06, 2015 06:47 AM UTC by Girish
**Last Updated:** Mon Aug 10, 2015 04:25 AM UTC
**Owner:**
- **status**: review -- fixed
- **Comment**:
changeset: 6681:87d18f870326
tag: tip
user:Johan Mårtensson johan.o.martens...@ericsson.com
date:Thu Jul 16 14:25:08 2015 +0200
summary: pyosaf: (updated) Add parameter to Ccb constructor to set exact
CCB flags [#1417]
---
** [tickets:#1425] IMM: Add attribute def flag SA_IMM_ATTR_STRONG_DEFAULT**
**Status:** unassigned
**Milestone:** future
**Created:** Fri Jul 24, 2015 12:49 PM UTC by Anders Bjornerstedt
**Last Updated:** Fri Jul 24, 2015 12:49 PM UTC
**Owner:** nobody
The saImmOmClassCreate_2() API
- **status**: unassigned -- assigned
- **assigned_to**: Hung Nguyen
---
** [tickets:#1424] Agent crash leaving zombie OI**
**Status:** assigned
**Milestone:** 4.5.2
**Created:** Wed Jul 22, 2015 10:34 AM UTC by Hung Nguyen
**Last Updated:** Wed Jul 22, 2015 10:34 AM UTC
**Owner:** Hung Nguyen
- **Type**: defect -- enhancement
---
** [tickets:#171] saAmfComponentUnregister should be unexposed to handle
obtained from B 4 1 version**
**Status:** unassigned
**Milestone:** future
**Created:** Tue May 14, 2013 06:01 AM UTC by Nagendra Kumar
**Last Updated:** Tue May 14, 2013 06:01 AM
- **Type**: defect -- enhancement
---
** [tickets:#167] AMF: CSI descriptor for standby assignment contains wrong
info**
**Status:** unassigned
**Milestone:** future
**Created:** Tue May 14, 2013 04:50 AM UTC by Nagendra Kumar
**Last Updated:** Tue May 14, 2013 04:50 AM UTC
**Owner:** nobody
- **Type**: defect -- enhancement
---
** [tickets:#168] saAmfComponentErrorReport() - errorDetectionTime not
initialized by library**
**Status:** unassigned
**Milestone:** future
**Created:** Tue May 14, 2013 05:37 AM UTC by Nagendra Kumar
**Last Updated:** Tue May 14, 2013 05:37 AM UTC
- **Type**: defect -- enhancement
---
** [tickets:#178] escalation policy is not happening till the restart count
exceeds, instead of reaching saAmfSGCompRestartMax for NPI components**
**Status:** unassigned
**Milestone:** future
**Created:** Tue May 14, 2013 06:24 AM UTC by Nagendra Kumar
- **Type**: defect -- enhancement
---
** [tickets:#183] component's operational state and SU's presence state are not
updated in the multiple NPI components instantiation failure**
**Status:** unassigned
**Milestone:** future
**Created:** Tue May 14, 2013 07:00 AM UTC by Nagendra Kumar
- **Type**: defect -- enhancement
---
** [tickets:#181] aAmfPmStart and Stop APIs with pmErrors =
SA_AMF_PM_ABNORMAL_END gives ERR_INVALID_PARAM instead of OK.**
**Status:** assigned
**Milestone:** future
**Created:** Tue May 14, 2013 06:54 AM UTC by Nagendra Kumar
**Last Updated:** Tue Aug
- **Type**: defect -- enhancement
---
** [tickets:#185] AMF: unnecessary/wrong updates of pure runtime attributes**
**Status:** accepted
**Milestone:** future
**Created:** Tue May 14, 2013 07:20 AM UTC by Nagendra Kumar
**Last Updated:** Mon Jun 02, 2014 05:39 AM UTC
**Owner:** Gary Lee
- **Type**: defect -- enhancement
---
** [tickets:#188] Use of pkill terminates the CLC-SCRIPT with a signal making
amf think the component termination failed.**
**Status:** unassigned
**Milestone:** future
**Created:** Tue May 14, 2013 07:41 AM UTC by Nagendra Kumar
**Last Updated:** Tue
- **Type**: defect -- enhancement
---
** [tickets:#174] admin unlock operation on SU in shutting down state should be
succeded**
**Status:** unassigned
**Milestone:** future
**Created:** Tue May 14, 2013 06:16 AM UTC by Nagendra Kumar
**Last Updated:** Tue May 14, 2013 06:16 AM UTC
- **Type**: defect -- enhancement
---
** [tickets:#173] protection group callback is giving null info when component
moves from quiesced to no redundancy**
**Status:** review
**Milestone:** 4.5.2
**Created:** Tue May 14, 2013 06:13 AM UTC by Nagendra Kumar
**Last Updated:** Wed Jul 08, 2015
- **Type**: defect -- enhancement
---
** [tickets:#177] N+M redandancy model was coming up with assignments even if
component capability used is SA_AMF_COMP_ONE_ACTIVE_OR_ONE_STANDBY.**
**Status:** unassigned
**Milestone:** future
**Created:** Tue May 14, 2013 06:21 AM UTC by Nagendra Kumar
- **Type**: defect -- enhancement
---
** [tickets:#172] AVSv:Loops in the csi dependencies should be checked during
config validatation and rejetcted**
**Status:** review
**Milestone:** 4.5.2
**Created:** Tue May 14, 2013 06:10 AM UTC by Nagendra Kumar
**Last Updated:** Fri Jul 10, 2015
- **Type**: defect -- enhancement
---
** [tickets:#163] AMF: Auto-adjust for standby assignments in NWay red. model
does not work**
**Status:** unassigned
**Milestone:** future
**Created:** Tue May 14, 2013 04:39 AM UTC by Nagendra Kumar
**Last Updated:** Tue May 14, 2013 04:39 AM UTC
- **Type**: defect -- enhancement
---
** [tickets:#164] AMF does not validate existence in model of SU for
SaAmfSIRankedSU objects**
**Status:** review
**Milestone:** 4.5.2
**Created:** Tue May 14, 2013 04:41 AM UTC by Nagendra Kumar
**Last Updated:** Wed Jul 01, 2015 07:22 AM UTC
**Owner:**
- **Type**: defect -- enhancement
---
** [tickets:#166] AMF: creating an SaAmfSIRankedSU object with rank==0 causes
inconsistence**
**Status:** unassigned
**Milestone:** future
**Created:** Tue May 14, 2013 04:48 AM UTC by Nagendra Kumar
**Last Updated:** Tue May 14, 2013 04:48 AM UTC
- **status**: assigned -- review
---
** [tickets:#1417] pyosaf: Add flag to Ccb class to let the user control the
SA_IMM_CCB_REGISTERED flag**
**Status:** review
**Milestone:** 4.6.1
**Created:** Tue Jul 14, 2015 07:00 AM UTC by Johan Mårtensson
**Last Updated:** Tue Jul 14, 2015 07:00 AM
- **status**: assigned -- review
---
** [tickets:#1418] pyosaf: Add convenience method to clear admin owner role on
a set of objects**
**Status:** review
**Milestone:** 4.7-Tentative
**Created:** Tue Jul 14, 2015 08:03 AM UTC by Johan Mårtensson
**Last Updated:** Tue Jul 14, 2015 08:38 AM
- **Milestone**: 4.6.1 -- 4.7-Tentative
---
** [tickets:#1417] pyosaf: Add flag to Ccb class to let the user control the
SA_IMM_CCB_REGISTERED flag**
**Status:** review
**Milestone:** 4.7-Tentative
**Created:** Tue Jul 14, 2015 07:00 AM UTC by Johan Mårtensson
**Last Updated:** Wed Jul 15,
- **Milestone**: future -- 4.5.2
---
** [tickets:#1414] amfd: N+M wrong assigment with SI dependency and role
failure**
**Status:** review
**Milestone:** 4.5.2
**Created:** Mon Jul 13, 2015 05:32 PM UTC by Alex Jones
**Last Updated:** Wed Jul 15, 2015 09:04 AM UTC
**Owner:** Alex Jones
- **Milestone**: 4.6.1 -- 4.5.2
---
** [tickets:#1410] pyosaf: Invalid exception used in ImmObject (object.py)**
**Status:** unassigned
**Milestone:** 4.5.2
**Created:** Fri Jul 10, 2015 10:11 AM UTC by Johan Mårtensson
**Last Updated:** Fri Jul 10, 2015 10:11 AM UTC
**Owner:** nobody
- **Version**: 4.5.2 -- 4.5
---
** [tickets:#1410] pyosaf: Invalid exception used in ImmObject (object.py)**
**Status:** unassigned
**Milestone:** 4.5.2
**Created:** Fri Jul 10, 2015 10:11 AM UTC by Johan Mårtensson
**Last Updated:** Wed Jul 15, 2015 12:46 PM UTC
**Owner:** nobody
ImmObject
- **Milestone**: 4.7-Tentative -- future
---
** [tickets:#1398] smf: Add capability to redo CCBs that fail **
**Status:** unassigned
**Milestone:** future
**Created:** Wed Jul 01, 2015 02:07 PM UTC by Rafael
**Last Updated:** Mon Jul 13, 2015 09:51 AM UTC
**Owner:** nobody
CCBs may fail for
- **Version**: 4.5.2 --
---
** [tickets:#1417] pyosaf: Add flag to Ccb class to let the user control the
SA_IMM_CCB_REGISTERED flag**
**Status:** review
**Milestone:** 4.7-Tentative
**Created:** Tue Jul 14, 2015 07:00 AM UTC by Johan Mårtensson
**Last Updated:** Wed Jul 15, 2015 12:42 PM
- **Type**: defect -- enhancement
---
** [tickets:#144] LOG: LOG server hangs with huge log records**
**Status:** unassigned
**Milestone:** future
**Created:** Mon May 13, 2013 11:08 AM UTC by elunlen
**Last Updated:** Mon May 13, 2013 11:48 AM UTC
**Owner:** elunlen
Playing around testing
- **Type**: defect -- enhancement
---
** [tickets:#135] SI unassignment failed for SU on node lock**
**Status:** unassigned
**Milestone:** future
**Created:** Mon May 13, 2013 10:23 AM UTC by surender khetavath
**Last Updated:** Tue May 21, 2013 10:02 AM UTC
**Owner:** nobody
Changeset :
- **Type**: defect -- enhancement
---
** [tickets:#123] Sample SMF RPM integration**
**Status:** unassigned
**Milestone:** future
**Created:** Mon May 13, 2013 08:48 AM UTC by Ingvar Bergström
**Last Updated:** Mon May 13, 2013 08:48 AM UTC
**Owner:** nobody
- **Type**: defect -- enhancement
---
** [tickets:#6] Amfd crashed on active controller**
**Status:** unassigned
**Milestone:** future
**Created:** Mon May 06, 2013 07:21 AM UTC by Nagendra Kumar
**Last Updated:** Tue Mar 24, 2015 10:33 AM UTC
**Owner:** nobody
Migrated from
1 - 100 of 1047 matches
Mail list logo
