-
Notifications
You must be signed in to change notification settings - Fork 9.1k
HDFS-16957. RBF: Exit status of dfsrouteradmin -rm should be non-zero for unsuccessful attempt #5487
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: trunk
Are you sure you want to change the base?
Conversation
… for unsuccessful attempt
💔 -1 overall
This message was automatically generated. |
All tests in TestRouterRPCMultipleDestinationMountTableResolver are passing locally |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this was raised somewhere in past as well but not done considering incompatible
🎊 +1 overall
This message was automatically generated. |
I thought so too, that's why wanted to check on the Jira :) |
@ayushtkn @goiri Would you recommend fixing them all once and for all on trunk (3.4.0) only with this PR? So that at least with 3.4.0 onwards, we have consistent behavior? |
yep, that is something known to me, it is there with almost all commands, and we had a discussion around it long back and it was kind of: 'Changing exit code is incompatible', remember discussing internally long back as well and the conclusion was people who have internal test scripts and code they heavily rely on these exit code(we were one of those then), so, it got dropped.
I won't say yes, have always been part of the gang or say I come from that era which was strong believer and follower of compat guidelines. Not sure how people are dealing nowadays though :( see this ex., just a minor CLI change which in all ways is good very useful got reverted just because of compat from all branches. that is some fun to follow |
Ah yes, not having compatibility is a pain for sure :( Any decision is fine though :) |
Do we have this exit code output being 0 in 3.3.X? |
I have to say that I'm even willing to break our own "compatibility" given that we are breaking compatibility with the rest of the world that assumes that a failed command should be -1. |
It is there since very starting, even in branch-2.9 There ain't any release line which has not released this behaviour :) |
On the above reference of branch-2.9, though even Whereas right now on 3.3, |
Looks like this is the commit that has changed behavior for |
Hmm, that changed something wrapped with the bug. There failure was claimed as successful or something like that…. But this behaviour including that also is there since branch-3.1, should be in almost all 3.2.x and 3.3.x no strong opinions here, slightly more inclined to stay with compat, for one reason 3.3.x has this behaviour and changing this is just peace to eyes but would break some test scripts out of which I too was part long back |
DFS router admin returns non-zero status code for unsuccessful attempt to add or update mount point. However, same is not the case with removal of mount point.
For instance,
Removal of mount point should stay consistent with other options and return non-zero (unsuccessful) status code.