[tickets] [opensaf:tickets] #1632 log: not handle AIS error codes properly

[Vu Minh Nguyen]

- Description has changed:

Diff:



--- old
+++ new
@@ -2,4 +2,4 @@
 
 For example, there is a case calling to saLogStreamOpen_2() will get 
`SA_AIS_ERR_NOT_SUPPORTED` error code, but in AIS A.02.01, that error code is 
not in the list of possible returned error codes of the API.
 
-More information, refer to the ticket 
[#1607](https://sourceforge.net/p/opensaf/tickets/1607/)
+More information, refer to the ticket [#1607]






---

** [tickets:#1632] log: not handle AIS error codes properly **

**Status:** unassigned
**Milestone:** 5.0.FC
**Created:** Thu Dec 10, 2015 04:12 AM UTC by Vu Minh Nguyen
**Last Updated:** Thu Dec 10, 2015 04:12 AM UTC
**Owner:** nobody


OpenSAF LOG in some places does not handle AIS codes properly. 

For example, there is a case calling to saLogStreamOpen_2() will get 
`SA_AIS_ERR_NOT_SUPPORTED` error code, but in AIS A.02.01, that error code is 
not in the list of possible returned error codes of the API.

More information, refer to the ticket [#1607]


---

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] #27 IMM: Support for some immsv service during local immnd sync.

[Neelakanta Reddy]

- **status**: unassigned --> assigned
- **assigned_to**: Anders Bjornerstedt --> Neelakanta Reddy
- **Part**: - --> nd
- **Milestone**: future --> 5.0.FC



---

** [tickets:#27] IMM:  Support for some immsv service during local immnd sync.**

**Status:** assigned
**Milestone:** 5.0.FC
**Created:** Tue May 07, 2013 10:26 AM UTC by Anders Bjornerstedt
**Last Updated:** Tue May 07, 2013 10:26 AM UTC
**Owner:** Neelakanta Reddy


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

The current implementation of imm-handle resurrect forces the
resurrect to wait until the local immnd has been synced.

This delay of the resurrect until the local immnd has been synced
makes sense as long as the client can not perform any meaningful
operations using the handle, until the local immnd is synced.

But some operations, such as implementerSet, could be possible
to support even when the local immnd is inccomplete on data.

To accomplish this, the resource allocations currently known by the immsv in 
the cluster and which are synced in 'finalizeSync', after
all the config data has been synced, could be synced
instead at start of sync.

It is already the case that many such resource allocating operations
are allowed during sync (at non sync clients) and are being
received and registered at sync clients.

In addition, reading operations (accessor-get & iteration) could
be achieved by having the imma library going remote when the local
immnd is syncing. 


---

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] #1209 IMM: OI callback timer should be restored after a ccb-augment is closed

[Neelakanta Reddy]

- **status**: unassigned --> assigned
- **assigned_to**: Neelakanta Reddy
- **Milestone**: future --> 5.0.FC



---

** [tickets:#1209] IMM: OI callback timer should be restored after a 
ccb-augment is closed**

**Status:** assigned
**Milestone:** 5.0.FC
**Created:** Tue Nov 11, 2014 12:49 PM UTC by Anders Bjornerstedt
**Last Updated:** Tue Nov 11, 2014 12:49 PM UTC
**Owner:** Neelakanta Reddy


This is related to ticket #1208.

http://sourceforge.net/p/opensaf/tickets/1208/

After an OI has closed a ccb-augmentation, the callback timer monitoring 
the liveness of the OI in that callback, should be restored. 

This requires the addition of a new message type to the IMMA->IMMND protocol.



---

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] #1383 IMM: immcfg should allow explcit admin-owner in explicit commit mode

[Neelakanta Reddy]

- **status**: unassigned --> assigned
- **assigned_to**: Neelakanta Reddy
- **Milestone**: future --> 5.0.FC



---

** [tickets:#1383] IMM: immcfg should allow explcit admin-owner in explicit 
commit mode**

**Status:** assigned
**Milestone:** 5.0.FC
**Created:** Fri Jun 05, 2015 07:30 AM UTC by Anders Bjornerstedt
**Last Updated:** Fri Jun 05, 2015 10:27 AM UTC
**Owner:** Neelakanta Reddy


The basic immcfg allows the user to explicitly set admin-owner

 immcfg -o MyAdminOwner .

In explicit commit mode this is not possible.

 # immcfg
 > immcfg -o MyAdmo
 Administrative owner name can be set only once

Setting admin-owner explicitly is necessary when operating on objects
that have admin-owner set more or less permanently. This is the case
when saImmOmAdminOwnerInitialize is invoked with the releaseOwnershipOnFinalize
argument set to SA_FALSE. 
See the SAF IMM A.02.01 spec for details on saImmOmAdminOwnerInitialize.

Possible solutions for immcfg in explicit commit mode are either:

(1) Postpone allocating the temporary admo until an explicit operation gets
invoked that is not 'immcfg -o  X' and no admo is initialized currently.

(2) If 'immcfg -o  X' is invoked in explicit commit mode while there is
currently another admo initialized, then close the current one and open the
new explicit admo.

I suggest solution (2) since it also allows a change of admo in one immcfg 
session.
The downside is that the user may shoot themselves in the foot with that one by
derailing a CCB that is under buildup. You cannot build up a CCB or a chain of 
CCBs
using one ccb-handle and several admin-oowners. One initialized CCB handle is
always associated with one initialized admin-owner handle.



---

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] #571 IMM: Internally represents NO_DANGLING reference attribute values as pointers

[Neelakanta Reddy]

- **status**: unassigned --> assigned
- **assigned_to**: Neelakanta Reddy
- **Part**: - --> nd
- **Milestone**: future --> 5.0.FC



---

** [tickets:#571] IMM: Internally represents NO_DANGLING reference attribute 
values as pointers**

**Status:** assigned
**Milestone:** 5.0.FC
**Created:** Fri Sep 20, 2013 06:54 AM UTC by Anders Bjornerstedt
**Last Updated:** Wed Nov 13, 2013 07:21 AM UTC
**Owner:** Neelakanta Reddy


This is related to the attribute reference NO_DANGLING enhancement.

https://sourceforge.net/p/opensaf/tickets/49/

The use of NO_DANGLING will (all else equal) increase the general memory
overhead for storing imm models. This is due to the need for internal 
back-pointers to make the upholding of the constraint reasonably efficient.

But the NO_DANGLING can also be exploited in the internal management of
references to save memory. Making the total internal memory cost lower 
for NO_DANGLING references than regular potentially dangling references. 

References between IMM objects are defined and managed using the SaNameT type.
The value stored in such reference attributes is the DN of the destination
object that is pointed at by attribute in the source object. 
DNs can be quite large and are likely to get larger when we support DNs
longer than 255 bytes. 

The imm server can save a lot of memory by internally representing such
reference attributes as direct pointers to the target object. Conversion back
to DN is only needed when an object is exported via a searchNext or accessorGet.

This only works for NO_DANGLING references because only such references are
guaranteed to be .. not dangling, i.e. to actually point to an existing object.

The conversion back to the regular DN can only be done for objects that 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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #195 IMM: Hardcoded limits should be made into config parameters

[Neelakanta Reddy]

- **status**: unassigned --> assigned
- **assigned_to**: Neelakanta Reddy
- **Part**: - --> nd
- **Milestone**: future --> 5.0.FC



---

** [tickets:#195] IMM: Hardcoded limits should be made into config parameters**

**Status:** assigned
**Milestone:** 5.0.FC
**Created:** Tue May 14, 2013 09:12 AM UTC by Anders Bjornerstedt
**Last Updated:** Wed Jun 19, 2013 10:03 AM UTC
**Owner:** Neelakanta Reddy


Migrated from: 
http://devel.opensaf.org/ticket/2855
-
steps:

1. Two controllers, SC-1 and SC-2.

2. Bring SC-1 up and creates more than 1000 classes

3. Bring SC-2 up, syncing will fail because the maximum supported classes in 
opensaf is 1000.

Oct 9 14:10:53 Slot-1 osafimmnd[7549]: NODE STATE-> IMM_NODE_R_AVAILABLE
Oct 9 14:10:53 Slot-1 osafimmd[7534]: Successfully announced sync. New ruling 
epoch:3
Oct 9 14:10:53 Slot-1 immload: logtrace: trace enabled to file 
/var/log/opensaf/osafimmnd, mask=0x
Oct 9 14:10:53 Slot-1 immload: Sync starting
Oct 9 14:10:58 Slot-1 immload: Synced 350 objects in total
Oct 9 14:10:58 Slot-1 osafimmnd[7549]: NODE STATE-> IMM_NODE_FULLY_AVAILABLE 
12197
Oct 9 14:10:58 Slot-1 osafimmnd[7549]: TOO MANY classes line: 1673
Oct 9 14:10:58 Slot-1 immload: immsv_finalize_sync failed!
Oct 9 14:10:58 Slot-1 immload: Sync ending ABNORMALLY
Oct 9 14:10:58 Slot-1 osafimmnd[7549]: Error code 21 returned for message type 
36 - ignoring
Oct 9 14:10:58 Slot-1 osafimmnd[7549]: SERVER STATE: IMM_SERVER_SYNC_SERVER —> 
IMM SERVER READY

The possible fix is to check the number of classes, when the class is created.
--
The problem is actually a bit more general than only the hardcoded limit
on the number of classes.

There are four hardcoded limits in:

osaf/libs/common/immsv/immsv_evt.c:

#define IMMSV_MAX_CLASSES 1000
#define IMMSV_MAX_IMPLEMENTERS 3000
#define IMMSV_MAX_ADMINOWNERS 2000
#define IMMSV_MAX_CCBS 1

All four should be moved to:
osaf/libs/common/immsv/include/immsv_api.h

Making them generally accessible to the imm server implementation code.

Then the checks on the relevant limit should be made in the relevant call in 
ImmModel?.cc

Longer term, these constants should be made into configuration parameters in the
OpenSAF-IMM configuration object.



---

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] #1425 IMM: Add attribute def flag SA_IMM_ATTR_STRONG_DEFAULT

[Hung Nguyen]

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

default (5.0)

changeset:   7165:6ae334abdd52 [6ae334]
user:Hung Nguyen 
date:Fri Dec 11 11:03:14 2015 +0700
summary: imm: Add OPENSAF_IMM_FLAG_PRT50_ALLOW value for noStdFlags [#1425]

changeset:   7166:1fda7ee00eb1 [1fda7e]
user:Hung Nguyen 
date:Fri Dec 11 11:05:37 2015 +0700
summary: imm: Introduce SA_IMM_ATTR_STRONG_DEFAULT flag [#1425]

changeset:   7167:83996f61a055 [83996f]
user:Hung Nguyen 
date:Fri Dec 11 11:46:21 2015 +0700
summary: imm: Support SA_IMM_ATTR_STRONG_DEFAULT flag [#1425]

changeset:   7168:f5e8fbc8f2a4 [f5e8fb]
user:Hung Nguyen 
date:Fri Dec 11 11:49:46 2015 +0700
summary: imm: Add support for strong default to IMM tools [#1425]

changeset:   7169:5a954d0f2fc9 [5a954d]
user:Hung Nguyen 
date:Fri Dec 11 11:50:25 2015 +0700
summary: imm: Add test cases for strong default [#1425]





---

** [tickets:#1425] IMM: Add attribute def flag SA_IMM_ATTR_STRONG_DEFAULT**

**Status:** fixed
**Milestone:** 5.0.FC
**Created:** Fri Jul 24, 2015 12:49 PM UTC by Anders Bjornerstedt
**Last Updated:** Mon Nov 23, 2015 03:33 AM UTC
**Owner:** Hung Nguyen


The saImmOmClassCreate_2() API allows the user to provide a list of attribute 
definitions. An attribute definition may include a default value.

The default value will be assigned to this attribute in an instance being 
created
by the saImmOmCcbObjectCreate_2() or the saImmOiRtObjectCreate_2() APIs, if the
user does not provide a value for that attribute.

But a user/OI may later update such an object/attribute assigning the empty 
value
to the attribute. So the default value mechanism is only effective for object
creation and not later in the life cycle of the object. This makes the default
attribute value mechanism weaker than some users would like. 

This enhancement proposes a new attribute flag SA_IMM_ATTR_STRONG_DEFAULT.
This flag will only be allowed to be set on an attribute definition that 
includes
a default value.

The meaning of the flag is that if a user attempts an update of an 
object/attribute
that assigns the empty value to such an attribute, then the IMM will replace, 
i.e.
override, that value with the default value defined in the class.





---

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