Page History

...

1. stable builds/intermittent test failures

• The HDDS-3698-nonrolling-upgrade branch has no intermittent test failures.
• Most intermittent failures specific to the HDDS-3698-nonrolling-upgrade branch were tracked and resolved in HDDS-4833.
• There is one known intermittent failure that has only been observed once so far. It is being tracked in Other intermittent failures have been resolved in HDDS-5109 and HDDS-5336.

2. documentation

• hadoop-hdds/docs/feature/design/how-to-do-a-nonrolling-upgrade.md contains instructions for users to upgrade a cluster using the framework.

• Documentation will be refined in coming weeks, before it is needed in the 1.2.0 release.

...

• hadoop-hdds/docs/content/design/upgrade-dev-primer.md contains instructions for developers who need to add a feauture feature using the upgrade framework.
• hadoop-hdds/docs/content/design/nonrolling-upgrade.md contains links to the main design document and presentation.
• hadoop-hdds/docs/content/design/omprepare.md contains links and summary for OM preparation design document.

...

• Sonar for master

  • Code coverage: 7374.4%8%

• Sonar for upgrades

  • Code coverage: 73.3%

• OM Prepare and general upgrade flow are tested through new acceptance tests which are not reflected in the code coverage.

8. build time

• Recent run passing runs from master:

  • https://github.com/apache/ozone/actions/runs/927339353 (2:09)
  • https://github.com/apache/ozone/actions/runs/923891108 (1:49)
  • https://github.com/apache/ozone/actions/runs/923951010 (2:02)

• Recent passing runs from upgrade branch:

  • https://github.com/apache/ozone/actions/runs/923010777 (2:02)
  • https://github.com/apache/ozone/actions/runs/941546330 (1:58)
  • Took 2:38 total.

  Recent run from upgrades

  • Took 2:51 total.

• Although lots of upgrade specific tests were added, the extra time is mostly due to two sets of testsfollowing are the most time consuming:

1. New upgrade acceptance tests, which walk through a cluster upgrade from the last release's docker image to the current build, in order to catch backwards incompatible changes.

   • Although we previously had upgrade tests on master, the added tests use the upgrade framework which uses more commands and tests, and therefore takes longer to run.

2. New upgrade integration tests in TestHDDSUpgrade, which test various failure combinations that could occur during the upgrade.

   • Only a subset of these tests are currently being run to save time.

3. New integration tests in TestOzoneManagerPrepare, which tests OM preparations under various failure and request combinations.

9. possible incompatible changes/used feature flag:

...

• The following dependencies have been added:

  • aspectjrt-1.8.9.jar
  • aspectjweaver-1.8.9.jar
  • reflections-0.9.12.jar

• All new libraries have compatible licenses. (License file update: HDDS-5137)

11. performance

• The majority of the upgrade framework is not used when an upgrade is not being performed, so it is not expected to have a performance impact.

• There is a small change on the write path for OM: The new LayoutVersionInstanceFactory is used to  LayoutVersionInstanceFactory was added to potentially handle client requests within OzoneManagerRatisUtils. This does not , although this is not being used yet to accommodate HDDS-2939 (filesystem optimizations).

•  Changes do not seem to affect performance based on simple freon testing (3 runs per branch):

ozone freon rk --num-of-keys=100 --num-of-buckets=10 --num-of-volumes=1 --replication-type=RATIS --factor=THREE

...

12. security considerations

...

The branch introduced the RPC methods in the ScmAdminProtocol.proto to initialize (and finalize) the upgrade process. They are available only to the admins (HDDS-5138).