| Re: [tractusx-dev] Discussion / Suggestion: Alignment of Helm Chart Versions with App Versions |
|
Hey list, hey Roman, This reads somehow like questioning the lived practice in the use of Helm Charts, although I can understand the reasons behind this. I won’t agree to force each Eclipse-Tractus-X component/product
to align their Helm Chart version with its application version. There are already a few components which follow this approach, but following this approach requires a high discipline in the (GH not Catena-X) release process. I would also tent to disagree that Helm Chart of a certain component is part of the service or product. It’s an offer/possibility how you can install and operate it but it’s not a recommendation.
Of course, it is much easier to use Helm to install a component than doing it manually. That’s the reason why Helm was invented
😊 When using Helm Charts then you must get used to deal with the Helm Chart version and the appVersion. Many Helm Charts have differences in this version information, some examples: $ helm search repo grafana/grafana --versions NAME CHART VERSION APP VERSION DESCRIPTION grafana/grafana 6.57.3 9.5.3 The leading tool for querying and visualizing t... grafana/grafana 6.57.2 9.5.3 The leading tool for querying and visualizing t... grafana/grafana 6.57.1 9.5.3 The leading tool for querying and visualizing t... grafana/grafana 6.57.0 9.5.2 The leading tool for querying and visualizing t... grafana/grafana 6.56.6 9.5.2 The leading tool for querying and visualizing t... $ helm search repo bitnami/postgresql --versions NAME CHART VERSION APP VERSION DESCRIPTION bitnami/postgresql 12.5.8 15.3.0 PostgreSQL (Postgres) is an open source object-... bitnami/postgresql 12.5.7 15.3.0 PostgreSQL (Postgres) is an open source object-... bitnami/postgresql 12.5.6 15.3.0 PostgreSQL (Postgres) is an open source object-... bitnami/postgresql 12.5.5 15.3.0 PostgreSQL (Postgres) is an open source object-... bitnami/postgresql 12.5.4 15.3.0 PostgreSQL (Postgres) is an open source object-... $ helm search repo ingress-nginx --versions NAME CHART VERSION APP VERSION DESCRIPTION ingress-nginx/ingress-nginx 4.7.0 1.8.0 Ingress controller for Kubernetes using NGINX a... ingress-nginx/ingress-nginx 4.6.1 1.7.1 Ingress controller for Kubernetes using NGINX a... ingress-nginx/ingress-nginx 4.6.0 1.7.0 Ingress controller for Kubernetes using NGINX a... ingress-nginx/ingress-nginx 4.5.2 1.6.4 Ingress controller for Kubernetes using NGINX a... ingress-nginx/ingress-nginx 4.5.0 1.6.3 Ingress controller for Kubernetes using NGINX a... $ helm search repo argo/argo-cd --versions NAME CHART VERSION APP VERSION DESCRIPTION argo/argo-cd 5.36.2 v2.7.5 A Helm chart for Argo CD, a declarative, GitOps... argo/argo-cd 5.36.1 v2.7.4 A Helm chart for Argo CD, a declarative, GitOps... argo/argo-cd 5.36.0 v2.7.4 A Helm chart for Argo CD, a declarative, GitOps... argo/argo-cd 5.35.1 v2.7.4 A Helm chart for Argo CD, a declarative, GitOps... argo/argo-cd 5.35.0 v2.7.3 A Helm chart for Argo CD, a declarative, GitOps... The Helm Chart version will be increased, whenever the chart itself gets changed. Bumping the application version because of the changes of the Helm Chart, without any change in the
application itself, would counteract the meaning of the version number of the application. And what would you write to the applications Changelog? That the Helm Chart, which is not a part of the application itself, has changed? I do not agree.
To what I could agree to is, that the developers should have clear rules when to bump which part of the version (major, minor, patch) of their Helm chart. If the teams align version
numbers out of intrinsic motivation, I have no problem with that. I disagree with making this a requirement. Also, in terms of sustainability we should not waste resources to start the build process with all its consequences just to bump the appVersion without any changes to the code to get
the same binary/container image/etc., but with a different version number. In my opinion, the discussion came up because of the lack of experience with Helm Charts. Which is not an issue, and to be honest, I had the same problems when my journey with Helm began.
But once you understand it, it's not that hard. As with all tools, you’ve to understand its concepts. Cheers Carsten -- Mit freundlichen Grüßen / Kind regards Carsten Lenz Senior Reliability Engineer Mercedes-Benz Tech Innovation (ehemals/formely Daimler TSS) Digital Value Platforms Wilhelm-Runge-Straße 11 89081 Ulm/Germany carsten.lenz@xxxxxxxxxxxxxxxxx www.mercedes-benz-techinnovation.com
Mercedes Benz Tech Innovation GmbH Sitz und Registergericht/Domicile and Register Court: Ulm, HRB-Nr./Commercial Register No.: 3844 Geschäftsführung/Management: Daniel Geisel (Vorsitzender/Chairperson), Isabelle Krautwald Von: tractusx-dev <tractusx-dev-bounces@xxxxxxxxxxx> im Auftrag von Roman Werner <roman.werner@xxxxxxxxxxxxxx> [**EXTERNAL E-MAIL**]
Hello all, sorry for the late feedback on the topic "Alignment of Helm Chart Versions with App Versions" although we have raised the point initially. The advantages we would see, especially from our point of view that we
have to run these components productively as
Cofintiy-X, would be the following:
I am happy to receive feedback. Thank you very much! Cheers Roman Mit freundlichen Grüßen/Kind regards Roman Werner Product Lead Core Services & EDC | Enterprise Architect Cofinity-X GmbH
│c/o Im Mediapark 5
│50670 Köln E :
roman.werner@xxxxxxxxxxxxxx M : +49 160 7841129
Mandatory Disclosure Statement:
www.cofinity-x.com/impressum This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby
notified, that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. From: tractusx-dev <tractusx-dev-bounces@xxxxxxxxxxx>
On Behalf Of sebastian.bezold--- via tractusx-dev Hi all, while I can understand, that tracking this many components that we have in App version and Chart version might be overwhelming in the beginning, I think forcefully aligning them is not the solution.
In my opinion, the table in our Release Changelog that maps the two versions is good enough. I would like to keep the option to just release the Chart without creating a new App version. We have seen fixes and improvements to Charts in the past, that did not require any change to the application itself. So it was ok to just bump
the Chart version and keep the app version. If we would be required to align the versions, we also would need to create a new app release. This would mean, like Mathias already mentioned, creating new tags and releases. Like I said at the beginning, I think the release table does a good enough job and we do not need the require alignment via release guideline. Cheers Sebastian Von:
tractusx-dev <tractusx-dev-bounces@xxxxxxxxxxx>
im Auftrag
von "Brunkow Moser, Mathias via
tractusx-dev" <tractusx-dev@xxxxxxxxxxx> [**EXTERNAL E-MAIL**]
Hi Sigi! I will give my honest opinion also. I find a good idea in general to align the helm chart versions and the app versions, because when you configure the helm charts is more easy since you don’t need to search for it where is the latest version of the chart or which is the
specific version. However I believe that in this case we are forcing that every time we push to the tractus-x main we need to create an application version tag. This does not allows us to have many small merges related to one version for later creating a
release tag. This also means that the app version needs to be incremented always when the chart version is incremented. However it can be the case that just a chart configuration change was necessary and it was independent from the application changes
which are in another version. I hope it could help, Best Regards,
Mathias Brunkow Moser | Software Engineer Consultant Industry 4.0, IoT & Catena-X
|
CGI Deutschland B.V. & Co. KG Leitzstraße, 45 | 70467 Stuttgart, Germany
M: + 49 1525 6723056
mathias.brunkowmoser@xxxxxxx
|
www.cgi.com/de/de CONFIDENTIALITY NOTICE: Proprietary/Confidential Information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient
indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such
case, you should destroy this message and are asked to notify the sender by reply e-mail. Von: tractusx-dev <tractusx-dev-bounces@xxxxxxxxxxx>
Im Auftrag von Kiermayer, Siegfried via tractusx-dev
Hi everyone! Holidays are probably over and I would like to “remind” you about this discussion, but I would also like to add the following screenshot to show you how it looks to people outside: <see attachment> Tx, Sigi From:
Kiermayer, Siegfried <siegfried.kiermayer@xxxxxxx> Hi everyone! We need to talk about Helm charts and versioning of them in connection with app versions: You have probably seen that we have released 3.1 of Eclipse Tractus-X; You might also have seen how this looks in our Changelog:
https://github.com/eclipse-tractusx/tractus-x-release/blob/main/CHANGELOG.md
. Confusing I would say. It’s a big wide table with different versions and a lot of potential for confusions, wrong versions etc. I haven’t suggested any TRG like “Alignment of Helm chart version with App Version” regarding this alignment before because I did not had any practical experience with this particular issue. Also when you look at other Helm charts, especially
the quite often used bitnami postgresql helm chart, they do diverge. BUT! My current assumption is that bitnami Helm charts diverge primarily because those helm charts are build by bitnami and others for other products like postgresql. I see following advantages and disadvantages: Advantages:
Disadvantages:
Overall, I do personally think it would be much easier and more stable to combine your frontend/backend code in one repository and have your helm chart also in the same spot. This would guarantee that you release holistically. The complexity
of combining multiply code projects is reduced on GitHub through path filters:
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore
with this you are easily able to do certain things like backend/frontend tests etc. only when your frontend or backend has changed. Please bring up your points (upsides, downsides), your experience with it and everything else to make it easier for the Eclipse Project Leads to decide if this is something we should or should not make mandatory. At the current point there is no TRG planed, if this is a controversial topic, a TRG might be introduced which is optional but suggests one specific strategy. Thanks, Sigi
|
