[
https://issues.apache.org/jira/browse/HDFS-11096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16168686#comment-16168686
]
Allen Wittenauer commented on HDFS-11096:
-----------------------------------------
bq. how do you feel about set -v?
It's usually overkill. It typically means that the code isn't giving enough
hints about what it's doing or that it lacks a --debug option to tell me about
important events if something is going wrong and I need in depth help.
bq. And did you mean set +e?
No, I meant setting 'set -e' as was in the code. The default for bash is set
+e.
bq. I feel like if it's okay for a command to sometimes fail, you can deal
with that return code explicitly, otherwise I'd like that failure to bubble up.
Am I missing something?
set -e will exit bash with no chance to deal with the failure. That's
disastrous if the code actually knows how to exit out gracefully or has
workarounds or multiple ways to try something or wants to use boolean result
codes.
bq. Not sure I understand exactly what hadoop_actual_ssh was supposed to be
doing before, but it's not used elsewhere and is marked as private
hadoop_actual_ssh is called from hadoop_connect_to_hosts_without_pdsh. That
code was originally written with xargs, but it wasn't in a POSIX compatible way
so the xargs implementation got removed. But when it was written with xargs,
the problem was one can't call a function as a parameter. So ... other ways
were invented. You can see the original xargs implementation in
hadoop-user-functions.sh.example to see how I worked around it.
That said... I have a hunch that your changes probably break hadoop/hdfs/...
--workers flag either completely or just the output when pdsh isn't installed.
An easier entry point is likely to be hadoop_connect_to_hosts which can take
advantage of pdsh and do things in parallel. Just need to set the appropriate
HADOOP_WORKERS var.
bq. $(dirname $ {0})
That's shellcheck hinting that something may be wrong... ;)
I generally go for something like:
{code}
this="${BASH_SOURCE-$0}"
BINDIR=$(cd -P -- "$(dirname -- "${this}")" >/dev/null && pwd -P)
{code}
This fixes some potential issues:
* deals with most of the ridiculous aliasing that people tend to with cd
* leading dashes for directory names aren't a problem
* gives an absolute, symlink resolved path
* .... and one of my absolute favorite obscure bugs: bash foo.sh now works if
foo.sh is in the path
{code}
$ cat ~/bin/foo.sh
echo "0: $0"
echo "BS0: ${BASH_SOURCE-$0}"
$ foo.sh
0: /Users/aw/bin/foo.sh
BS0: /Users/aw/bin/foo.sh
$ bash foo.sh
0: foo.sh
BS0: /Users/aw/bin/foo.sh
{code}
bq. Switch to using create-release - --native wasn't working because the Docker
image doesn't have a high enough version of cmake
Rebase required? Or is this some other Dockerfile? Because otherwise precommit
would be failing...
> Support rolling upgrade between 2.x and 3.x
> -------------------------------------------
>
> Key: HDFS-11096
> URL: https://issues.apache.org/jira/browse/HDFS-11096
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: rolling upgrades
> Affects Versions: 3.0.0-alpha1
> Reporter: Andrew Wang
> Assignee: Sean Mackrory
> Priority: Blocker
> Attachments: HDFS-11096.001.patch, HDFS-11096.002.patch,
> HDFS-11096.003.patch
>
>
> trunk has a minimum software version of 3.0.0-alpha1. This means we can't
> rolling upgrade between branch-2 and trunk.
> This is a showstopper for large deployments. Unless there are very compelling
> reasons to break compatibility, let's restore the ability to rolling upgrade
> to 3.x releases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
