Adding @swoehrl-mw and @evheniyt to please take a look, once this is merged we can move forward with this PR #754 to refactor opensearch-cluster helm chart.

Once this PR is merged the idea is to rebase this PR #754, update the version and merge to main, then the helm/chart-releaser-action will take care of releasing the helm chart.

Thank you
@getsaurabh02 @peterzhuamazon

So basically helm will always be latest HEAD? While operator official release will be stable ones?

Thanks.

Thanks Peter, the operator when released creates the docker image and other helm charts (part of the seperate releases) uses this operator version from appVersion.

It is the same mechanism that we use today for OpenSearch helm charts opensearch-project/helm-charts#569 where the appVersion is the OpenSearch version.

With this new release process we run a huge risk of releasing features in the chart that are not yet included in the operator code if someone makes a non-related change in the chart and wants to release that by increasing the version. This will only lead to problems.
So IMO the release and version of the operator chart should stay coupled with the operator release.

Thanks, @swoehrl-mw. I agree with your point, but I believe the maintainers are responsible for reviewing PRs and Helm chart changes. For example, in this PR #754, the change involved the opensearch-cluster, and the maintainers should be aware of code modifications made to the opensearch-operator Helm chart and decide if the chart version needs to be incremented.

This PR aims to standardize the Helm release process for both opensearch-cluster and opensearch-operator Helm charts, which would only require a version increment, and the workflow would handle the release. The timing and coordination of version increments should be managed by the PR authors and maintainers to ensure smooth chart releases.

In some cases, like a critical/small fix, we may need to release the opensearch-operator Helm chart independently, without waiting for the opensearch-operator release and this process (by this PR) should be helpful and unblock the chart release.

Thank you
Adding @getsaurabh02 @salyh @pchmielnik @jochenkressin @dblock @peterzhuamazon

@prudhvigodithi
I still think this will lead to problems, to be honest I don't think we have the best track record there with keeping stability and thoroughly checking PRs.

IMO it is the lesser evil to have different release processes than making it easy to break things.

In some cases, like a critical/small fix, we may need to release the opensearch-operator Helm chart independently, without waiting for the opensearch-operator release and this process (by this PR) should be helpful and unblock the chart release.

Should this actually happen of doing a release of the opeator+chart without code changes, that is not really an argument for me.

@swoehrl-mw any other suggestions on how to move forward with this PR #754 without decoupling the releases?

that is not really an argument for me.

Again we cant release an operator for every small change in the helm chart (and helm chart should not wait until the operator is released), IMO its totally worth to decouple both the 2 products, the operator and the helm chart.

Following, @swoehrl-mw can you please suggest the next steps here? I want to Decouple Helm Release with the Operator Release because of #872 (comment) and unblock the PR #754.
Thank you
@getsaurabh02 @peterzhuamazon

@prudhvigodithi I would suggest to have the opensearch-cluster helm chart with the release process as you suggest it in this PR and have operator docker + opensearch-operatorhelm chart with the release process as it is currently. That way #754 would be unblocked. Releases for the operator chart would still be slow, but as I said in an earlier comment that chart is tightly coupled with operator features so they should really be released only together.