Releasing NNF Software
NNF Software Overview
The following repositories comprise the NNF Software and each have their own versions. There is a
hierarchy, since nnf-deploy packages the individual components together using submodules.
Each component under nnf-deploy needs to be released first, then nnf-deploy can be updated to
point to those release versions, then nnf-deploy itself can be updated and released.
The documentation repo (NearNodeFlash/NearNodeFlash.github.io) is released separately and is not
part of nnf-deploy, but it should match the version number of nnf-deploy. Release this like the
other components.
nnf-ec is vendored in as part of nnf-sos and does not
need to be released separately.
Primer
This document is based on the process set forth by the DataWorkflowServices Release Process. Please read that as a background for this document before going any further.
Requirements
To create tags and releases, you will need maintainer or admin rights on the repos.
Release Each Component In nnf-deploy
You'll first need to create releases for each component contained in nnf-deploy. This section
describes that process.
Each release branch needs to be updated with what is on master. To do that, we'll need the latest
copy of master, and it will ultimately be merged to the releases/v0 branch via a Pull Request.
Once merged, an annotated tag is created and then a release.
Each component has its own version number that needs to be incremented. Make sure you change the
version numbers in the commands below to match the new version for the component. The v0.0.3 is
just an example.
-
Ensure your branches are up to date:
-
Create a branch to merge into the release branch:
-
Merge in the updates from the
masterbranch. There should not be any conflicts, but it's not unheard of. Tread carefully if there are conflicts. -
Verify that there are no differences between your branch and the master branch:
If there are any differences, they must be trivial. Some READMEs may have extra lines at the end.
-
Perform repo-specific updates:
- For
lustre-csi-driver,lustre-fs-operator,dws,nnf-sos, andnnf-dmthere are additional files that need to track the version number as well, which allow them to be installed withkubectl apply -k.
Repo Update nnf-mfuThe new version of nnf-mfuis referenced by theNNFMFUvariable in several places:nnf-sos
1.MakefilereplaceNNFMFUwithnnf-mfu'stag.nnf-dm
1. InDockerfileandMakefile, replaceNNFMU_VERSIONwith the new version.
2. Inconfig/manager/kustomization.yaml, replacennf-mfu'snewTag: <X.Y.Z>.lustre-fs-operatorupdate config/manager/kustomization.yamlwith the correct version.dwsupdate config/manager/kustomization.yamlwith the correct version.nnf-sosupdate config/manager/kustomization.yamlwith the correct version.nnf-dmupdate config/manager/kustomization.yamlwith the correct version.lustre-csi-driverupdate deploy/kubernetes/base/kustomization.yamlandcharts/lustre-csi-driver/values.yamlwith the correct version. - For
-
Target the
releases/v0branch with a Pull Request from your branch. When merging the Pull Request, you must use a Merge Commit.Note
Do not Rebase or Squash! Those actions remove the records that Git uses to determine which commits have been merged, and then when the next release is created Git will treat everything like a conflict. Additionally, this will cause auto-generated release notes to include the previous release.
-
Once merged, update the release branch locally and create an annotated tag:
-
Now that a tag exists, a release can be created via the GitHub CLI. Alternatively, use the Web UI.
Note Do not do this gh release create in the nnf-deploy repo. That repo will create a release automatically when a new tag is pushed.
- GOTO Step 1 and repeat this process for each remaining component.
Release nnf-deploy
Once the individual components are released, we need to update the submodules
in nnf-deploy's master branch before we create the release branch. This ensures
that everything is current on master for nnf-deploy.
-
Update the submodules for
nnf-deployon master: -
Create a branch to capture the submodule changes for the PR to
master -
Commit the changes and open a Pull Request against the
masterbranch. -
Once merged, follow steps 1-3 from the previous section to create a release branch off of
releases/v0and update it with changes frommaster. -
There will be conflicts for the submodules after step 3. This is expected. Update the submodules to the new tags and then commit the changes. If each tag was committed properly, the following command can do this for you:
-
Verify that each submodule is now at the proper tagged version.
-
Do a
git addfor each of the submodules. -
Update
config/repositories.yamlwith the referenced versions for:lustre-csi-driverlustre-fs-operatornnf-mfu(Search for NNFMFU_VERSION)
-
Tidy and make
nnf-deployto avoid embarrassment. -
Do another
git addfor any changes, particularlygo.modand/orgo.sum. -
Verify that
git statusis happy withnnf-deployand then finalize the merge from master by with agit commit. -
Follow steps 6-7 from the previous section to finalize the release of
nnf-deploy.
Note In step 7, the push of the tag will cause nnf-deploy's handle_release_tag workflow to automatically create the release.
The software is now released!
Clone a release
The follow commands clone release v0.0.7 into nnf-deploy-v0.0.7