Just as a note, I tried Option (b) and it seems to work. (Also, SMF doesn’t
performs a classimplementerset() on this, but the implementerName is still
available
for reading because it’s a PRTO)
The question would then be -this change should be adopted in older releases
too!?
Thanks,
Mathi.
From: Mathi Naickan [mailto:[email protected]]
Sent: Tuesday, December 15, 2015 3:31 PM
To: [email protected]
Subject: [tickets] [opensaf:tickets] #1605 smfd: campaign not correctly
terminated after failed SI-SWAP
I see two possible options for this
(a) Change the DN name format and concatenate/suffix the node_name to the
SmfRestartIndicator DN name.
(b) Change the SMF's ImplementerName string by concatenating/suffixing the
node_name. Before becoming implementer, if this object exists, call
AccessorGet() for the SmfRestartIndicator PRTO object and read the
'SaImmAttrImplementerName' attribute.
Thus it wil help determine if the object was originally created by smfd running
on the same/self node(old controller) or the peer controller node.
_____
HYPERLINK "http://sourceforge.net/p/opensaf/tickets/1605/"[tickets:#1605] smfd:
campaign not correctly terminated after failed SI-SWAP
Status: unassigned
Milestone: 5.0.FC
Created: Thu Nov 19, 2015 12:26 PM UTC by Ingvar Bergström
Last Updated: Thu Nov 19, 2015 12:26 PM UTC
Owner: nobody
Scenario:
1)smfd order a SI-SWAP to continue the campaign execution on the other
controller.
2)before swap is executed, an imm object "SmfRestartIndicator" is created to
signal to the smf on the new controller the campaign restart was initiated by
smf (spontaneus restarts will always fail the campaign in executing state).
3)When the new controller comes up smf will check the existence of the object.
If present OK if not fail. If OK the "SmfRestartIndicator" object is removed.
In this case the new controller fail to start very early, before smf was
started. Smf never have a chance to remove the object.
5)AMF order a switchback to the first controller.
6)Smf start up on the "old" controller once again. Since the
"SmfRestartIndicator" is still there, smf think the restart was ordered by smf
and try to continue campaign execution which fail (the wrong way e.g. core dump)
Todo: find a mechanism which make smf to detect the "SmfRestartIndicator" is
the old one and treat this case as it does not exist. Make sure the new
solution is backward compatible.
The campaign continues at:
file: SmfUpgradeCampaign.cc, method:SmfUpgradeCampaign::continueExec()
The restart indicator is handeled in:
file: SmfUpgradeCampaign.cc,
method:SmfUpgradeCampaign::checkSmfRestartIndicator()
_____
Sent from sourceforge.net because HYPERLINK
"mailto:[email protected]"[email protected]
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.
---
** [tickets:#1605] smfd: campaign not correctly terminated after failed SI-SWAP
**
**Status:** unassigned
**Milestone:** 5.0.FC
**Created:** Thu Nov 19, 2015 12:26 PM UTC by Ingvar Bergström
**Last Updated:** Tue Dec 15, 2015 10:01 AM UTC
**Owner:** nobody
Scenario:
1)smfd order a SI-SWAP to continue the campaign execution on the other
controller.
2)before swap is executed, an imm object "SmfRestartIndicator" is created to
signal to the smf on the new controller the campaign restart was initiated by
smf (spontaneus restarts will always fail the campaign in executing state).
3)When the new controller comes up smf will check the existence of the object.
If present OK if not fail. If OK the "SmfRestartIndicator" object is removed.
In this case the new controller fail to start very early, before smf was
started. Smf never have a chance to remove the object.
5)AMF order a switchback to the first controller.
6)Smf start up on the "old" controller once again. Since the
"SmfRestartIndicator" is still there, smf think the restart was ordered by smf
and try to continue campaign execution which fail (the wrong way e.g. core dump)
Todo: find a mechanism which make smf to detect the "SmfRestartIndicator" is
the old one and treat this case as it does not exist. Make sure the new
solution is backward compatible.
The campaign continues at:
file: SmfUpgradeCampaign.cc, method:SmfUpgradeCampaign::continueExec()
The restart indicator is handeled in:
file: SmfUpgradeCampaign.cc,
method:SmfUpgradeCampaign::checkSmfRestartIndicator()
---
Sent from sourceforge.net because [email protected] is
subscribed to http://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
http://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
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
