Completed functionality for admin check command

[kevinrr888]

New checks for admin check command

• Implemented SYSTEM_CONFIG check:
  • Checks ZooKeeper locks for Accumulo server processes
  • Checks ZooKeeper table nodes
  • Checks that the WAL metadata in ZooKeeper is valid
• Added new SERVER_CONFIG check:
  • Checks that all configured properties are valid
  • Checks that required properties are present in the config
• Added new tests in AdminCheckIT for SYSTEM_CONFIG and SERVER_CONFIG. Added failing test cases for all checks.
• Updated description for admin check run command functionality #4892. This describes all the checks thus far for the new accumulo admin check command. See this for the complete functionality of the command.
• Considered adding check to MetadataConstraints to ensure tablets reference files that actually exist (i.e., in MetadataConstraints.validateDataFileMetadata, check that stf.getPath() exists in HDFS). This would make sure the file exists before the mutation is ever written and would also check that it exists when we run the admin check command for metadata (root metadata, root table, and metadata table): see MetadataCheckRunner.checkColumns(). However, this led to a ComprehensiveIT test failure, so I assume the file may not always exist before the metadata for it is written...
• Deleted CheckServerConfig (run via accumulo check-server-config) as the new accumulo admin check run SERVER_CONFIG will inherently do the same checks. Maybe we don't want to completely get rid of this check yet. Maybe it would be better to have the check just output that the check has moved under accumulo admin check?
• There were a couple other existing check commands that I originally considered moving under this new admin command (CheckAccumuloProperties and CheckCompactionConfig), however, their usage is specifically to check a file irrespective of any running Accumulo instance, so I did not feel it would make sense to move these under the new admin command.

This PR along with #4957 closes #4892

[kevinrr888]

any other important ones I left out? Any I shouldn't have included?

[keith-turner]

Not a change for this PR, but wondering if this should be pushed to the validation code of each property. For example could we attempt to do something like the following in addition to the code that goes through the defined props above. Thinking if a props validation fails on null or empty string then its "required" and should be set. Looking at some of the important props, like instance.volumes their types would need change from something besides STRING that is more specific, which would be a good general change to make (would be good to have specific type to do validation for instance volumes and that could include not accepting empty string).

    for(var prop : Property.values()) {
      var value = config.get(prop);
      if (!Property.isValidProperty(prop.getKey(), value)) {
        log.warn("Invalid property (key={} val={}) found in the config", prop, value);
      }
    }

If the rest of the code worked like this, then would not need this list here.

[keith-turner]

As the code is currently written it loops over all the props the loop in the prev comment may not work well because the get method replaces w/ the default value when not present.

In general it seems like it would be best to move the concept of a required property into the Property class in some form. Then the entire system could react appropriately when a required property is not present and is requested. For now a list in this class seems fine.

I experimented w/ validating the volume prop in #5365 based on the exploration done as part of this.

[kevinrr888]

This sounds like a good idea to me. There are a lot of PropertyType.STRING when a String isn't really what the property is. PropertyType exists to check that the property is valid; setting the PropertyType to STRING is just a way to ignore this validation. I wonder if it would be best for a 1 to 1 mapping Property to PropertyType. This would probably be overkill though, another idea could be to analyze the PropertyTypes that are always valid. From briefly looking, PropertyType.PATH, PropertyType.STRING, PropertyType.URI are always valid. I don't think any properties should always be valid. Those that are PropertyType.STRING could probably be given a more appropriate existing PropertyType or a new one. PATH and URI could have validation.

In addition to this, can analyze all properties, determine if they are required or not, and change the validation:

• Properties that are not required could accept empty string, null, or a valid value (where validity is well defined)
• Properties that are required could only accept a valid value

Like you said, for this PR, can just push this list of required properties into Property. Maybe for now/in this PR this list of required props is only accessed/checked in this admin check. Might be a bit of a scope creep to start checking this list elsewhere in the code. Could do it in follow on.

[keith-turner]

Definitely want to avoid any scope creep in this PR. Identified some areas that need improvement based on this work, we can open follow on issues or PRs for those.

[keith-turner]

Could leave the list as is in the PR. For follow on issues, do we need two issues? One for addressing the STRING types and another for somehow representing and documenting required props in the Property.java?

[kevinrr888]

I think either would be fine, but it might be easier as just one issue. There would be overlap in these changes so might be hard to split up/work on as two separate issues/PRs. For example, instance.volumes would need to be a required property (which would be tied to validation in it's PropertyType) and would need to be moved away from PropertyType.STRING

[kevinrr888]

@keith-turner - Could you take another look at this when you get the chance? I've updated this to work for 4.0. Since there's no more 3.x, this should make things simpler here. Main things changed in latest commit were:

• Addressed Completed functionality for admin check command #5348 (comment)
• SystemConfigCheckRunner changes

There are also some outstanding comments/questions

[keith-turner]

Noticed #6078 and #6079 while looking at this.

[dlmarion]

LGTM. I think @keith-turner had some other comments too. Suggest waiting for his approval also before merging.