#1190 AMF: saAmfSIPrefActiveAssignments has wrong default, stopping scaling nway active SGs

[Hans Feldt]

Problem: In naway-active, SUs are not instantiated unless saAmfSIPrefActiveAssignments is configured.

saAmfSIPrefActiveAssignments is a configuration attribute only valid for the nway-active redundancy model.

According to the spec 3.6.5.3 it should have a default value of "the preferred number of assigned service units."

and
"saAmfSGNumPrefAssignedSUs" should have a default value of "the preferred number of in-service service units"

and

"saAmfSGNumPrefInserviceSUs" should have a default value of "the number of the service units configured for the service group."

The value of saAmfSIPrefActiveAssignments is currently set to one when not configured, instead it should be set to saAmfSGNumPrefAssignedSUs.

In order to avoid any backward compatibility issue, choice is left to the user for default value of the attribute.
Default value of saAmfSIPrefActiveAssignments will be either saAmfSGNumPrefAssignedSUs or 1
based on user choice.
Following are conditions in which different default values will be honoured:
-if a user configures saAmfSIPrefActiveAssignments=1 then SI will assigned to only one
SU.This is to ensure backward compatibility.
-if a user does not configure attribute saAmfSIPrefActiveAssignments in application or
deletes this attributes via CCB operation then AMFD will still honor default value as 1. This
is again to ensure backward compatibility.
-if a user sets saAmfSIPrefActiveAssignments=0 via CCB or in application conf then AMFD will
use section 3.6.5 definition for default value i.e saAmfSGNumPrefAssignedSUs.

[Hans Feldt]

the schema seems to be wrong since has a default value of 1, should have no default

[Praveen]

Patch is floated to fix old amfd assert:
http://sourceforge.net/p/opensaf/mailman/message/33105302/

[Praveen]

Default value of this attribute is assigned different values at two places in AMF spec:
1)section 3.6.5.
2)section 8.11(Schema Issue).
So moving this ticket for 5.0.

[Praveen]

Section 3.6.5 covers details of N-Way Active red model characteristics. So for this ticket default value mentioned in section "3.6.5.3 Configuration" will be honoured.

[Praveen]

Note related to upgrade (AMF PR doc will be updated for this) :
If any N-Way Active application is running with default value of
saAmfSIPrefActiveAssignments=1 for a SI then SI is assigned to only
one SU. After upgrade to this release, default value is now changed to
saAmfSGNumPrefAssignedSUs. So application will see more assigned SUs for
this SI. For such an application, old behaviour can still be achieved by
modifying the default value of saAmfSIPrefActiveAssignments to 1 using CCB
operation only once. This should be done as soon as the first system
controller is upgraded to this release in standby role. In this way Standby
controller will remember the user definition and it will honor it when it
takes the active role.
This upgrade provision is maintained for two releases only and it can be removed when 5.2 is no longer
maintained.

Will raise two defects related to:
1) default value of saAmfSGNumPrefAssignedSUs.,
2) When saAmfSIPrefActiveAssignments is reduced, AMFD is deleting assignments from SUs with high ranke when no SI ranked SU is configured.

[Praveen]

changeset: 8615:121dbcd7391b
tag: tip
user: Praveen Malviya praveen.malviya@oracle.com
date: Fri Feb 24 11:39:13 2017 +0530
files: src/amf/amfd/sg.cc src/amf/amfd/sg.h src/amf/amfd/si.cc
description:
amfd: fix default value of saAmfSIPrefActiveAssignments [1190]

Will be updating AMF PR doc

[Praveen]

Hi All,
I think patch for this ticket can be pushed in other branches also because we are retaining both the definitions. If a user sets it to 1 then default value will remain 1. If a user sets it to 0 then default value will be PrefAssignedSUs. A user has always the facility to lock the SI for no assignments.

Thanks,
Praveen

[Praveen]

Pushed patch does not contain one change in si_ccb_apply_modify_hdlr(). The change was initially published with V1 of the patch and I did not update and include in V2 version when definition was modified. Now I have published it with the patch of ticket #2268.