#2985 imm: allow empty value attribute with default tag to persist

[Vu Minh Nguyen]

When replacing value of an attribute which has default-value tag with NULL during runtime, NULL value will be replaced with its default value after cluster is rebooted; in other words, that value is not persisted.

Let's take an example: user defines an attribute maxAge which shows how many days user passwords will be expired, default is 30 days; if replacing with a NULL/empty, it means the passwords will never get expired.

When the exisiting value is replaced with NULL during runtime, then cluster is rebooted, that value is silently replaced with the default without notice of user.

This behavior is clearly documented in IMM:

(iii) Default values are assigned at cluster restart for any attributes that are null/empty and that have a default.

But with the need of above use case, this ticket proposes a change that empty value attribute with default tag will remain empty for subsequent executive reads even after cluster is rebooted.

The proposal:
1) Introduce a notation in IMM model file (XML) that represents a NULL value.
<value xsi:nil="“true”"></value>

2) Allow only IMM loader to send the attribute descriptor which has NULL value to IMMND when creating IMM object. Other applications will get default value for NULL attribute when creating object as exactly as legacy behavior is doing.

[Vu Minh Nguyen]

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

[Vu Minh Nguyen]

Update commit message.
https://sourceforge.net/p/opensaf/mailman/message/36497498/

[elunlen]

The ticket should be set invalid.

To me it seems as if the use case described in the ticket is not really valid even if the IMM behavior is a bit inconsistent (value=<empty> is replaced by default at restart but other values are not). If I have understood it correctly you say that an attribute where an empty value has a significant meaning (from ticket: MaxAge=<empty> means that a password never expires). This is in itself not an invalid use case but there is already a way to avoid this behavior and that is to not have a default value in the class specification. If all values including <empty> is a valid value then setting a default value to be handled by IMM is incorrect. Instead, the software that "owns/is dependent on" this attribute should check if the value is valid (if for example the attribute has a max value so values larger than that max are invalid) and if the value is invalid it could be replaced by a default value.</empty></empty></empty>

[elunlen]

This fix will be implemented. SInce immdump will be changed to set <value xsi:nil=""></value> instead of <value></value> and this changed is somewhat NBC a new option will be added to immdump. When this option is set this new more correct behaviour will be used.

[Vu Minh Nguyen]

Thanks Lennart. I added a new option '-n' (--null) to immdump command tool and sent out for review.
https://sourceforge.net/p/opensaf/mailman/message/36517294/

[Vu Minh Nguyen]

commit 6c5c389b4d92bf48e42615b067f8a9028880a2a8 (HEAD -> develop, origin/develop, ticket-2985)
Author: Vu Minh Nguyen vu.m.nguyen@dektech.com.au
Date: Tue Jan 15 10:29:26 2019 +0700

imm: allow empty-value attribute with default-tag persisted [#2985]

During runtime, when replacing value of an attribute which has default-value
tag with NULL, this NULL value is not persistent after cluster is rebooted -
NULL value will be automatically replaced with its default value by IMM.

This behavior causes several unexpected results. Below is an use case:
User defines an attribute with name `maxAge`; the value shows how many days
user passwords will get expired; default value is 30 days. If replacing with
a NULL/empty, it means the passwords will never get expired.

User may change the existing value with NULL - expect the passwords never get
expired, but later on, after cluster is rebooted, that value is silently
replaced with the default value without notice of user.

This patch makes some changes in immdump/immloader/imm om library/immnd
to make NULL value in such case persisted even after cluster is rebooted.