Hi Vu, That paragraph is talking about implementer names, and it's still valid. Ticket #2579 is about appliers.
Thanks, Zoran -----Original Message----- From: Vu Minh Nguyen [mailto:vu.m.ngu...@dektech.com.au] Sent: den 3 november 2017 11:31 To: Zoran Milinkovic <zoran.milinko...@ericsson.com> Cc: opensaf-devel@lists.sourceforge.net Subject: RE: [PATCH 1/1] imm: update README with IMM changes in OpenSAF 5.17.11 [#2665] Hi Zoran, Ack with one below question. In README, it states: "A word of caution about implementer names. Implementer names are to be re-used. They are never garbage collected by the imm service. An implementer-name may have no current live implementer handle attached, but once created, it lives "forever" ready for the next attach, (saImmOiImplementerSet). Implementer-names could be compared to Unix port numbers. " Does it need to revise a bit due to introducing of ticket #2579? Regards, Vu -----Original Message----- From: Zoran Milinkovic [mailto:zoran.milinko...@ericsson.com] Sent: Thursday, November 2, 2017 9:30 PM To: vu.m.ngu...@dektech.com.au Cc: opensaf-devel@lists.sourceforge.net; Zoran Milinkovic <zoran.milinko...@ericsson.com> Subject: [PATCH 1/1] imm: update README with IMM changes in OpenSAF 5.17.11 [#2665] Add two sections. The section that describes the new flag for enabling features in 5.17.11, and the section that describes the removal of disconnected appliers --- src/imm/README | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) diff --git a/src/imm/README b/src/imm/README index 184ae63..0b108d6 100644 --- a/src/imm/README +++ b/src/imm/README @@ -2955,6 +2955,72 @@ In case of CLM node lock, and HEADLESS is triggered after CLM node lock, then CL node is nullified. The node is considered as HEADLESS and all other agent functions supported in HEADLESS are supported. +Notes on upgrading to OpenSAF 5.17.11 +===================================== +OpenSAF 5.17.11 adds new attribute flag allowing the removal of +disconnected appliers (#2579). During a rolling upgrade from an earlier +OpenSAF release to the 5.17.11 release there will be nodes executing +the older release concurrently with nodes executing OpenSAF 5.17.11. +Nodes executing the earlier release will not recognize the new +attribute flag originating from nodes executing 5.17.11. + +Because of this upgrade issue, the new attribute flag added in OpenSAF +5.17.11 is not allowed unless a flag is toggled on in the +opensafImmNostdFlags runtime attribute in the object: + + opensafImm=opensafImm,safApp=safImmService. + +The following is the shell command: + + immadm -o 1 -p opensafImmNostdFlags:SA_UINT32_T:1024 \ + opensafImm=opensafImm,safApp=safImmService + +This will set bit 10 of the 'opensafImmNostdFlags' runtime attribute +inside the immsv. +Operation-id '1' invoked on the object: + + 'opensafImm=opensafImm,safApp=safImmService' + +has the meaning of 'flags-ON'. Operation-id '2' has the meaning of 'flags-OFF'. +This flag (and possibly other relevant flags) needs to be toggled ON +when the upgrade to OpenSAF 5.17.11 has been successfully completed. +This would be in some final step of the upgrade. Any cluster +start/restart of an OpenSAF 5.17.11 system will always automatically +toggle on relevant flags. + +In summary: + +Bit 1 controls schema (imm class) changes allowed or not (normally off/0). +Bit 2 controls OpenSAF4.1 protocols allowed or not (normally on/1). +Bit 3 controls OpenSAF4.3 protocols allowed or not (normally on/1). +Bit 4 controls 2PBE oneSafe2PBE, see 2PBE feature in OpenSAF4.4 above (normally off/0). +Bit 5 controls OpenSAF4.5 protocols allowed or not (normally on/1). +Bit 6 controls OpenSAF4.6 protocols allowed or not (normally on/1). +Bit 7 controls OpenSAF4.7 protocols allowed or not (normally on/1). +Bit 8 controls OpenSAF5.0 protocols allowed or not (normally on/1). +Bit 9 controls OpenSAF5.1 protocols allowed or not (normally on/1). +Bit 10 controls OpenSAF5.17.11 protocols allowed or not (normally on/1). + +Removal of disconnected applier (5.17.11) +================================================= +Once an implementer is created, it resides in the system to the cluster +restart. There is no way to remove implementers from the system. +Applier is a special case of implementers and the same feature applies +to appliers. + +Applier names usually contain the node name where they are created to +avoid the collision with the same appliers on other nodes. In systems +where new nodes come with new names every time, this can be a problem +and the limit of +3000 implementer and appliers can be reached. + +The new feature is introduced in 5.17.11 which will handle the time for +keeping disconnected appliers in the system. When the time expires, +disconnected appliers will be removed from the system. + +The applier timeout is configurable, and it is set in the new attribute +minApplierTimeout in IMM object. If minApplierTimeout attribute is set +to 0, the removal of disconnected appliers is disabled. The unit in +counting the timeout is in seconds. + +To be possible to use this new feature, bit 10 must be set in +opensafImmNostdFlags attribute in IMM object. + ---------------------------------------- DEPENDENCIES ============ -- 1.9.1 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
