Can we review the changed doc instead? /Hans On 01/29/2014 12:00 PM, Nagendra Kumar wrote: > Here is the doc change, I am going to commit: > > 7.1.1 Adding a component in an SG
Components are added to SUs > 7.1.1.1 Approach 1: Adding a component by deactivating/activating the SU. > The following is the sequence of operations to be performed in this approach. > Lock SU2 > Lock-inst SU2 > Add a Component Comp23 in SU2. > Unlock-inst SU2 > Unlock SU2. > At this point of time, SU2 has three components (Comp21, Comp22, Comp23), > Comp21 and Comp22 has Standby assignments. > Lock SU1 > Lock-inst SU1 > Add a Component Comp13 in SU1. > Unlock-inst SU1 > Unlock SU1. > At this point of time, SU1 has three components (Comp11, Comp12, Comp13), > Comp11 and Comp12 has Standby assignments. And SU2 has three > components(Comp21, Comp22, Comp23), Comp21 and Comp22 has Active assignments. > Add new SaAmfCSBaseType, SaAmfCSType. > SaAmfCtCsType (existing SaAmfCompType with new SaAmfCSType) > SaAmfSvcTypeCSTypes(Existing SaAmfSvcType with new SaAmfCSType) > two new CompCSTypes (New SaAmfCSType with Components Comp13 and Comp23). > Add CSI3 having new SaAmfCSType. > At this point of time, SU1 has three components (Comp11, Comp12, Comp13), > Comp11, Comp12 and Comp13 has Standby assignments. And SU2 has three > components (Comp21, Comp22, Comp23), Comp21, Comp22 and Comp23 has Active > assignments. > Perform SI SWAP operation on application SI if SU1 and SU2 HA states desired > to be the same before adding a component. > 7.1.1.2 Approach 2: Adding a component when the SU is in instantiated state, > without deactivation of the SU. > In this approach, the component can be added dynamically into SUs without > lock/lock-in of the SU. When a component is added to the SU, the component is > transitioned into the instantiated state(if no error occurs). This can be > termed as automatic instantiation of a component. > When a component is dynamically added in instantiated SU, then the SU > presence state is transitioned to uninstantiated, subsequently to > instantiating and then transition back to instantiated state after the > component is successfully instantiated. > Addition of more than one component in a single CCB is not supported. Also, > the SU should be in instantiated state with at least a single component for > this approach of automatic component instantiation to work. This is required > because when one the component is instantiating, the SU presence state moves > into instantiating and the addition of another component will be forced to be > put in instantiating state which violates the basic assumption of component > being added into instantiated SU. > > The following is the sequence of operations to be performed in this approach: > Add a Component Comp13 and Comp23 in SU1 and SU2. Both the component will be > instantiated. > At this point of time, SU1 has three components (Comp11, Comp12, Comp13), > Comp11 and Comp12 has Active assignments. And SU2 has three > components(Comp21, Comp22, Comp23), Comp21 and Comp22 has Standby > assignments. > Add new SaAmfCSBaseType, SaAmfCSType. > SaAmfCtCsType (existing SaAmfCompType with new SaAmfCSType) > SaAmfSvcTypeCSTypes(Existing SaAmfSvcType with new SaAmfCSType) > two new CompCSTypes (New SaAmfCSType with Components Comp13 and Comp23). > Add CSI3 having new SaAmfCSType. > At this point of time, SU1 has three components (Comp11, Comp12, Comp13), > Comp11, Comp12 and Comp13 has Active assignments. And SU2 has three > components (Comp21, Comp22, Comp23), Comp21, Comp22 and Comp23 has Standby > assignments. > > > 7.1.2 Removing a component from SG Components are removed from SUs > 7.1.2.1 Approach 1: Removing a component by deactivating/activating the SU. > The following is the sequence of operations to be performed in this approach: > Delete CSI2 from SI. > At this point of time, SU1 has two components (Comp11 and Comp12), Comp11 has > Active assignment. And SU2 has two components(Comp21 and Comp22), Comp21 has > Standby assignment. > Lock SU2 > Lock-inst SU2 > Delete Component Comp22 from SU2. > Unlock-inst SU2 > Unlock SU2. > At this point of time, SU2 has one component (Comp21) with Standby assignment. > Lock SU1 > Lock-inst SU1 > Delete Component Comp12 from SU1. > Unlock-inst SU1 > Unlock SU1. > Delete the old entity types that are no longer in use. > At this point of time, SU1 has one component (Comp12) with Standby > assignment. SU2 has one component (Comp21) with Active assignment. > Perform SI SWAP operation on application SI if SU1 and SU2 HA states desired > to be the same before adding a component. > 7.1.2.2 Approach 2: Removing a component when the SU is in instantiated > state, without deactivation of the SU. > In this approach, a component can be deleted dynamically from SUs without > lock/lock-in of the SU. The CSI assignment from that component should be > removed before the component is deleted. When component is deleted from the > SU, the component is terminated and it transitions into uninstantiated > state(if no error occurs). This can be termed as automatic deletion of a > component. > When component is deleted from the SU, the SU presence state doesn't change > and component presence state transition from instantiated => terminating => > uninstantiated will not be available in imm because the component is already > deleted from data base. > Deletion of more than one component in a single CCB is not supported. > Automatic component deletion is not possible when the SU contains only a > single component. Automatic component addition and deletion in the same CCB > is also not supported. > The following is the sequence of operations to be performed in this approach: > Delete CSI2 from SI. > Delete Component Comp12 Comp22 from SU1 and SU2 respectively. > At this point of time, SU1 has one component (Comp12) with Active assignment. > SU2 has one component (Comp21) with Standby assignment. > > >> -----Original Message----- >> From: Nagendra Kumar >> Sent: 24 January 2014 11:46 >> To: [email protected]; [email protected]; Praveen Malviya; >> Hrishikesh Chenna >> Cc: [email protected] >> Subject: [devel] [PATCH 0 of 1] Review Request for V 3.0 amf: support for >> automatic comp instantiation and deletion [#597] >> >> Summary: V 3.0 amf: support for automatic comp instantiation and deletion >> [#597] Review request for Trac Ticket(s): #597 Peer Reviewer(s): Hans F, Hans >> N, Praveen Pull request to: <<LIST THE PERSON WITH PUSH ACCESS HERE>> >> Affected branch(es): Default Development branch: Default >> >> -------------------------------- >> Impacted area Impact y/n >> -------------------------------- >> Docs n >> Build system n >> RPM/packaging n >> Configuration files n >> Startup scripts n >> SAF services y >> OpenSAF services n >> Core libraries n >> Samples n >> Tests n >> Other n >> >> >> Comments (indicate scope for each "y" above): >> --------------------------------------------- >> <<EXPLAIN/COMMENT THE PATCH SERIES HERE>> This patch includes review >> comments incorporated and modification for ticket #743 as well. >> >> changeset b76281f5a353590dd45ad7736291e08b32ca049e >> Author: Nagendra Kumar<[email protected]> >> Date: Fri, 24 Jan 2014 11:41:53 +0530 >> >> amf: support for automatic comp instantiation and deletion [#597] >> When any >> component is added in the instantiated SU, Amf will try to instantiate >> the >> component. When any component is deleted from instantiated SU, Amf >> will try >> to terminate the component. >> >> >> Complete diffstat: >> ------------------ >> osaf/services/saf/amf/amfd/comp.cc | 37 >> +++++++++++++++++++++++++++++++------ >> osaf/services/saf/amf/amfd/ndproc.cc | 10 +++++++--- >> osaf/services/saf/amf/amfnd/clc.cc | 10 ++++++++++ >> osaf/services/saf/amf/amfnd/compdb.cc | 45 >> +++++++++++++++++++++++++++++++++++++++------ >> osaf/services/saf/amf/amfnd/include/avnd_comp.h | 2 ++ >> osaf/services/saf/amf/amfnd/su.cc | 27 >> ++++++++++++++++++++++++--- >> osaf/services/saf/amf/amfnd/susm.cc | 4 +++- >> 7 files changed, 116 insertions(+), 19 deletions(-) >> >> >> Testing Commands: >> ----------------- >> Please check previous patch floated. >> >> >> Testing, Expected Results: >> -------------------------- >> Please check previous patch floated. >> >> >> Conditions of Submission: >> ------------------------- >> Ack from peer reviewers >> >> Arch Built Started Linux distro >> ------------------------------------------- >> mips n n >> mips64 n n >> x86 n n >> x86_64 y y >> powerpc n n >> powerpc64 n n >> >> >> Reviewer Checklist: >> ------------------- >> [Submitters: make sure that your review doesn't trigger any checkmarks!] >> >> >> Your checkin has not passed review because (see checked entries): >> >> ___ Your RR template is generally incomplete; it has too many blank entries >> that need proper data filled in. >> >> ___ You have failed to nominate the proper persons for review and push. >> >> ___ Your patches do not have proper short+long header >> >> ___ You have grammar/spelling in your header that is unacceptable. >> >> ___ You have exceeded a sensible line length in your headers/comments/text. >> >> ___ You have failed to put in a proper Trac Ticket # into your commits. >> >> ___ You have incorrectly put/left internal data in your comments/files >> (i.e. internal bug tracking tool IDs, product names etc) >> >> ___ You have not given any evidence of testing beyond basic build tests. >> Demonstrate some level of runtime or other sanity testing. >> >> ___ You have ^M present in some of your files. These have to be removed. >> >> ___ You have needlessly changed whitespace or added whitespace crimes >> like trailing spaces, or spaces before tabs. >> >> ___ You have mixed real technical changes with whitespace and other >> cosmetic code cleanup changes. These have to be separate commits. >> >> ___ You need to refactor your submission into logical chunks; there is >> too much content into a single commit. >> >> ___ You have extraneous garbage in your review (merge commits etc) >> >> ___ You have giant attachments which should never have been sent; >> Instead you should place your content in a public tree to be pulled. >> >> ___ You have too many commits attached to an e-mail; resend as threaded >> commits, or place in a public tree for a pull. >> >> ___ You have resent this content multiple times without a clear indication >> of what has changed between each re-send. >> >> ___ You have failed to adequately and individually address all of the >> comments and change requests that were proposed in the initial review. >> >> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc) >> >> ___ Your computer have a badly configured date and time; confusing the >> the threaded patch review. >> >> ___ Your changes affect IPC mechanism, and you don't present any results >> for in-service upgradability test. >> >> ___ Your changes affect user manual and documentation, your patch series >> do not contain the patch that updates the Doxygen manual. >> >> >> ------------------------------------------------------------------------------ >> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >> Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical >> Workloads, Development Environments & Everything In Between. >> Get a Quote or Start a Free Trial Today. >> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clk >> trk >> _______________________________________________ >> Opensaf-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/opensaf-devel > > ------------------------------------------------------------------------------ WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
