FYI - Just pushed it with adding changes related to CLMNA (i.e. election mechanism).
Thanks, Mathi. ----- [email protected] wrote: > Hi Mathi > > I’ve updated the PR doc (please see attachment). Please push it if > you’re happy with it. > > Thanks > Gary > > > > > On 7/04/2016, 4:13 PM, "Gary Lee" <[email protected]> wrote: > > >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 ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
