supportability JIRAs

[Yongjun Zhang <yz...@cloudera.com>]

Hi,

When creating jira, there is a "Labels" entry where we could label the jira
as supportability. It would help to do this, so we could possibly give
priority to fix them for better supportability,  especially for those JIRAs
that tend to be small but very high-impact for end users.

The types of jiras that we can label "supportability" are (see some
detailed description at the bottom of this mail):

- improving logs and error messages
- simplifying workflows for admins
- reducing configuration complexity
- adding new metrics
- ...

For example,

HDFS-7281 <https://issues.apache.org/jira/browse/HDFS-7281>Missing block is
marked as corrupted block

HDFS-7497 <https://issues.apache.org/jira/browse/HDFS-7497>Inconsistent
report of decommissioning DataNodes between dfsadmin and NameNode webui

HDFS-6959 <https://issues.apache.org/jira/browse/HDFS-6959>Make the HDFS
home directory location customizable.

HDFS-6403 <https://issues.apache.org/jira/browse/HDFS-6403>Add metrics for
log warnings reported by JVM pauses

This email serves as an proposal to do this kind of labeling when creating
new jiras. We could also go back to label old jiras for reference when time
allows.

Comments are welcome.

Thanks.

--Yongjun

Below is a bit more detailed description of some relevant scenarios (thanks
to Andrew Wang and Todd Lipcon):

1) In the presence of configuration errors, detecting them preemptively
before they result in the system getting into a funky state. For example,
we used to have a possible configuration where the NN would start up bound
to 0.0.0.0 and then advertise 0.0.0.0 to the SNN as its remote IP. This
meant that checkpointing wouldn't work, but would fail with confusing
errors. Aborting at startup made this easier to support.

2) In the presence of environmental issues, detecting them and giving
meaningful errors. For example, stuff like the GC Pause monitor that's in
the NN now is helpful because when something goes wrong, you have a smoking
gun. (even though it's not exactly an NN bug that GC happens, in some cases)

3) Changing non-specific error messages to specific ones. For example,
we've had cases before where we throw an NPE, and the "fix" is to check for
null and throw an IllegalArgumentException with a nice message or
something. It wasn't a bug that the system failed with that particular
config, but the error message tells the user/supporter exactly what to do
to fix it.