Versioning for the chart and exporters

[mpryc]

As I mentioned in chat, chart versions don't need to be (and shouldn't be) in lockstep with the exporter version. This is because chart updates would bump the version, and then immediately be out of sync with the exporter code.

There is a larger question: what does it mean to have a tag in this repo, since we have both exporter code and the charts here?

Originally posted by @KevinMGranger in #366 (review)

We need to agree around 3 things

1. Exporters:
   a. Should exporters be on a separate lifecycle and versioning as an "exporters bundle"
   b. Should each of the exporter be on a separate lifecycle and versioning and we should have compability matrix for them

2. Pelorus Chart versioning. Should this be synced with exporters or maybe separate one ?

3. Tagging. Does the new release and tag in the pelorus repo means synced tag with the Pelorus Chart? Currently github workflows do build and push containers to quay.io and retag them with the github pelorus tag, so it means each exporter will be at container version matching the tag, however it's not matching the version mentioned in Chart.

[mpryc]

Converting to discussion as we need to agree on versioning of exporters/charts and now the pelorus-operator.

[KevinMGranger]

Relevant documentation question: #496

[mpryc]

The release process requires syncing or ensuring we deliver proper versions in the following parts of the Pelorus project:

There are couple of things to consider:

1. Some of the PRs may change the versions of the <helm_version_A> <helm_version_B1> or <helm_version_C1>. Those versions can be changed independently and are following a standard SemVer specification. For the SemVer specification we are currently using only X.Y.Z as integers without any suffix to the Z.

2. The helm version MUST be updated if any of the files in the relevant Helm chart sub-folder is modified as part of the PR.

3. On every PR merged that included changes to the exporters source code a new set of exporters is being built in the quay.io/pelorus/ namespace with two image tags:

   • latest
   • <hash>, where hash match the commit hash of the merged PR

4. On Git Create Release:
   a. New Git <TAG> is being created
   b. <hash> image tag is being renamed to stable. Note that <hash> is taken from the commit that was used to create release and must have been merged prior to creating release. It may have happened that <hash> was created on top of not TIP of the git repository, this would mean that the commits after the one that created <hash> will not be included in the release.
   c. It is possible to modify at this point the Helm Chart versions, but they may not match the <TAG> as the versions may have been increased to the number above the <TAG> in previous PRs that required Helm chart bumps.

5. Pelorus Operator
   a. The versioning of Pelorus Operator as in the <operator_version> is independent of the Helm Chars and Quay Exporter images.
   b. The Helm Charts used to create Pelorus Operators are taken from the original Helm Charts during Pelorus operator release process, so they may/will be older after some development cycles that were not creating new operator, just updating helm charts in the git repository.
   c. Currently The Helm Charts used to create Pelorus Operators are pointing to the stable tag of the exporter images.

[mpryc]

1. Last GitHub release:

   • GitHub TAG: v2.0.1
   • Helm charts
     • Pelorus: 2.0.1
     • exporters: v1.3.0
     • operators: 2.0.0
   • Exporter images: stable

2. Current master branch:

   • GitHub TAG: n/a
   • Helm charts
     • Pelorus: 2.0.5
     • exporters: 2.0.5
     • operators: 2.0.4
   • Exporter images: stable

3. Last Pelorus Operator release:

   • Pelorus Operator Version: 0.0.2
   • Helm charts
     • Pelorus: 2.0.4
     • exporters: 2.0.4
     • operators: n/a
   • Exporter images: stable

n/a - this does not apply. For example Pelorus Operator does not need operators Helm charts as the OLM takes care of those.

[mpryc]

Proposal of current release:
Currently the highest Helm Chart version is at 2.0.5, so we will create the GitHub release with 2.0.6 version. In fact we will skip some versions, because current GitHub release is at 2.0.1

• All three Helm Charts will be synced to 2.0.6 version.
• The Exporter Quay container images are tagged with two tags. Release version tag and 'stable'. For release we will modify the helm charts to point to the version tag. This way we ensure that different pelorus operators won't be using same 'stable' release of exporters. https://github.com/konveyor/pelorus/blob/master/charts/pelorus/subcharts/exporters/templates/_imagestream_from_image.yaml#L23
• In the same PR we will create pelorus-operator, that will be created out of the updated Helm Charts from the same PR. The version of pelorus-operator will continue as is so will be not in sync with GitHub release and Helm Charts.

From that release we will introduce "-rc.1" suffix to our Helm Charts, so next release will have incremental number 2.0.6 and subsequent PRs which will not create release will be bumping Helm charts with rc.X:

• Release 2.0.5
• PR change: 2.0.5-rc.1
• Next PR change: 2.0.5-rc.2
• Next release: 2.0.6
• PR change: 2.0.6-rc.1

Only the releases without suffix will be accepted as the input for pelorus operator.

[mpryc]

@weshayutin @KevinMGranger @mateusoliveira43 ^^

[mateusoliveira43]

I would try to have just one version for everything. I think it is harder to work with 3 different ones (exporters, charts and operator), and on top of that, the repo version. Today our product is the operator, this should be the version that our repo holds.

I think it would be good if we have operator creation be all automated. My idea would be:

• to have a separate branch to it (something close to what I thought https://github.com/mateusoliveira43/cly, the gh-pages branch) (I am thinking about a separate branch because the operator code has a lot of duplication with the charts code and it is all created by script, so I would not save it among the code we "really" need).
• each time we create a release on the repo, the code in that branch would be updated and a new version of the operator would be created in OpenShift (it would also handle creating new images versions for the exporters, which we would not care anymore).
• each release would change the version of charts (we can not just remove them, right? but we would not care about them anymore), and not each PR that touches their code, like today (even if we do not touch their code, for example, just updating exporters).

Do you believe this is possible to be done and it is a good approach?

[mpryc]

I am convinced that having one version at this point is a good approach, because we already released number of GitHub versions and it's not that easy to downgrade them back.

Also bumping pelorus-operator version isn't something that we can really do /from the user perspective it would be bad to jump from 0.0.3 to 2.0.6).

Also we don't recommend using helm charts on it's own, so really those versions (github/image tag/helm charts) are only for the internal to the project purposes at the moment.

[mpryc]

Agreed to what's in the #811 (comment) with one addition:
Any Helm chart update will cause other Helm chart updates as well, so they are in sync all the time.
Only GitHub releases causes the Helm Chart to be bumped to the GitHub version, if it's not GitHub release then Helm chart will be updated with the -rc.X suffix, so for example: 2.0.5-rc.1 -> 2.0.5-rc.2 -> 2.0.5-rc.3 -> 2.0.6 (release)

[mpryc]

NOTE: The rc.1, rc.2 are pre-relase versions, so they are always lower then release versions:

2.0.5 is greater then 2.0.5-rc.1, so when 2.0.5 is out our release candidate should start with 2.0.6-rc.1 -> 2.0.6-rc.2 and then when the released it's 2.0.6 .

The above example must be modified:

2.0.4 (release) -> 2.0.5-rc.1 -> 2.0.5-rc.2 -> 2.0.5-rc.3 -> 2.0.5 (release)

[mpryc]

The chart-lint is using the following library for comparing the semver:
https://github.com/Masterminds/semver#working-with-prerelease-versions

[mateusoliveira43]

Closing discussion as PR #990 (and others) applied what has been discussed here