On 06/25/2013 01:43 PM, praveen malviya wrote: > Thanks for the comments and discussion. I will respond for other > comments soon, as of now starting with this mail. > Please see the response below. > > One more point can be brought into discussion here. The case is when > admin restart operation is invoked on the component and > saAmfDisableRestart is true for it. > Now if saAmfSUFailover is also true for the SU of this component, then: > case1) AMF should honor saAmfSUFailover and perform the failover of > whole SU. > case2) Amf should reject the comp restart admin operation because whole > su should fail-over as a single entity. In my opinion AMF should reject > the operation.
Agree simplest and safest for now > > Any comments? > > On 25-Jun-13 3:20 PM, Mathivanan Naickan Palanivelu wrote: >>> -----Original Message----- >>> From: Hans Feldt [mailto:[email protected]] >>> Sent: Tuesday, June 25, 2013 3:01 PM >>> To: Mathivanan Naickan Palanivelu >>> Cc: Praveen Malviya; Nagendra Kumar; [email protected] >>> Subject: Re: [PATCH 6 of 6] amf: handle sufailover in SU FSM and Comp >>> FSM >>> at amfnd [#98] >>> >>> >>> On 06/24/2013 04:39 PM, Mathivanan Naickan Palanivelu wrote: >>>> Hi Praveen, >>>> >>>> Thanks for the clarification. >>>> Please find some other comments below: >>>> >>>> - I'm sure you would have had a reason to do it this way, but I thought >>> alternatively performing the repair at the AMFND itself(instead of >>> notifying >>> to AMFD) is one viable option! >>> >>> Guess not it interferes with a potential auto adjust feature right? >> I meant that we could avoid the 'extra step' of informing AMFD. >> May be, we could reduce the latency (in repairing) if avoid going >> through AMFD. >> Well, AMFND could be made aware of autoadjust attributes, isn't it! > saAmfSGAutoRepair attribute is maintained at amfd only. Current > implementation support repair of SU through admin operation. > When repair admin operation is invoked, amfd informs amfnd to perform > repair. So functionally it is amfnd that performs the repair. > In these patches, this same mechanism is used to perform repair. After > performing failover of assignments of faulted SU (this only amfd can > do), amfd checks saAmfSGAutoRepair and if it is true informs amfnd to > perform repair. Rest of the flow is same as admin repair operation. > If saAmfSGAutoRepair is maintained at amfnd, then in ccb modify > operations on this attribute amfd will have to update to each amfnd > hosting SUs of this SG. These again will be "extra steps". Yes I think your chosen design is elegant and lean! Reuse the same logic for auto and manual repair... > >>>> Some other comments I had in mind are: >>>> - is si-si dependencies automatically taken care by these changes? >>>> - are we honouring 'order' of termination of components based on the >>> 'instantiationlevel'(in reverse)? >>> >>> 3.11.1.3.2 SU failover: >>> >>> "If the service unit is configured to fail over as a single entity >>> (saAmfSUFailover set to SA_TRUE), all other components of the service >>> unit >>> are abruptly terminated" >>> >>> Does not say anything about ordering. Should we add some defined >>> ordering >>> semantics on top of that you mean? >>> >>> >> I meant the below. Also, SU failover 'effectively' involves restart of >> the failed SU! > -In case of SU failover no quiesced assignment will be given. So SI dep > will be honored only while giving active assignment to the standby or > spare su. > - As a part of su failover components will be abruptly terminated > without honoring instantiation-level. I think instantiation-level is to > be considered during graceful termination > of component like Lock-in operation. We could of course honour inst level for abrupt termination also if we want to. It is our choice. Could start unordered though as in the patch series. > In case of SU restart one ticket exists #315 >>> FYI just realized ordering and semantics of "SU restart" is wrong. Will >>> write a defect. > As pointed out ticket already exists #315. My memory is rather short, seems like I wrote it myself... But it is just not the level, it is the way SU restart is done. See 3.11.1.2: Restarting a service unit is achieved by the following actions: • First, all components in the service unit are terminated in the order dictated by their instantiation-levels. • In a second step, all components in the service unit are instantiated in the order dictated by their instantiation-levels. That is obviously not the case since SU restart is just an iteration of comp restart. Should be comp termination and then comp instantiation Thanks, Hans ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
