Modify pre-upgrade steps warn if table properties at system level

[dlmarion]

The following discussion took place in #5781

Can we make the pre upgrade steps check for tables props at the system level to help ease the upgrade process? Could prevent upgrade until these are remediated.

We could warn in the pre-upgrade step. There was discussion of moving the ZooKeeper related upgrade changes from the Upgrader to the start step, but that hasn't happened yet.

#5781 modified the Upgrader to copy the table properties from the system configuration to all namespaces unless the property was already there with a different value. Then it removes the table properties from the system configuration. The pre-upgrade step should warn the user that this is going to occur.

[ctubbsii]

I think this is for 2.1, since it's the pre-upgrade steps in 2.1 prior to running the 4.0 upgrade code.

[dlmarion]

I think I was envisioning this happening in the start step. There is no guarantee that the prepare phase will be run.

[keith-turner]

#5781 modified the Upgrader to copy the table properties from the system configuration to all namespaces unless the property was already there with a different value. Then it removes the table properties from the system configuration. The pre-upgrade step should warn the user that this is going to occur.

Instead of automatically trying to handle this situation, could fail instead like the following.

1. In 2.1 run upgrade prepare and it warns
2. In 4.0 run upgrade start and it fails when table props are seen
3. User has to manually deal w/ the table props in some way

[ctubbsii]

Wasn't the previous idea to move these to each namespace during the upgrade? That would conflict with the 4.0 failing on start. If we fail, we could simplify the upgrade code, but it means the user would have to manually add it to the namespaces using ZooPropEditor or something like that.

[keith-turner]

Wasn't the previous idea to move these to each namespace during the upgrade? That would conflict with the 4.0 failing on start. If we fail, we could simplify the upgrade code, but it means the user would have to manually add it to the namespaces using ZooPropEditor or something like that.

Decided to fail in 2.1 in #5888. I think automagically moving the props during upgrade could be problematic. Best if the user handles this. They could have inconsistent table props in the files across the cluster. They need to get all of the file across the entire cluster fixed in the best way they see fit. They may want to only set these on a subset of tables or namespaces.

[ctubbsii]

I was confused between the SiteConfiguration and the SystemConfiguration. The SiteConfiguration should cause an error. If it's in the SystemConfiguration (in ZK), it will be upgraded to each namespace to achieve equivalent behavior (I hope it also gives a warning). I made other related comments at #5886 (comment)

[ctubbsii]

See also #5854