Menu
▾
▴
#597 AMF: support to add component in MW SU
Today it is possible to add a component in an unlocked SU but it will not be instantiated until the SU has gone through the admin operation cycle lock->lockin->unlockin->unlock.
This enhancement proposes that when a component is added to an unlocked SU it should be automatically instantiated (if sa-aware).
When the corresponding CSI is added to component should either be 1) assigned (SA-aware) or 2) instantiated (non-sa-aware)
The reverse should also work. When a CSI is removed, the corresponding component should either be 1) unassigned (sa-aware) or 2) terminated (non-sa-aware). When the component is removed the sa-aware component shold be terminated.
Hmm. In the absence of HARS support, I think this 'automatic instantiation' behavior could be controlled based on a configuration attribute, say "autostart" or "autoinstantiate"
This could give flexibility (to do a readiness check!?).
One way of looking at this proposal is to treat it as equivalent to introducing a new admin operation called "REPROVISION" that internally orchestrates a set of CCB commands to be executed.
Having said that, I'm not sure(need to figure out) how the statemachines will be impacted if this proposal is to be supported!
Cheers,
Mathi.
From: Hans Feldt [mailto:hansfeldt@users.sf.net]
Sent: Thursday, October 17, 2013 1:27 PM
To: Ticket 597
Subject: [tickets] [opensaf:tickets] #597 AMF: support to add component in unlocked SU
HYPERLINK "http://sourceforge.net/p/opensaf/tickets/597/"[tickets:#597] AMF: support to add component in unlocked SU
Status: unassigned
Created: Thu Oct 17, 2013 07:56 AM UTC by Hans Feldt
Last Updated: Thu Oct 17, 2013 07:56 AM UTC
Owner: nobody
Today it is possible to add a component in an unlocked SU but it will not be instantiated until the SU has gone through the admin operation cycle lock->lockin->unlockin->unlock.
This enhancement proposes that when a component is added to an unlocked SU it should be automatically instantiated (if sa-aware).
When the corresponding CSI is added to component should either be 1) assigned (SA-aware) or 2) instantiated (non-sa-aware)
The reverse should also work. When a CSI is removed, the corresponding component should either be 1) unassigned (sa-aware) or 2) terminated (non-sa-aware). When the component is removed the sa-aware component shold be terminated.
Sent from sourceforge.net because HYPERLINK "mailto:opensaf-tickets@lists.sourceforge.net"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.
Related
Tickets:
#597Tickets: tickets
changeset: 4861:2567501c6fb9
tag: tip
user: Nagendra Kumarnagendra.k@oracle.com
date: Wed Jan 29 12:33:12 2014 +0530
summary: amf: support for automatic comp instantiation and deletion [#597]
[staging:256750]
Related
Tickets:
#597changeset: 4862:cb10228b97da
branch: opensaf-4.4.x
tag: tip
parent: 4859:8cdb6d472f7b
user: Nagendra Kumarnagendra.k@oracle.com
date: Wed Jan 29 12:37:49 2014 +0530
summary: amf: support for automatic comp instantiation and deletion [#597]
[staging:cb1022]
Related
Tickets:
#597Documentation changes :
changeset: 84:0c44f52b381a
tag: tip
user: Nagendra Kumarnagendra.k@oracle.com
date: Wed Jan 29 16:23:20 2014 +0530
summary: amf: support for automatic comp instantiation and deletion [#597]
[staging:0c44f5]
Related
Tickets:
#597Last edit: Nagendra Kumar 2014-01-29
The change is not backwards compatible with existing campaigns that adds component to locked SU in a rolling fashion.
Consider a campaign that adds a component of a new type, delivered by a new SW bundle. When the component is added in procInitAction, this triggers a REG_SU message sent from the director to the node director. At this point the corresponding SaAmfNodeSwBundle does not exist and the operation fails.
To be backwards compatible with such campaigns it is proposed that the sending of the REG_SU message when the component is added is guarded with the check that the related SaAmfNodeSwBundle exist.
This problem is still there if immnd doesn't get synced up. I think this is a separate issue.
Even with this suggested change it's not completly backwards compatible. If someone has installed the correct SW, added components and then explicitly locked/unlocked the SU to activate the changes. Not suddenly the components are activated automatically when created. Another issue is if someone thinks they have installed the correct SW (but it was wrong) and then adds a component and the component is not started because it was the wrong SW that was installed. In this case there will be no indication about this (alarm etc.).
Since, adding a component in unlock/locked su was not documented, this is not an issue.
We have documented to add component in locked-in SU state and hence feature doesn't break any backward compatibility.
When using SMF campaigns it is not possible to modify IMM in the upgrade step. That can only be done in the procInitAction (or the procWrapupAction). This means that user's already today have added components to an unlocked SU because that is the only way to do it! So yes it was supported before and needs to be supported after 4.4.
I am afraid Mathi was spot on with his initial comment about this. Maybe a new configuration attribute "autostart" is what is needed to fix this properly? Admin operations on comp and CSI is not something we would like to have at this point.
The documentation just say what you can do, it does not state the reverse - what you cannot do. Besides as I said this is the only possible way...
So I guess you should reopen this ticket and we should work together to find a good solution.
When you are upgrading from older releases(4.2, 4.3), then adding component in procInitAction is fine as it is not going to instantiate as they are older releases.
So, this is fine. I don't see any issue here.
When upgrade has been done to 4.4 and now you want to run the same campaign, the behaviour will be different as we have documented it. The campaign is required to be modified as per document.
I don't (yet) understand the backward compatibility issue. However, if existing deployments need the benefit of flexibility in the way the campaign can be written during the migration paths from older to newer releases, then we could just consider restrict the enhancement introduced in 597 as applicable only to the middleware SU.
Hi Nagendra, we could just make this applicable only to the OpenSAF SU and raise another enhancement ticket to support this in a generic way.
Thanks,
Mathi.
I need to check and tweak the code and it may take some time.
Is other stakeholders agreeing to Math's suggestion and it solves their problem ?
Support of middleware component only.
The concern got fixed as part of https://sourceforge.net/p/opensaf/tickets/780/