Hi Mathi Thanks, we can go with your version.
Thanks Gary On 7/04/2016, 3:54 PM, "Mathivanan Naickan Palanivelu" <[email protected]> wrote: >Comment inline: >Mathi. > >> -----Original Message----- >> From: Gary Lee [mailto:[email protected]] >> Sent: Thursday, April 07, 2016 6:39 AM >> To: Mathivanan Naickan Palanivelu >> Cc: [email protected]; [email protected] >> Subject: Re: CLM PR update for #1646 >> >> Hi Mathi >> >> Thanks. Hope this is OK: >> >> * A CLM handle held by a client will become invalidated after recovery from a >> headless state. On reception of ERR_BAD_HANDLE, each CLM client must call >> saClmInitialize() again to obtain a new CLM handle. >I thought there is no 'recovery' action taken as such in the case of CLM. >So, we could go like as below: > >The CLM handle(SaClmHandleT) held by an application becomes invalid when the >system controller nodes go for a reboot. >As a result of this the CLM application shall receive ERR_BAD_HANDLE and the >Application is expected to obtain a new CLM handle by calling >saClmInitialize() and to honour >The SA_AIS_ERR_TRY_AGAIN error code during this scenario. > > >> >> >> Thanks >> Gary >> >> On 6/04/2016, 8:18 PM, "Mathivanan Naickan Palanivelu" >> <[email protected]> wrote: >> >> >Looks good. >> >But, i think instead of phrasing it open ended (for eg:- 'may become >> >invalidated'), we should be specific to mention the scenario when this error >> code would be returned. >> > >> >Thanks, >> >Mathi. >> >----- [email protected] wrote: >> > >> >> Hi Mathi / Anders >> >> >> >> I’d like to add this to section 4.2 Implementation Notes of the CLM >> >> PR. >> >> >> >> * A CLM handle held by a client may become invalidated and >> >> ERR_BAD_HANDLE will be returned to the client. For example, after >> >> recovery from a headless state and reception of ERR_BAD_HANDLE, each >> >> CLM client will need to call saClmInitialize again to obtain a new >> >> CLM handle. >> >> >> >> Thanks >> >> Gary >> >> >> >> >> >> >> >> >> >> On 19/01/2016, 11:29 PM, "Anders Widell" <[email protected]> >> >> wrote: >> >> >> >> >Ack for the series (code review only). >> >> > >> >> >regards, >> >> >Anders Widell >> >> > >> >> >On 01/07/2016 05:38 AM, Gary Lee wrote: >> >> >> Summary: clm: support simultaneous reboot of both controller nodes >> >> [#1646] >> >> >> Review request for Trac Ticket(s): 1646 Peer Reviewer(s): Mathi, >> >> >> Anders W Pull request to: >> >> >> 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 n >> >> >> OpenSAF services n >> >> >> Core libraries y >> >> >> Samples n >> >> >> Tests n >> >> >> Other n >> >> >> >> >> >> >> >> >> Comments (indicate scope for each "y" above): >> >> >> --------------------------------------------- >> >> >> >> >> >> changeset 44df7b651431e306911e9b327d182e86ce3022fb >> >> >> Author: Gary Lee <[email protected]> >> >> >> Date: Thu, 07 Jan 2016 15:27:12 +1100 >> >> >> >> >> >> clma: send BAD_HANDLE to all clients if both controller nodes >> >> >> are >> >> >> unavailable [#1646] >> >> >> >> >> >> If we detect clmd is unavailable on both controller nodes, then >> >> set >> >> >> clma_cb.clms_reinit_required as true. >> >> >> >> >> >> Once an instance of clmd recovers, notify all clients that their >> >> CLM handle >> >> >> is stale by returning BAD_HANDLE. Each client will need to call >> >> >> saClmInitialize again. >> >> >> >> >> >> changeset b61f9fb02800dc6878dfb41b7d24c8a798149ee0 >> >> >> Author: Gary Lee <[email protected]> >> >> >> Date: Thu, 07 Jan 2016 15:27:20 +1100 >> >> >> >> >> >> clm nodeagent: send nodeup again when clms is available after >> >> both >> >> >> controllers are down [#1646] >> >> >> >> >> >> >> >> >> Complete diffstat: >> >> >> ------------------ >> >> >> osaf/libs/agents/saf/clma/clma.h | 2 ++ >> >> >> osaf/libs/agents/saf/clma/clma_api.c | 30 >> >> +++++++++++++++++++++++------- >> >> >> osaf/libs/agents/saf/clma/clma_mds.c | 27 >> >> ++++++++++++++++++++++++--- >> >> >> osaf/libs/agents/saf/clma/clma_util.c | 2 ++ >> >> >> osaf/services/saf/clmsv/nodeagent/main.c | 10 ++++++++++ >> >> >> 5 files changed, 61 insertions(+), 10 deletions(-) >> >> >> >> >> >> >> >> >> Testing Commands: >> >> >> ----------------- >> >> >> Apply "headless feature" patches for other services Reboot both >> >> >> controllers >> >> >> >> >> >> Testing, Expected Results: >> >> >> -------------------------- >> >> >> Once a controller recovers, a CLM client should be signalled to >> >> call saClmDispatch() and >> >> >> receive SA_AIS_ERR_BAD_HANDLE >> >> >> >> >> >> Conditions of Submission: >> >> >> ------------------------- >> >> >> <<HOW MANY DAYS BEFORE PUSHING, CONSENSUS ETC>> >> >> >> >> >> >> >> >> >> 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. >> >> >> >> ------------------------------------------------------------------------------ _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
