Summary: mds: Send NCSMDS_DOWN with vdest if there is no any adest [#2941]
Review request for Ticket(s): 2941
Peer Reviewer(s): Hans
Pull request to: *** LIST THE PERSON WITH PUSH ACCESS HERE ***
Affected branch(es): develop
Development branch: ticket-2941
Base revision: 3b80698770d599bc15b97119cbfd4098943d7643
Personal repository: git://git.code.sf.net/u/minh-chau/review
--------------------------------
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
NOTE: Patch(es) contain lines longer than 80 characers
Comments (indicate scope for each "y" above):
---------------------------------------------
*** EXPLAIN/COMMENT THE PATCH SERIES HERE ***
revision 0fe8a3f11e5d0d464d7d03287a636da7681895bc
Author: Minh Chau <minh.c...@dektech.com.au>
Date: Thu, 25 Oct 2018 13:34:05 +1100
mds: Send NCSMDS_DOWN with vdest if there is no any adest [#2941]
If split brain happens and network merges back, at this point in time
there are a few mds events coming to payloads, which are the SVC UP
from the other controller; SVC down from services in both controllers
due to reboot from split brain detection.
In the ticket description, the first partition includes SC1, PL3,
the second partition includes SC2, PL4, PL5. The amfnd on PL3 is
missing NCSMDS_DOWN with vdest in the below scenario:
- SVC up event from the other amfd (on SC2)
- SVC down event from amfd (SC1), it's the same active adest from
mds-PL3's view, start await_active timer, but no NCSMDS_DOWN with
vdest is sent because the adest on SC2 exists.
- SVC down event from amfd (SC2), it's different active adest.
Because the payloads reside in different partitions so they don't
have the same active adest view at mds level. When both SCs go down
due to split brain detection, the same SVC down events occur and
comes to all payloads, but they have different view so they behave
differently to the payloads in the other partition.
The patch adds an additional condition to send NCSMDS_DOWN if there is
no actual adest existed
Complete diffstat:
------------------
src/mds/mds_c_api.c | 80 ++++++++++++++++++++++++++++++-----------------------
1 file changed, 46 insertions(+), 34 deletions(-)
Testing Commands:
-----------------
*** LIST THE COMMAND LINE TOOLS/STEPS TO TEST YOUR CHANGES ***
Testing, Expected Results:
--------------------------
*** PASTE COMMAND OUTPUTS / TEST RESULTS ***
Conditions of Submission:
-------------------------
ack
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 ~/.gitconfig file (i.e. user.name, user.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
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
