-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PROPOSAL] Seperate the operator helm chart release with the actual operator release #830
Comments
Adding @dbason @swoehrl-mw @jochenkressin @pchmielnik @salyh @bbarani @getsaurabh02 @evheniyt to please take a look and share your thoughts. |
I think it's pretty clear that the release process of operator, and helm charts (both operator and cluster) should be separated. I think the main topic to discuss is versioning. In operator-helm we have In cluster-helm for Another question is how to track/match operator-helm and cluster-helm |
One thing to keep in mind here are CRD changes in the operator chart. In the current process updates to the CRD yamls are added to the chart in the PR the changes are introduced. But if the operator chart release process is separate this can lead to problems if the chart is released with a changed CRD that the operator image does not yet support. My opinion here is: Keep version and release process for the operator and operator helm chart in sync as is now, but decouple the release and version of the opensearch-cluster helm chart to allow faster pace there.
I like the first option: use the operator version as appVersion in the cluster chart to signal with which operator version it is compatible. We should keep the opensearch version out of there as both operator and chart support multiple and also older opensearch versions. |
What/Why
What are you proposing?
Have have a seperate release cadence for operator helm chart. Example here is an open PR for a bug fix in helm chart #826, even though this is reviewed and merged, this wont be released until the next version of the operator release.
What problems are you trying to solve?
Currently, the release process for the operator helm charts is tightly coupled with the release of the operator, decouple the release cycles of helm charts and operator to allow independent and fast paced updates. Have a seperate version management to the helm charts.
What is the user and developer experience going to be?
The developers and users will have more control over the helm charts development and releases, having this a user/developer need not wait until the release of the operator to have an helm chart release. This improves and gives more control in fixing the bugs and improving the helm charts periodically.
Are there any security considerations?
No
Are there any breaking changes to the API
No
Are there breaking changes to the User Experience?
No
Why should it be built? Any reason not to?
The operator is mostly installed/used by the hem charts, having to implement this will have the following advantages
Faster Release Cycle: Helm chart updates can be released as soon as they are ready, without waiting for the next operator release cycle.
Increased Flexibility: Helm charts can be patched and improved independently, allowing quicker responses to bugs and user feedback.
Simplified Versioning: Separate versioning schemes for Helm charts and operators will make it easier to manage and ensure compatibility.
What will it take to execute?
There is already an open PR #754 contributed by @evheniyt review and merge this. Seperate the release process in https://github.com/opensearch-project/opensearch-k8s-operator/blob/main/.github/workflows/release.yaml, define the versioning and release process of helm charts. We can re-use some of the release workflows from the OpenSearch helm repo https://github.com/opensearch-project/helm-charts/blob/main/.github/workflows/release.yaml.
The helm release should be from the
version
inChart.yaml
,version
inChart.yaml
(follow the SemVer)CHANGELOG.md
.version
inChart.yaml
and do a helm release.Note: Even though the logic to seperate the operator helm chart release with the actual operator release is needed, there should be an automation and mechanism to have a operator helm chart release soon after the the main operator release, this is to ensure the CRD's and other new files are synced that are part of the operator release.
Any remaining open questions?
N/A
The text was updated successfully, but these errors were encountered: