Good catch! The proposal is fine with me. /Hans > -----Original Message----- > From: Nagendra Kumar [mailto:[email protected]] > Sent: den 5 september 2014 08:49 > To: Hans Feldt; Hans Nordebäck; Praveen Malviya > Cc: [email protected] > Subject: RE: [devel] [PATCH 1 of 1] amfd: respond to shutdown op if lock has > been issued before it completes [#1021] > > > But bigger question is : If Specs defines this path/flow as valid and > > provides sanctity and doesn't consider it as an error. Why Amf should > > return an error? > [Hans] Returning prematurely from SHUTDOWN before LOCKED state has been > reached is an error to me. AMF can internally wait > until the LOCK operation is done and then respond to both SHUTDOWN and LOCK. > > Well, I got answer from CLM B.4.2 Specs section 5.2.4 : > > SA_AIS_ERR_INTERRUPT - The SA_CLM_ADMIN_SHUTDOWN administrative operation > was superseded by a SA_CLM_ADMIN_LOCK or by a SA_CLM_ADMIN_UNLOCK > operation. > > So, do you think we can implement it, it is not mentioned anywhere in Amf ? > > Thanks > -Nagu > > > -----Original Message----- > > From: Hans Feldt [mailto:[email protected]] > > Sent: 04 September 2014 18:24 > > To: Nagendra Kumar; Hans Nordebäck; Praveen Malviya > > Cc: [email protected] > > Subject: RE: [devel] [PATCH 1 of 1] amfd: respond to shutdown op if lock has > > been issued before it completes [#1021] > > > > > > > > > -----Original Message----- > > > From: Nagendra Kumar [mailto:[email protected]] > > > Sent: den 4 september 2014 10:24 > > > To: Hans Feldt; Hans Nordebäck; Praveen Malviya > > > Cc: [email protected] > > > Subject: RE: [devel] [PATCH 1 of 1] amfd: respond to shutdown op if > > > lock has been issued before it completes [#1021] > > > > > > > So far as I have seen SMF never works on SI level. > > > We did the same thing with SU as part of ticket #582. > > > > > > > I vote for BAD_OPERATION. > > > As per Specs, this error is reported when target entity is locked > > > already. Here it > > is not locked. > > > > > > But bigger question is : If Specs defines this path/flow as valid and > > > provides sanctity and doesn't consider it as an error. Why Amf should > > > return > > an error? > > [Hans] Returning prematurely from SHUTDOWN before LOCKED state has been > > reached is an error to me. AMF can internally wait until the LOCK operation > > is > > done and then respond to both SHUTDOWN and LOCK. > > > > > > > > Thanks > > > -Nagu > > > > > > > -----Original Message----- > > > > From: Hans Feldt [mailto:[email protected]] > > > > Sent: 04 September 2014 12:53 > > > > To: Nagendra Kumar; Hans Nordebäck; Praveen Malviya > > > > Cc: [email protected] > > > > Subject: RE: [devel] [PATCH 1 of 1] amfd: respond to shutdown op if > > > > lock has been issued before it completes [#1021] > > > > > > > > So far as I have seen SMF never works on SI level. The problem here > > > > is also more manually triggered, some operator gets tired of waiting > > > > for SHUTDOWN and goes for LOCK. SMF would not do that. > > > > I vote for BAD_OPERATION. > > > > /Hans > > > > > > > > > -----Original Message----- > > > > > From: Nagendra Kumar [mailto:[email protected]] > > > > > Sent: den 4 september 2014 08:44 > > > > > To: Hans Feldt; Hans Nordebäck; Praveen Malviya > > > > > Cc: [email protected] > > > > > Subject: RE: [devel] [PATCH 1 of 1] amfd: respond to shutdown op > > > > > if lock has been issued before it completes [#1021] > > > > > > > > > > Hi Hans, > > > > > I think it is better to return OK because of following reasons: > > > > > 1. It avoids Smf upgrade failures. If Amf returns TIME_OUT, Smf > > > > > tries again(not sure about the implementation, but as per Spec, it > > > > > should try again) > > > > and Smf may get TRY_AGAIN or BAD_OP error return code. If Smf get > > > > BAD_OP, it will abort upgrade. > > > > > 2. If Smf accepts OK in this case and then run another command > > > > > like unlock, then worst case, it will get TRY_AGAIN and this is one > > > > > of above > > case. > > > > > > > > > > Thanks > > > > > -Nagu > > > > > > > > > > > -----Original Message----- > > > > > > From: Hans Feldt [mailto:[email protected]] > > > > > > Sent: 03 September 2014 17:54 > > > > > > To: Hans Feldt; Nagendra Kumar; Hans Nordebäck; Praveen Malviya > > > > > > Cc: [email protected] > > > > > > Subject: RE: [devel] [PATCH 1 of 1] amfd: respond to shutdown op > > > > > > if lock has been issued before it completes [#1021] > > > > > > > > > > > > Or from 9.4.6: > > > > > > > > > > > > SA_AIS_ERR_BAD_OPERATION - The operation was not successful > > > > > > because the target entity is locked or locked for instantiation. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hans Feldt [mailto:[email protected]] > > > > > > > Sent: den 3 september 2014 14:15 > > > > > > > To: [email protected]; Hans Nordebäck; > > > > > > > [email protected] > > > > > > > Cc: [email protected] > > > > > > > Subject: Re: [devel] [PATCH 1 of 1] amfd: respond to shutdown > > > > > > > op if lock has been issued before it completes [#1021] > > > > > > > > > > > > > > Do we think OK is an appropriate error code here? > > > > > > > Maybe TIMEOUT? > > > > > > > /Hans > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: [email protected] [mailto:[email protected]] > > > > > > > > Sent: den 3 september 2014 13:45 > > > > > > > > To: Hans Feldt; Hans Nordebäck; [email protected] > > > > > > > > Cc: [email protected] > > > > > > > > Subject: [PATCH 1 of 1] amfd: respond to shutdown op if lock > > > > > > > > has been issued before it completes [#1021] > > > > > > > > > > > > > > > > osaf/services/saf/amf/amfd/si.cc | 4 ++++ > > > > > > > > 1 files changed, 4 insertions(+), 0 deletions(-) > > > > > > > > > > > > > > > > > > > > > > > > If shutdown op is undergoing, lock can be issued. > > > > > > > > If lock is isued, Amf is not responding to shutdown op. > > > > > > > > Amf should ideally respond to shutdown op immediately after > > > > > > > > it receives lock op. And after lock op completes, then Amf > > > > > > > > should respond to lock op. > > > > > > > > > > > > > > > > diff --git a/osaf/services/saf/amf/amfd/si.cc > > > > > > > > b/osaf/services/saf/amf/amfd/si.cc > > > > > > > > --- a/osaf/services/saf/amf/amfd/si.cc > > > > > > > > +++ b/osaf/services/saf/amf/amfd/si.cc > > > > > > > > @@ -881,6 +881,10 @@ static void > > si_admin_op_cb(SaImmOiHandle > > > > > > > > > > report_admin_op_error(immOiHandle, > > > > > > invocation, SA_AIS_ERR_TRY_AGAIN, NULL, > > > > > > > > "'%s' other > > semantics...", > > > > > > objectName->value); > > > > > > > > goto done; > > > > > > > > + } else { > > > > > > > > + rc = SA_AIS_OK; > > > > > > > > + > > > > > > avd_saImmOiAdminOperationResult(immOiHandle, si->invocation, > > > > > > rc); > > > > > > > > + si->invocation = 0; > > > > > > > > } > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > > ---- > > > > > > > ---- > > > > > > > -------- > > > > > > > Slashdot TV. > > > > > > > Video for Nerds. Stuff that matters. > > > > > > > http://tv.slashdot.org/ > > > > > > > _______________________________________________ > > > > > > > Opensaf-devel mailing list > > > > > > > [email protected] > > > > > > > https://lists.sourceforge.net/lists/listinfo/opensaf-devel
------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
