search

operator-framework / olm-docs

Hugo doc site for https://github.com/operator-framework/operator-lifecycle-manager
10 stars 79 forks source link

[channel-namming] - supplement recommendations #232

Closed camilamacedo86 closed 2 years ago

camilamacedo86 commented 2 years ago

Description

We are proposing some additionals on its documentation. What is the delta?

Within a channel each patch release should be directly upgradable to the HEAD of channel. Use skips or skipRange to provide this behaviour. (i.e. skipRange to publish a patch for 3.6.zunder thestable-v3.6 would mean setting the skipRange to be >= 3.5.z. < 3.6.z, where 3.5.z represents the oldest 3.5.z version for which you can provide direct upgrade support to 3.6.z latest)

Nit: We added the links to the respective docs as well.

camilamacedo86 commented 2 years ago

c/c @dmesser @joelanford @bparees

camilamacedo86 commented 2 years ago

c/c @anik120

camilamacedo86 commented 2 years ago

Hi @fgiloux,

All improvements suggestions were addressed as well. Really thx for your review :-)

fgiloux commented 2 years ago

/lgtm my comments have been addressed. In regards to the discussion legacy vs FBC I believe that they will cohabit for some more time and there is value in having both documented. Community operators and their catalogs may move quicker than operators and their catalogs built within enterprise having strict and time consuming validation processes, slow moving infrastructures. We still need to keep them onboard.

openshift-ci[bot] commented 2 years ago

@fgiloux: changing LGTM is restricted to collaborators

In response to [this](https://github.com/operator-framework/olm-docs/pull/232#issuecomment-1086173133): >/lgtm >my comments have been addressed. >In regards to the discussion legacy vs FBC I believe that they will cohabit for some more time and there is value in having both documented. Community operators and their catalogs may move quicker than operators and their catalogs built within enterprise having strict and time consuming validation processes, slow moving infrastructures. We still need to keep them onboard. Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
camilamacedo86 commented 2 years ago

Hi, @anik120 really thank you for your help. I addressed all comments and mainly accepted all (99%) of your suggestions. I hope that it is good enough to get merged now. Let us know. Again, thx a lot for your time.

cdjohnson commented 2 years ago

@camilamacedo86 I do have some concerns, which reflect why we did not adopt this naming strategy. I apoologize for not commenting earlier, but I wanted some of the internal discussions and noise to die down first....

You can see my research here for some backround.

Regarding the suggested channel naming of <frequency>-<version>:

  1. Unless your delivery pipeline is really good, in order to promote artificial operator versions to include the promotion logic is very cumbersome. It didn't work for us at all. We therefore could not follow this model.
  2. It would be worthwhile to highlight that FBC completely solves the promotion problem, making this model totally realistic.
  3. It makes more sense to me to flip the channel names to <version>-<frequency (e.g. v1-candidate), so like-versions are lexicographically sorted together.
  4. Our customers REALLY want to control the risk of upgrades. That's why we introduced vX.Y and stable-only (no frequency). With FBC this is opening the door for all sorts of much more interesting patterns, and hence why my hackmd.io doc is there....
camilamacedo86 commented 2 years ago

Hi @cdjohnson,

Thank you for reaching out. Regards your comment https://github.com/operator-framework/olm-docs/pull/232#issuecomment-1100098507

It seems like you are trying to add here what would be possible to achieve in the future with FBC. That is not the goal of this PR and is out of its scope. The goal of this PR is clarified in the description. See the delta, for now. We only are looking to ensure that it has the examples and required additions discussed so far.

The channel naming doc described the limitations with channel promotion before FBC already. It is something that will be addressed with FBC and one of its motivations, but here we are not there yet.

See, we have no intention to discuss or cover any possible future possibility with FBC in this PR. It is 100% out of the scope of this PR.

Regards:

  1. It makes more sense to me to flip the channel names to -<frequency (e.g. v1-candidate), so like-versions are lexicographically sorted together.

candidate-v1, candidate-v2, candidate-v3 will also sort out the versions and group by the maturity such as it is done for example, Openshift release channels. So, it is hard to make everybody happy with any convention since each person might have their preferences. However, discussing the possibility to change it is also out of the scope of this PR.

Regards:

  1. Our customers REALLY want to control the risk of upgrades. That's why we introduced vX.Y and stable-only (no frequency).

If you want to let the customers really control the risk, it will make more sense to provide them with the candidate and fast channels with the MAJOR.MINOR versions so that they are aware of the risks for these maturity levels of releases. I am not sure how to suggest using MAJOR.MINOR versions in the channel names would go against your goal. That seems the other way around.

However, your approach to using major and minor versions only for stable channel names does not seem to hurt the convention proposed here at all. It mainly asks authors to use the names/terminology stable/fast/candidate and stick with them. The first example provided here does not use MAJOR.MINOR versions.

The usage of MAJOR.MINOR versions are recommended to be used in the channel names to provide this info to cluster admins and go along with your requirement "Our customers REALLY want to control the risk of upgrades."

With FBC, this is opening the door for all sorts of much more interesting patterns, and hence why my hackmd.io doc is there...

Address the possibilities with FBC is not the goal of this PR, and it is out of the scope here.

anik120 commented 2 years ago

/test/link(pull_request) override since a link in the contribution guideline doc is failing and this PR does not touch that doc, and has gone through enough churn. We can fix that issue in another PR.

/lgtm /approve

openshift-ci[bot] commented 2 years ago

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: anik120, camilamacedo86

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/operator-framework/olm-docs/blob/master/OWNERS)~~ [anik120] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment