)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":5890,"name":"Doug Goldstein","email":"cardoe@cardoe.com","username":"cardoe"},"change_message_id":"389acc9e093e2b0c0142538e73b90d4b5b563d53","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":10,"id":"f8f9ee4e_9f4c77db","updated":"2024-11-21 19:06:39.000000000","message":"I’ll +1 on the condition that we look at usage and pain points after a few PTG cycles. maybe I’m being too cautious and","commit_id":"c7326e462593e3f475f3a0b777521968387a7fde"},{"author":{"_account_id":5890,"name":"Doug Goldstein","email":"cardoe@cardoe.com","username":"cardoe"},"change_message_id":"6a2975392c214a4d34307ac47fa717ab67a3876c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":10,"id":"7a0cbfea_37f40a0d","updated":"2024-11-20 20:59:00.000000000","message":"This will achieve the goal of immutable tarballs so I\u0027m good with it if Vasyl is.","commit_id":"c7326e462593e3f475f3a0b777521968387a7fde"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"02b46889a51d3c3aff9d9e591e842cf402362d45","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":10,"id":"d0ec0a2f_e6445b6b","updated":"2024-11-21 14:19:16.000000000","message":"looks good for me, thanks for updates.","commit_id":"c7326e462593e3f475f3a0b777521968387a7fde"}],"doc/source/specs/2025.1/chart_versioning.rst":[{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"749292fbb6847bad7f2cc5368264f5203af9269f","unresolved":true,"context_lines":[{"line_number":7,"context_line":""},{"line_number":8,"context_line":"There are issues:"},{"line_number":9,"context_line":""},{"line_number":10,"context_line":"* All Openstack-Helm charts depend on the helm-toolkit subchart, but"},{"line_number":11,"context_line":"  the helm-toolkit version is not pinned. When helm-toolkit is updated,"},{"line_number":12,"context_line":"  we don\u0027t bump the version of the charts that depend on it and re-publish"},{"line_number":13,"context_line":"  them. This can change the behavior of the charts while the version of the"},{"line_number":14,"context_line":"  chart tarball remains unchanged."},{"line_number":15,"context_line":"* We use `chart-testing`_ to lint the charts. The chart-testing tool"},{"line_number":16,"context_line":"  requires that the chart version is bumped every time any file in the"},{"line_number":17,"context_line":"  chart directory is changed. In every chart, we have a `values_overrides`"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5ca289ae_5c7cfddb","line":14,"range":{"start_line":10,"start_character":0,"end_line":14,"end_character":34},"updated":"2024-11-06 07:23:25.000000000","message":"Why we have 2 repositories with charts openstack-helm and openstack-helm-infra? Dropping openstack-helm-infra and moving all infra charts into openstack-helm/infra directory will solve all dependency problems. Since we building all charts we may set in dependency relative path, by doing this cloning single repo provides correct state among all charts.","commit_id":"21ee50c2595328145fddf77ab2940fa170222cea"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"c036a4921bf2a3ed3cc1329aca965d53b8e757a0","unresolved":false,"context_lines":[{"line_number":7,"context_line":""},{"line_number":8,"context_line":"There are issues:"},{"line_number":9,"context_line":""},{"line_number":10,"context_line":"* All Openstack-Helm charts depend on the helm-toolkit subchart, but"},{"line_number":11,"context_line":"  the helm-toolkit version is not pinned. When helm-toolkit is updated,"},{"line_number":12,"context_line":"  we don\u0027t bump the version of the charts that depend on it and re-publish"},{"line_number":13,"context_line":"  them. This can change the behavior of the charts while the version of the"},{"line_number":14,"context_line":"  chart tarball remains unchanged."},{"line_number":15,"context_line":"* We use `chart-testing`_ to lint the charts. The chart-testing tool"},{"line_number":16,"context_line":"  requires that the chart version is bumped every time any file in the"},{"line_number":17,"context_line":"  chart directory is changed. In every chart, we have a `values_overrides`"}],"source_content_type":"text/x-rst","patch_set":2,"id":"0e700709_a4e74f06","line":14,"range":{"start_line":10,"start_character":0,"end_line":14,"end_character":34},"in_reply_to":"012632ba_59393490","updated":"2024-11-07 17:30:04.000000000","message":"This is another story not related to the spec. All the charts have helm-toolkit as a dependency. When you change the helm-toolkit you have to bump the chart (published) that depends on it. Helm is a packaging solution, right? Helm users are not git users and they are not even expected to know about openstack-helm git repos. \n\n```\nhelm repo add openstack-helm https://tarballs.opendev.org/openstack/openstack-helm\nhelm upgrade --install keystone openstack-helm/keystone\n```\n\nYou are talking about putting all charts to the same git repo and completely forget about their versions. Users just clone the git repo and use charts in place (build and assign any version). Some users can do this now, no problem at all. When we change helm-toolkit we test other charts with the change. But there is another group of users who just want to deploy Openstack using helm command.\n\nI am closing this thread because we are talking about different use cases.","commit_id":"21ee50c2595328145fddf77ab2940fa170222cea"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"d03f21362e43a83d98b67c8681cf49fb39e91634","unresolved":true,"context_lines":[{"line_number":7,"context_line":""},{"line_number":8,"context_line":"There are issues:"},{"line_number":9,"context_line":""},{"line_number":10,"context_line":"* All Openstack-Helm charts depend on the helm-toolkit subchart, but"},{"line_number":11,"context_line":"  the helm-toolkit version is not pinned. When helm-toolkit is updated,"},{"line_number":12,"context_line":"  we don\u0027t bump the version of the charts that depend on it and re-publish"},{"line_number":13,"context_line":"  them. This can change the behavior of the charts while the version of the"},{"line_number":14,"context_line":"  chart tarball remains unchanged."},{"line_number":15,"context_line":"* We use `chart-testing`_ to lint the charts. The chart-testing tool"},{"line_number":16,"context_line":"  requires that the chart version is bumped every time any file in the"},{"line_number":17,"context_line":"  chart directory is changed. In every chart, we have a `values_overrides`"}],"source_content_type":"text/x-rst","patch_set":2,"id":"280523ae_d3a5f7b8","line":14,"range":{"start_line":10,"start_character":0,"end_line":14,"end_character":34},"in_reply_to":"0b85fb6a_2eeadf2a","updated":"2024-11-08 02:39:28.000000000","message":"Removed the part about pinning helm-toolkit.","commit_id":"21ee50c2595328145fddf77ab2940fa170222cea"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"b6c3b76e4f304855471e5a234c34df0e0b2c01d3","unresolved":false,"context_lines":[{"line_number":7,"context_line":""},{"line_number":8,"context_line":"There are issues:"},{"line_number":9,"context_line":""},{"line_number":10,"context_line":"* All Openstack-Helm charts depend on the helm-toolkit subchart, but"},{"line_number":11,"context_line":"  the helm-toolkit version is not pinned. When helm-toolkit is updated,"},{"line_number":12,"context_line":"  we don\u0027t bump the version of the charts that depend on it and re-publish"},{"line_number":13,"context_line":"  them. This can change the behavior of the charts while the version of the"},{"line_number":14,"context_line":"  chart tarball remains unchanged."},{"line_number":15,"context_line":"* We use `chart-testing`_ to lint the charts. The chart-testing tool"},{"line_number":16,"context_line":"  requires that the chart version is bumped every time any file in the"},{"line_number":17,"context_line":"  chart directory is changed. In every chart, we have a `values_overrides`"}],"source_content_type":"text/x-rst","patch_set":2,"id":"a9a49712_f790964d","line":14,"range":{"start_line":10,"start_character":0,"end_line":14,"end_character":34},"in_reply_to":"0e700709_a4e74f06","updated":"2024-11-07 19:31:34.000000000","message":"I do not think its separate story as this spec suggest to create some complicated workflow that will bump version of htk in all charts automatically L108 in this doc which is completely not needed.","commit_id":"21ee50c2595328145fddf77ab2940fa170222cea"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"8ee6e7f843661a1b95aded24e29410f9b59745bc","unresolved":true,"context_lines":[{"line_number":7,"context_line":""},{"line_number":8,"context_line":"There are issues:"},{"line_number":9,"context_line":""},{"line_number":10,"context_line":"* All Openstack-Helm charts depend on the helm-toolkit subchart, but"},{"line_number":11,"context_line":"  the helm-toolkit version is not pinned. When helm-toolkit is updated,"},{"line_number":12,"context_line":"  we don\u0027t bump the version of the charts that depend on it and re-publish"},{"line_number":13,"context_line":"  them. This can change the behavior of the charts while the version of the"},{"line_number":14,"context_line":"  chart tarball remains unchanged."},{"line_number":15,"context_line":"* We use `chart-testing`_ to lint the charts. The chart-testing tool"},{"line_number":16,"context_line":"  requires that the chart version is bumped every time any file in the"},{"line_number":17,"context_line":"  chart directory is changed. In every chart, we have a `values_overrides`"}],"source_content_type":"text/x-rst","patch_set":2,"id":"db65a30f_331b828b","line":14,"range":{"start_line":10,"start_character":0,"end_line":14,"end_character":34},"in_reply_to":"280523ae_d3a5f7b8","updated":"2024-11-11 13:40:01.000000000","message":"can we add this option - merge openstack-helm and openstack-helm-infra in single repository as an option","commit_id":"21ee50c2595328145fddf77ab2940fa170222cea"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"af04e9952cc24efedead4ed5da9a667fe266161c","unresolved":true,"context_lines":[{"line_number":7,"context_line":""},{"line_number":8,"context_line":"There are issues:"},{"line_number":9,"context_line":""},{"line_number":10,"context_line":"* All Openstack-Helm charts depend on the helm-toolkit subchart, but"},{"line_number":11,"context_line":"  the helm-toolkit version is not pinned. When helm-toolkit is updated,"},{"line_number":12,"context_line":"  we don\u0027t bump the version of the charts that depend on it and re-publish"},{"line_number":13,"context_line":"  them. This can change the behavior of the charts while the version of the"},{"line_number":14,"context_line":"  chart tarball remains unchanged."},{"line_number":15,"context_line":"* We use `chart-testing`_ to lint the charts. The chart-testing tool"},{"line_number":16,"context_line":"  requires that the chart version is bumped every time any file in the"},{"line_number":17,"context_line":"  chart directory is changed. In every chart, we have a `values_overrides`"}],"source_content_type":"text/x-rst","patch_set":2,"id":"695cee32_142a3fed","line":14,"range":{"start_line":10,"start_character":0,"end_line":14,"end_character":34},"in_reply_to":"5ca289ae_5c7cfddb","updated":"2024-11-07 02:52:45.000000000","message":"At some point we had 1 repo and then for some reasons it was decided to split them. This is legacy. Anyway putting everything into a single git repo does not solve the versioning problem. \n\nWe used to consider git repos as our main deliverables but this contradicts with the very sense of helm as a packaging system. Some users can still use helm charts from the git repos and build them and assign any versions they want. On the other hand we build charts and publish them as binary artifacts. And we have to be careful with their versions.\n\nWhen we rebuild the chart with the newer library version we have to update the chart version and publish a new artifact. This is not so important for some simple ad-hoc deployments but some users rely on these versions and expect the binary of a particular version is not changed at any time in the future.","commit_id":"21ee50c2595328145fddf77ab2940fa170222cea"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"b9f2b3dd3bb507770d99d273e8b487f213b54e73","unresolved":true,"context_lines":[{"line_number":7,"context_line":""},{"line_number":8,"context_line":"There are issues:"},{"line_number":9,"context_line":""},{"line_number":10,"context_line":"* All Openstack-Helm charts depend on the helm-toolkit subchart, but"},{"line_number":11,"context_line":"  the helm-toolkit version is not pinned. When helm-toolkit is updated,"},{"line_number":12,"context_line":"  we don\u0027t bump the version of the charts that depend on it and re-publish"},{"line_number":13,"context_line":"  them. This can change the behavior of the charts while the version of the"},{"line_number":14,"context_line":"  chart tarball remains unchanged."},{"line_number":15,"context_line":"* We use `chart-testing`_ to lint the charts. The chart-testing tool"},{"line_number":16,"context_line":"  requires that the chart version is bumped every time any file in the"},{"line_number":17,"context_line":"  chart directory is changed. In every chart, we have a `values_overrides`"}],"source_content_type":"text/x-rst","patch_set":2,"id":"012632ba_59393490","line":14,"range":{"start_line":10,"start_character":0,"end_line":14,"end_character":34},"in_reply_to":"695cee32_142a3fed","updated":"2024-11-07 10:28:44.000000000","message":"Having single repo allows to have consistent helm-toolkit dependency in all charts without any extra work. There is no any benefits on having charts split between different repos. If we want to split charts logically we still can keep them in different folders. This approach will be much easier to implement, no need of extra automated jobs that do bumps etc, you clone single repo and know the exact state. Lets try to find a valid reason why charts were split between repos maybe I\u0027m missing something","commit_id":"21ee50c2595328145fddf77ab2940fa170222cea"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"4b059210a095146373762f238997b0729550bc0d","unresolved":false,"context_lines":[{"line_number":7,"context_line":""},{"line_number":8,"context_line":"There are issues:"},{"line_number":9,"context_line":""},{"line_number":10,"context_line":"* All Openstack-Helm charts depend on the helm-toolkit subchart, but"},{"line_number":11,"context_line":"  the helm-toolkit version is not pinned. When helm-toolkit is updated,"},{"line_number":12,"context_line":"  we don\u0027t bump the version of the charts that depend on it and re-publish"},{"line_number":13,"context_line":"  them. This can change the behavior of the charts while the version of the"},{"line_number":14,"context_line":"  chart tarball remains unchanged."},{"line_number":15,"context_line":"* We use `chart-testing`_ to lint the charts. The chart-testing tool"},{"line_number":16,"context_line":"  requires that the chart version is bumped every time any file in the"},{"line_number":17,"context_line":"  chart directory is changed. In every chart, we have a `values_overrides`"}],"source_content_type":"text/x-rst","patch_set":2,"id":"0b85fb6a_2eeadf2a","line":14,"range":{"start_line":10,"start_character":0,"end_line":14,"end_character":34},"in_reply_to":"a9a49712_f790964d","updated":"2024-11-07 21:46:38.000000000","message":"I am going to suggest another approach w/o pinning htk.","commit_id":"21ee50c2595328145fddf77ab2940fa170222cea"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"c73e1fa4db6a1820f636557a60c2353d78e0a702","unresolved":true,"context_lines":[{"line_number":7,"context_line":""},{"line_number":8,"context_line":"There are issues:"},{"line_number":9,"context_line":""},{"line_number":10,"context_line":"* All Openstack-Helm charts depend on the helm-toolkit subchart, but"},{"line_number":11,"context_line":"  the helm-toolkit version is not pinned. When helm-toolkit is updated,"},{"line_number":12,"context_line":"  we don\u0027t bump the version of the charts that depend on it and re-publish"},{"line_number":13,"context_line":"  them. This can change the behavior of the charts while the version of the"},{"line_number":14,"context_line":"  chart tarball remains unchanged."},{"line_number":15,"context_line":"* We use `chart-testing`_ to lint the charts. The chart-testing tool"},{"line_number":16,"context_line":"  requires that the chart version is bumped every time any file in the"},{"line_number":17,"context_line":"  chart directory is changed. In every chart, we have a `values_overrides`"}],"source_content_type":"text/x-rst","patch_set":2,"id":"e8b63d7c_b90c3e4d","line":14,"range":{"start_line":10,"start_character":0,"end_line":14,"end_character":34},"in_reply_to":"db65a30f_331b828b","updated":"2024-11-13 02:54:34.000000000","message":"Let\u0027s discuss this later in a separate spec. This could be tricky because some users have their CI/CDs relying on two OSH git repos.","commit_id":"21ee50c2595328145fddf77ab2940fa170222cea"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"749292fbb6847bad7f2cc5368264f5203af9269f","unresolved":true,"context_lines":[{"line_number":32,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"We propose to do the following:"},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"* Move values overrides to a separate directory."},{"line_number":37,"context_line":"* Use `apiVersion: v2` in `Chart.yaml`."},{"line_number":38,"context_line":"* Move release notes to the CHANGELOG.md files."},{"line_number":39,"context_line":"* Once the Openstack is released we will bump the version of all charts to"},{"line_number":40,"context_line":"  this new release, for example `2025.1.0`."},{"line_number":41,"context_line":"  Semver assumes the following:"},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"    * MAJOR version when you make incompatible API changes"},{"line_number":44,"context_line":"    * MINOR version when you add functionality in a backward compatible manner"}],"source_content_type":"text/x-rst","patch_set":2,"id":"15693c93_4a53fd73","line":41,"range":{"start_line":35,"start_character":0,"end_line":41,"end_character":31},"updated":"2024-11-06 07:23:25.000000000","message":"The versioning is highly tied to the allowed scope changes. What are the pans for changes in public API (helm chart values structures?) how they will be reflected with suggested versioning? What are the rules for deprecation of data structures or features that we want to drop?","commit_id":"21ee50c2595328145fddf77ab2940fa170222cea"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"400122af72e441c3473b0639f3166d88c12ec5f9","unresolved":false,"context_lines":[{"line_number":32,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"We propose to do the following:"},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"* Move values overrides to a separate directory."},{"line_number":37,"context_line":"* Use `apiVersion: v2` in `Chart.yaml`."},{"line_number":38,"context_line":"* Move release notes to the CHANGELOG.md files."},{"line_number":39,"context_line":"* Once the Openstack is released we will bump the version of all charts to"},{"line_number":40,"context_line":"  this new release, for example `2025.1.0`."},{"line_number":41,"context_line":"  Semver assumes the following:"},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"    * MAJOR version when you make incompatible API changes"},{"line_number":44,"context_line":"    * MINOR version when you add functionality in a backward compatible manner"}],"source_content_type":"text/x-rst","patch_set":2,"id":"cda0c8d2_299679c1","line":41,"range":{"start_line":35,"start_character":0,"end_line":41,"end_character":31},"in_reply_to":"042bfaec_c7482ab6","updated":"2024-11-08 14:26:35.000000000","message":"Acknowledged","commit_id":"21ee50c2595328145fddf77ab2940fa170222cea"},{"author":{"_account_id":5890,"name":"Doug Goldstein","email":"cardoe@cardoe.com","username":"cardoe"},"change_message_id":"d1991f932ce67adfbc15faf3190967e7baba8c14","unresolved":true,"context_lines":[{"line_number":32,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"We propose to do the following:"},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"* Move values overrides to a separate directory."},{"line_number":37,"context_line":"* Use `apiVersion: v2` in `Chart.yaml`."},{"line_number":38,"context_line":"* Move release notes to the CHANGELOG.md files."},{"line_number":39,"context_line":"* Once the Openstack is released we will bump the version of all charts to"},{"line_number":40,"context_line":"  this new release, for example `2025.1.0`."},{"line_number":41,"context_line":"  Semver assumes the following:"},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"    * MAJOR version when you make incompatible API changes"},{"line_number":44,"context_line":"    * MINOR version when you add functionality in a backward compatible manner"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bc6a34cf_0a76f9c0","line":41,"range":{"start_line":35,"start_character":0,"end_line":41,"end_character":31},"in_reply_to":"15693c93_4a53fd73","updated":"2024-11-06 23:58:09.000000000","message":"Good questions here. We do need to figure out how long something needs to remain and when it can be depreciated.","commit_id":"21ee50c2595328145fddf77ab2940fa170222cea"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"b9f2b3dd3bb507770d99d273e8b487f213b54e73","unresolved":true,"context_lines":[{"line_number":32,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"We propose to do the following:"},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"* Move values overrides to a separate directory."},{"line_number":37,"context_line":"* Use `apiVersion: v2` in `Chart.yaml`."},{"line_number":38,"context_line":"* Move release notes to the CHANGELOG.md files."},{"line_number":39,"context_line":"* Once the Openstack is released we will bump the version of all charts to"},{"line_number":40,"context_line":"  this new release, for example `2025.1.0`."},{"line_number":41,"context_line":"  Semver assumes the following:"},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"    * MAJOR version when you make incompatible API changes"},{"line_number":44,"context_line":"    * MINOR version when you add functionality in a backward compatible manner"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bb2f0cb2_fe4e6413","line":41,"range":{"start_line":35,"start_character":0,"end_line":41,"end_character":31},"in_reply_to":"757fe104_73fa965e","updated":"2024-11-07 10:28:44.000000000","message":"How we define what helm chart versions are released artifacts and what are still in developemnt state? In OpenStack we have stable branch for each release, and when ready they set tag on it. While tag is not set the code is considered as dev. Before cutting tag extra testing by component team may be done, it is very hard to run full set of tests against each patch.\n\nWhat will be the long running strategy for openstack-helm here? Will we use branches? Will we use tags to define `stable` charts? \n\nI think versioning problem should take into account deprecation and stable releases aspects, othervise if this spec is about what value use in version it does not make any sense to me.","commit_id":"21ee50c2595328145fddf77ab2940fa170222cea"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"8e3bc867f5f3ff92b2ddea4a458a18d213e43584","unresolved":true,"context_lines":[{"line_number":32,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"We propose to do the following:"},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"* Move values overrides to a separate directory."},{"line_number":37,"context_line":"* Use `apiVersion: v2` in `Chart.yaml`."},{"line_number":38,"context_line":"* Move release notes to the CHANGELOG.md files."},{"line_number":39,"context_line":"* Once the Openstack is released we will bump the version of all charts to"},{"line_number":40,"context_line":"  this new release, for example `2025.1.0`."},{"line_number":41,"context_line":"  Semver assumes the following:"},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"    * MAJOR version when you make incompatible API changes"},{"line_number":44,"context_line":"    * MINOR version when you add functionality in a backward compatible manner"}],"source_content_type":"text/x-rst","patch_set":2,"id":"042bfaec_c7482ab6","line":41,"range":{"start_line":35,"start_character":0,"end_line":41,"end_character":31},"in_reply_to":"bb2f0cb2_fe4e6413","updated":"2024-11-07 19:47:14.000000000","message":"Indeed versions/deprecation strategy can be tied to git branches/tags. At the moment we are using steaming or rolling release development model when we deliver features/bug fixes directly to the master branch and thoroughly test them with 3 most recent Openstack releases and we\u0027ve been improving our test pipelines during recent release cycles.\n\nThis spec is not about the release cycle in our development process. I would suggest to discuss having stable branches during 2025.2 PTG and let\u0027s not try to solve everything at once.\n\nIt is about helm charts versions which are more tarball versions. The spec suggests doing something similar (but not the same) to what Arch Linux does. We consider Openstack as the upstream that needs to be packaged. It is released twice a year with numbers like 2024.2. We are going to use this number plus the third digit for the chart version which is considered as OSH specific. We will increment it every time when we update the chart. \n\nBy default, we can follow the Openstack deprecation policy which suggests to support deprecated API/configuration during one year before removal. We can (and will) add helm-doc comments to all our values.yaml files and if we want to remove smth. we just add the `[Deprecated, will be removed after xxxx-xx-xx]` comment. So users have time to adopt changes. For this you don\u0027t have to utilize stable branches and tags (moreover in openinfra handling tags and branches is not trivial and usually some infra/governance stuff is involved).","commit_id":"21ee50c2595328145fddf77ab2940fa170222cea"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"af04e9952cc24efedead4ed5da9a667fe266161c","unresolved":true,"context_lines":[{"line_number":32,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"We propose to do the following:"},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"* Move values overrides to a separate directory."},{"line_number":37,"context_line":"* Use `apiVersion: v2` in `Chart.yaml`."},{"line_number":38,"context_line":"* Move release notes to the CHANGELOG.md files."},{"line_number":39,"context_line":"* Once the Openstack is released we will bump the version of all charts to"},{"line_number":40,"context_line":"  this new release, for example `2025.1.0`."},{"line_number":41,"context_line":"  Semver assumes the following:"},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"    * MAJOR version when you make incompatible API changes"},{"line_number":44,"context_line":"    * MINOR version when you add functionality in a backward compatible manner"}],"source_content_type":"text/x-rst","patch_set":2,"id":"757fe104_73fa965e","line":41,"range":{"start_line":35,"start_character":0,"end_line":41,"end_character":31},"in_reply_to":"bc6a34cf_0a76f9c0","updated":"2024-11-07 02:52:45.000000000","message":"Indeed this is a good question. I was thinking about using helm-docs style comments in all values.yaml files and values.schema.json for validating and tracking changes in the values format. However, this is a much bigger story and this spec is only about versioning.\n\nHelm itself does not give any recommendations about deprecation policy. By default it is assumed that we are obeying the Openstack deprecation policy. And so far we\u0027ve been always very careful about removal of things. When we have all values files supplied with the helm-doc comments we can add `[Deprecated]` warnings to the sections we are going to remove and after two release cycles remove them.","commit_id":"21ee50c2595328145fddf77ab2940fa170222cea"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"400122af72e441c3473b0639f3166d88c12ec5f9","unresolved":true,"context_lines":[{"line_number":107,"context_line":"Update the versioning policy"},{"line_number":108,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":109,"context_line":"* When the helm-toolkit chart is updated and tested with all other charts,"},{"line_number":110,"context_line":"  we will bump its version, rebuild it and publish the new version."},{"line_number":111,"context_line":"  All other charts will be rebuilt and re-published with this new version of"},{"line_number":112,"context_line":"  helm-toolkit (inside) but the parent chart version will not be changed `X.Y.Z`."},{"line_number":113,"context_line":"  For those users who would like to use a specific version that is guaranteed"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7e4b75b1_b11d44fa","line":110,"range":{"start_line":110,"start_character":2,"end_line":110,"end_character":26},"updated":"2024-11-08 14:26:35.000000000","message":"will this be done manually?","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"98e6858a1f89f0e05e43bacdde0d0a237a381f1a","unresolved":true,"context_lines":[{"line_number":107,"context_line":"Update the versioning policy"},{"line_number":108,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":109,"context_line":"* When the helm-toolkit chart is updated and tested with all other charts,"},{"line_number":110,"context_line":"  we will bump its version, rebuild it and publish the new version."},{"line_number":111,"context_line":"  All other charts will be rebuilt and re-published with this new version of"},{"line_number":112,"context_line":"  helm-toolkit (inside) but the parent chart version will not be changed `X.Y.Z`."},{"line_number":113,"context_line":"  For those users who would like to use a specific version that is guaranteed"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9faaeb62_605a848d","line":110,"range":{"start_line":110,"start_character":2,"end_line":110,"end_character":26},"in_reply_to":"7e4b75b1_b11d44fa","updated":"2024-11-08 16:07:04.000000000","message":"Yes, the same experience as we have now.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"400122af72e441c3473b0639f3166d88c12ec5f9","unresolved":true,"context_lines":[{"line_number":108,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":109,"context_line":"* When the helm-toolkit chart is updated and tested with all other charts,"},{"line_number":110,"context_line":"  we will bump its version, rebuild it and publish the new version."},{"line_number":111,"context_line":"  All other charts will be rebuilt and re-published with this new version of"},{"line_number":112,"context_line":"  helm-toolkit (inside) but the parent chart version will not be changed `X.Y.Z`."},{"line_number":113,"context_line":"  For those users who would like to use a specific version that is guaranteed"},{"line_number":114,"context_line":"  not to change (using `--version`) we will also rebuild and publish the charts"},{"line_number":115,"context_line":"  with the build metadata `X.Y.Z+XX.YY.ZZ`, where `XX.YY.ZZ` is the new"}],"source_content_type":"text/x-rst","patch_set":3,"id":"277fba35_f428877c","line":112,"range":{"start_line":111,"start_character":2,"end_line":112,"end_character":81},"updated":"2024-11-08 14:26:35.000000000","message":"does it mean that we will change tarball content without changing its name? By parent chart you mean nova/cinder for example, those charts that uses htk as a dependency?","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"98e6858a1f89f0e05e43bacdde0d0a237a381f1a","unresolved":true,"context_lines":[{"line_number":108,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":109,"context_line":"* When the helm-toolkit chart is updated and tested with all other charts,"},{"line_number":110,"context_line":"  we will bump its version, rebuild it and publish the new version."},{"line_number":111,"context_line":"  All other charts will be rebuilt and re-published with this new version of"},{"line_number":112,"context_line":"  helm-toolkit (inside) but the parent chart version will not be changed `X.Y.Z`."},{"line_number":113,"context_line":"  For those users who would like to use a specific version that is guaranteed"},{"line_number":114,"context_line":"  not to change (using `--version`) we will also rebuild and publish the charts"},{"line_number":115,"context_line":"  with the build metadata `X.Y.Z+XX.YY.ZZ`, where `XX.YY.ZZ` is the new"}],"source_content_type":"text/x-rst","patch_set":3,"id":"e72cddfd_f5d4b148","line":112,"range":{"start_line":111,"start_character":2,"end_line":112,"end_character":81},"in_reply_to":"277fba35_f428877c","updated":"2024-11-08 16:07:04.000000000","message":"Yes, like what we do at the moment. We rebuild nova/cinder when the htk is updated and we replace the existing chart tarball with the same version. But those users who whould like to stick to a particular nova/htk combination we will also build X.Y.Z+XX.YY.ZZ tarball, where X.Y.Z is the nova version and XX.YY.ZZ is the htk version.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"ff7f3a6c413f834a451d1a052eb35149dccea7a3","unresolved":true,"context_lines":[{"line_number":108,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":109,"context_line":"* When the helm-toolkit chart is updated and tested with all other charts,"},{"line_number":110,"context_line":"  we will bump its version, rebuild it and publish the new version."},{"line_number":111,"context_line":"  All other charts will be rebuilt and re-published with this new version of"},{"line_number":112,"context_line":"  helm-toolkit (inside) but the parent chart version will not be changed `X.Y.Z`."},{"line_number":113,"context_line":"  For those users who would like to use a specific version that is guaranteed"},{"line_number":114,"context_line":"  not to change (using `--version`) we will also rebuild and publish the charts"},{"line_number":115,"context_line":"  with the build metadata `X.Y.Z+XX.YY.ZZ`, where `XX.YY.ZZ` is the new"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ae17456c_7e2dd4b7","line":112,"range":{"start_line":111,"start_character":2,"end_line":112,"end_character":81},"in_reply_to":"4ef80bc1_06d77f06","updated":"2024-11-13 19:20:58.000000000","message":"We have to find a compromise here. Having tags/branches in Openstack is not trivial. It requires involving infra/governance repos. Gerrit is also not very friendly to hooks in build time.\n\nSo as we agreed in another thread we are going to have 2024.2.0 version which we won\u0027t bump every time when chart is updated (chart itself of library).\n\nI am trying to suggest more or less consistent and clear scheme. When a chart is updated (itself or lib) we rebuild it with commit_sha and publish. This gonna be `2024.2.0+$OSH_COMMIT_SHA_$OSHI_COMMIT_SHA`. At the same time `2024.2.0` will correspond to what we really have in Chart.yaml and this will be the current/latest/whatever version which is not guaranteed to stay the same.\n\nThose users who would like to stick to a specific binary will use `2024.2.0+$OSH_COMMIT_SHA_$OSHI_COMMIT_SHA`. Others who don\u0027t care of versions will be using this latest `2024.2.0`.\n\nYet another option here is that whenever we want to publish a new version, we take a look of what we have in the helm repo and increment the PATCH (third digit in the version number).\n\nFor example, this\n```\nhelm search repo openstack-helm/nova -l\n```\ngives us many tarballs with the most recent 2024.2.Z and we publish the new one with 2024.2.Z+1. The concern here is about potential race condition when two jobs at the same time try to publish the tarball.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":5890,"name":"Doug Goldstein","email":"cardoe@cardoe.com","username":"cardoe"},"change_message_id":"a79659669ed6f8b4d8d951e01b7fb8b224d04df5","unresolved":true,"context_lines":[{"line_number":108,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":109,"context_line":"* When the helm-toolkit chart is updated and tested with all other charts,"},{"line_number":110,"context_line":"  we will bump its version, rebuild it and publish the new version."},{"line_number":111,"context_line":"  All other charts will be rebuilt and re-published with this new version of"},{"line_number":112,"context_line":"  helm-toolkit (inside) but the parent chart version will not be changed `X.Y.Z`."},{"line_number":113,"context_line":"  For those users who would like to use a specific version that is guaranteed"},{"line_number":114,"context_line":"  not to change (using `--version`) we will also rebuild and publish the charts"},{"line_number":115,"context_line":"  with the build metadata `X.Y.Z+XX.YY.ZZ`, where `XX.YY.ZZ` is the new"}],"source_content_type":"text/x-rst","patch_set":3,"id":"c3db25fc_800a940d","line":112,"range":{"start_line":111,"start_character":2,"end_line":112,"end_character":81},"in_reply_to":"5b924c3b_9293bbc6","updated":"2024-11-15 19:04:41.000000000","message":"No they don\u0027t require a commit to the releases repo. But we can use that model. It will be hard for someone to figure out the next version to go to. I guess they\u0027ll have to browse the HTML listing and see the created/updated date is my only concern.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"8ee6e7f843661a1b95aded24e29410f9b59745bc","unresolved":true,"context_lines":[{"line_number":108,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":109,"context_line":"* When the helm-toolkit chart is updated and tested with all other charts,"},{"line_number":110,"context_line":"  we will bump its version, rebuild it and publish the new version."},{"line_number":111,"context_line":"  All other charts will be rebuilt and re-published with this new version of"},{"line_number":112,"context_line":"  helm-toolkit (inside) but the parent chart version will not be changed `X.Y.Z`."},{"line_number":113,"context_line":"  For those users who would like to use a specific version that is guaranteed"},{"line_number":114,"context_line":"  not to change (using `--version`) we will also rebuild and publish the charts"},{"line_number":115,"context_line":"  with the build metadata `X.Y.Z+XX.YY.ZZ`, where `XX.YY.ZZ` is the new"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa7c1632_c65bfa7e","line":112,"range":{"start_line":111,"start_character":2,"end_line":112,"end_character":81},"in_reply_to":"6ca53eb5_3b1757ce","updated":"2024-11-11 13:40:01.000000000","message":"Issue with immutable resources is not be tied to versions and upgrades. This will happen when some values are changed for example image that is used in the job or openstack service config option. Usually it may be fixed by removing all jobs in the namespace and resintalling all charts (or removing only specific jobs) and then installing new release. I do not think versioning spec should even count this as a problem.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":5890,"name":"Doug Goldstein","email":"cardoe@cardoe.com","username":"cardoe"},"change_message_id":"38d235156fbd351a319d8239559b2d356a78df71","unresolved":true,"context_lines":[{"line_number":108,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":109,"context_line":"* When the helm-toolkit chart is updated and tested with all other charts,"},{"line_number":110,"context_line":"  we will bump its version, rebuild it and publish the new version."},{"line_number":111,"context_line":"  All other charts will be rebuilt and re-published with this new version of"},{"line_number":112,"context_line":"  helm-toolkit (inside) but the parent chart version will not be changed `X.Y.Z`."},{"line_number":113,"context_line":"  For those users who would like to use a specific version that is guaranteed"},{"line_number":114,"context_line":"  not to change (using `--version`) we will also rebuild and publish the charts"},{"line_number":115,"context_line":"  with the build metadata `X.Y.Z+XX.YY.ZZ`, where `XX.YY.ZZ` is the new"}],"source_content_type":"text/x-rst","patch_set":3,"id":"f4b88736_cbb65447","line":112,"range":{"start_line":111,"start_character":2,"end_line":112,"end_character":81},"in_reply_to":"ae17456c_7e2dd4b7","updated":"2024-11-14 19:15:15.000000000","message":"So I spoke with the opendev maintainers and they\u0027ve pointed me to jobs triggering from git tags and how to make git tags. They\u0027ve said it\u0027s not a big deal. Using that method takes the version number out of the chart and reduces conflicts.\n\nThis is the config that fires off jobs based on tags:\nhttps://opendev.org/openstack/project-config/src/branch/master/zuul.d/pipelines.yaml#L306-L320\n\nAs far as releases and versioning this is what was suggested:\nhttps://github.com/openstack/releases/blob/7eabe5c2e6e9d8a50d970e52c49bd3866464adbb/doc/source/reference/release_models.rst#cycle-with-intermediary\nhttps://github.com/openstack/releases/blob/7eabe5c2e6e9d8a50d970e52c49bd3866464adbb/deliverables/epoxy/tempest.yaml#L4-L7","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"f8545b3de80db21d94467485e6cb1ce22548ba41","unresolved":true,"context_lines":[{"line_number":108,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":109,"context_line":"* When the helm-toolkit chart is updated and tested with all other charts,"},{"line_number":110,"context_line":"  we will bump its version, rebuild it and publish the new version."},{"line_number":111,"context_line":"  All other charts will be rebuilt and re-published with this new version of"},{"line_number":112,"context_line":"  helm-toolkit (inside) but the parent chart version will not be changed `X.Y.Z`."},{"line_number":113,"context_line":"  For those users who would like to use a specific version that is guaranteed"},{"line_number":114,"context_line":"  not to change (using `--version`) we will also rebuild and publish the charts"},{"line_number":115,"context_line":"  with the build metadata `X.Y.Z+XX.YY.ZZ`, where `XX.YY.ZZ` is the new"}],"source_content_type":"text/x-rst","patch_set":3,"id":"820f51c2_0134d351","line":112,"range":{"start_line":111,"start_character":2,"end_line":112,"end_character":81},"in_reply_to":"c3db25fc_800a940d","updated":"2024-11-15 21:02:49.000000000","message":"What if we combine two approches?\n1) figure out the latest available version using `helm search repo openstack-helm/nova -l` and increment the PATCH\n2) use commit sha as build metadata\n\nEventually we\u0027ll have (commit sha build metadata will be different for all the tarballs)\n```\n2024.2.X+$OSH_COMMIT_SHA_$OSHI_COMMIT_SHA\n2024.2.\u003cX+1\u003e+$OSH_COMMIT_SHA_$OSHI_COMMIT_SHA\n2024.2.\u003cX+2\u003e+$OSH_COMMIT_SHA_$OSHI_COMMIT_SHA\n...\n```\n\nThis gonna give the hint to users which tarball is the latest. \n\nThose race conditions when two jobs publish tarballs with the same version will be rare (building a tarball usually takes just a second). But still I assume we could eventually encounter the case when we have two tarballs with the same version X.Y.Z but with different build metadata.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":5890,"name":"Doug Goldstein","email":"cardoe@cardoe.com","username":"cardoe"},"change_message_id":"783ce3b921cffdd0fe81c42719d9814a6a2fecea","unresolved":true,"context_lines":[{"line_number":108,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":109,"context_line":"* When the helm-toolkit chart is updated and tested with all other charts,"},{"line_number":110,"context_line":"  we will bump its version, rebuild it and publish the new version."},{"line_number":111,"context_line":"  All other charts will be rebuilt and re-published with this new version of"},{"line_number":112,"context_line":"  helm-toolkit (inside) but the parent chart version will not be changed `X.Y.Z`."},{"line_number":113,"context_line":"  For those users who would like to use a specific version that is guaranteed"},{"line_number":114,"context_line":"  not to change (using `--version`) we will also rebuild and publish the charts"},{"line_number":115,"context_line":"  with the build metadata `X.Y.Z+XX.YY.ZZ`, where `XX.YY.ZZ` is the new"}],"source_content_type":"text/x-rst","patch_set":3,"id":"4ef80bc1_06d77f06","line":112,"range":{"start_line":111,"start_character":2,"end_line":112,"end_character":81},"in_reply_to":"c588882e_6c360fd1","updated":"2024-11-13 18:44:53.000000000","message":"That\u0027s how I\u0027ve felt, Vasyl. That\u0027s why I\u0027ve suggested some kind of automation to bump things in that case to make it easier on maintenance. See: https://github.com/argoproj/argo-helm/releases/tag/argo-cd-7.7.3 as an example. That chart was bumped because one of the internal charts it uses was bumped.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":5890,"name":"Doug Goldstein","email":"cardoe@cardoe.com","username":"cardoe"},"change_message_id":"e2cd3903845ea781865a8de22abded38c9a4630a","unresolved":true,"context_lines":[{"line_number":108,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":109,"context_line":"* When the helm-toolkit chart is updated and tested with all other charts,"},{"line_number":110,"context_line":"  we will bump its version, rebuild it and publish the new version."},{"line_number":111,"context_line":"  All other charts will be rebuilt and re-published with this new version of"},{"line_number":112,"context_line":"  helm-toolkit (inside) but the parent chart version will not be changed `X.Y.Z`."},{"line_number":113,"context_line":"  For those users who would like to use a specific version that is guaranteed"},{"line_number":114,"context_line":"  not to change (using `--version`) we will also rebuild and publish the charts"},{"line_number":115,"context_line":"  with the build metadata `X.Y.Z+XX.YY.ZZ`, where `XX.YY.ZZ` is the new"}],"source_content_type":"text/x-rst","patch_set":3,"id":"6ca53eb5_3b1757ce","line":112,"range":{"start_line":111,"start_character":2,"end_line":112,"end_character":81},"in_reply_to":"e72cddfd_f5d4b148","updated":"2024-11-08 19:09:42.000000000","message":"Is that going to work / be respected by helm repo? This automatic replacement of the tarball is what the concern was that I was bringing up during PTG. The change to the labels in htk resulted in users needing to delete some existing resources because they are immutable and cannot be upgraded. So it broke \"helm upgrade\". Some people were able to upgrade to that version and some weren\u0027t. The reason being that some people got the newer tarball and some the older.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"ccaf69125fee48d14cf75a9dbbc1ab156f557250","unresolved":true,"context_lines":[{"line_number":108,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":109,"context_line":"* When the helm-toolkit chart is updated and tested with all other charts,"},{"line_number":110,"context_line":"  we will bump its version, rebuild it and publish the new version."},{"line_number":111,"context_line":"  All other charts will be rebuilt and re-published with this new version of"},{"line_number":112,"context_line":"  helm-toolkit (inside) but the parent chart version will not be changed `X.Y.Z`."},{"line_number":113,"context_line":"  For those users who would like to use a specific version that is guaranteed"},{"line_number":114,"context_line":"  not to change (using `--version`) we will also rebuild and publish the charts"},{"line_number":115,"context_line":"  with the build metadata `X.Y.Z+XX.YY.ZZ`, where `XX.YY.ZZ` is the new"}],"source_content_type":"text/x-rst","patch_set":3,"id":"c588882e_6c360fd1","line":112,"range":{"start_line":111,"start_character":2,"end_line":112,"end_character":81},"in_reply_to":"ea5014f8_53a80689","updated":"2024-11-13 17:49:48.000000000","message":"I do not really like to replace artifacts with same version/name when only htk is changed. In production nobody will use such artefacts in the end.  IMO htk bump should be considered as a change to the chart.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"1dd23ee80ac3317de346c24c07d0b3130228f3b6","unresolved":true,"context_lines":[{"line_number":108,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":109,"context_line":"* When the helm-toolkit chart is updated and tested with all other charts,"},{"line_number":110,"context_line":"  we will bump its version, rebuild it and publish the new version."},{"line_number":111,"context_line":"  All other charts will be rebuilt and re-published with this new version of"},{"line_number":112,"context_line":"  helm-toolkit (inside) but the parent chart version will not be changed `X.Y.Z`."},{"line_number":113,"context_line":"  For those users who would like to use a specific version that is guaranteed"},{"line_number":114,"context_line":"  not to change (using `--version`) we will also rebuild and publish the charts"},{"line_number":115,"context_line":"  with the build metadata `X.Y.Z+XX.YY.ZZ`, where `XX.YY.ZZ` is the new"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5b924c3b_9293bbc6","line":112,"range":{"start_line":111,"start_character":2,"end_line":112,"end_character":81},"in_reply_to":"f4b88736_cbb65447","updated":"2024-11-15 02:45:42.000000000","message":"All these tags require commits to the releases repo, right? Maybe I am missing something. And every such commit must be approved by the release team. \n\nAnd there will be lots of such tags whenever we update any of the charts and what to pin the update to a tag. There will be like dozens of tags like 2024.2.X-nova or 2024.2.Y-neutron...\n\nWhy can not we just publish charts with `2024.2.0+$OSH_COMMIT_SHA_$OSHI_COMMIT_SHA`?","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"c73e1fa4db6a1820f636557a60c2353d78e0a702","unresolved":true,"context_lines":[{"line_number":108,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":109,"context_line":"* When the helm-toolkit chart is updated and tested with all other charts,"},{"line_number":110,"context_line":"  we will bump its version, rebuild it and publish the new version."},{"line_number":111,"context_line":"  All other charts will be rebuilt and re-published with this new version of"},{"line_number":112,"context_line":"  helm-toolkit (inside) but the parent chart version will not be changed `X.Y.Z`."},{"line_number":113,"context_line":"  For those users who would like to use a specific version that is guaranteed"},{"line_number":114,"context_line":"  not to change (using `--version`) we will also rebuild and publish the charts"},{"line_number":115,"context_line":"  with the build metadata `X.Y.Z+XX.YY.ZZ`, where `XX.YY.ZZ` is the new"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ea5014f8_53a80689","line":112,"range":{"start_line":111,"start_character":2,"end_line":112,"end_character":81},"in_reply_to":"fa7c1632_c65bfa7e","updated":"2024-11-13 02:54:34.000000000","message":"The very motivation behind the spec is to solve this tarball versioning problem. So if we are talking about tarballs then it works well when you first install `X.Y.Z+meta` and then you want to upgrade and run `helm upgrade --version X.Y.Z+othermeta`. \n\nWhen jobs are annotated with helm hook labels post-upgrade,post-install these jobs will be automatically recreated.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"479c04f651d0b3e01a7b11a526079b71ed6e7f10","unresolved":true,"context_lines":[{"line_number":118,"context_line":"* When a particular chart is changed, we will bump the version of this chart only."},{"line_number":119,"context_line":"  So all charts will be versioned independently of each other (2024.2.X where X"},{"line_number":120,"context_line":"  can be different for every chart). All the test jobs will be run with this"},{"line_number":121,"context_line":"  updated chart and with other charts taken from the public helm repository (tarballs)."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Alternatively, we could pin the helm-toolkit version in the charts, but this would"},{"line_number":124,"context_line":"make the maintenance of the charts more complicated."}],"source_content_type":"text/x-rst","patch_set":3,"id":"cf279ff9_906f32bd","line":121,"range":{"start_line":121,"start_character":2,"end_line":121,"end_character":9},"updated":"2024-11-11 13:59:03.000000000","message":"Other aspect that is related to the workflow but not reflected in this spec currently is how the version bump happening. Right now we do it manually and this leads to conflics between two patches to the same chart. Which is a stone age and prevents multiple persons to develop same chart in parallel. I would like to see that this aspect is covered somehow, maybe chart version may be detected at the build stage somehow automatically? And release notes may be generated automatically as well?","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":5890,"name":"Doug Goldstein","email":"cardoe@cardoe.com","username":"cardoe"},"change_message_id":"5b9dd62877cfabe432cdb6985befa8063052387c","unresolved":true,"context_lines":[{"line_number":118,"context_line":"* When a particular chart is changed, we will bump the version of this chart only."},{"line_number":119,"context_line":"  So all charts will be versioned independently of each other (2024.2.X where X"},{"line_number":120,"context_line":"  can be different for every chart). All the test jobs will be run with this"},{"line_number":121,"context_line":"  updated chart and with other charts taken from the public helm repository (tarballs)."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Alternatively, we could pin the helm-toolkit version in the charts, but this would"},{"line_number":124,"context_line":"make the maintenance of the charts more complicated."}],"source_content_type":"text/x-rst","patch_set":3,"id":"b08b0c78_6b71948d","line":121,"range":{"start_line":121,"start_character":2,"end_line":121,"end_character":9},"in_reply_to":"a0a55bf0_1f4adcb1","updated":"2024-11-12 02:15:43.000000000","message":"https://github.com/cardoe/openstack-helm/commit/6629425c88be6f29aa761426bb96fbc193854f07 is how I\u0027ve been doing it with GitHub Actions using tags that are \"ironic-0.3.30\" for example that would publish the ironic 0.3.30 chart.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"c73e1fa4db6a1820f636557a60c2353d78e0a702","unresolved":true,"context_lines":[{"line_number":118,"context_line":"* When a particular chart is changed, we will bump the version of this chart only."},{"line_number":119,"context_line":"  So all charts will be versioned independently of each other (2024.2.X where X"},{"line_number":120,"context_line":"  can be different for every chart). All the test jobs will be run with this"},{"line_number":121,"context_line":"  updated chart and with other charts taken from the public helm repository (tarballs)."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Alternatively, we could pin the helm-toolkit version in the charts, but this would"},{"line_number":124,"context_line":"make the maintenance of the charts more complicated."}],"source_content_type":"text/x-rst","patch_set":3,"id":"cb64049b_aa6640d9","line":121,"range":{"start_line":121,"start_character":2,"end_line":121,"end_character":9},"in_reply_to":"b08b0c78_6b71948d","updated":"2024-11-13 02:54:34.000000000","message":"So you are suggesting to disrespect the Chart.yaml version at all? \n\nWould it be ok if we use the following:\n- All charts have the same version `2024.2.0` (and updates twice a year). We will not commit any version updates other than that.\n- chart-testing linter requires version update, so we will make fake version update just to make it work.\n- Updated charts will be rebuilt with the version `2024.2.0` and with `2024.2.0+$OSH_COMMIT_SHA_$OSHI_COMMIT_SHA`\n\nLater we will discuss having all the charts in a single repo as Vasyl suggested. This will a separate spec. Once it is done, we will rebuld all the charts with the only $COMMIT_SHA build metadata.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"ccaf69125fee48d14cf75a9dbbc1ab156f557250","unresolved":true,"context_lines":[{"line_number":118,"context_line":"* When a particular chart is changed, we will bump the version of this chart only."},{"line_number":119,"context_line":"  So all charts will be versioned independently of each other (2024.2.X where X"},{"line_number":120,"context_line":"  can be different for every chart). All the test jobs will be run with this"},{"line_number":121,"context_line":"  updated chart and with other charts taken from the public helm repository (tarballs)."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Alternatively, we could pin the helm-toolkit version in the charts, but this would"},{"line_number":124,"context_line":"make the maintenance of the charts more complicated."}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfbd9220_0eb6b3e4","line":121,"range":{"start_line":121,"start_character":2,"end_line":121,"end_character":9},"in_reply_to":"cb64049b_aa6640d9","updated":"2024-11-13 17:49:48.000000000","message":"yes, for git based installations version is completely ignored. It is important only when you install from tarball. So we can actually generate version for tarball before chart build including release notes.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":5890,"name":"Doug Goldstein","email":"cardoe@cardoe.com","username":"cardoe"},"change_message_id":"777469301f489f7f79c5dd58e878042d4fa1a7a9","unresolved":true,"context_lines":[{"line_number":118,"context_line":"* When a particular chart is changed, we will bump the version of this chart only."},{"line_number":119,"context_line":"  So all charts will be versioned independently of each other (2024.2.X where X"},{"line_number":120,"context_line":"  can be different for every chart). All the test jobs will be run with this"},{"line_number":121,"context_line":"  updated chart and with other charts taken from the public helm repository (tarballs)."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Alternatively, we could pin the helm-toolkit version in the charts, but this would"},{"line_number":124,"context_line":"make the maintenance of the charts more complicated."}],"source_content_type":"text/x-rst","patch_set":3,"id":"a0a55bf0_1f4adcb1","line":121,"range":{"start_line":121,"start_character":2,"end_line":121,"end_character":9},"in_reply_to":"cf279ff9_906f32bd","updated":"2024-11-12 01:42:44.000000000","message":"we could possibly have that part automatically be changed by a bot once the merge lands. I’ll ask around for how we could do this.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":5890,"name":"Doug Goldstein","email":"cardoe@cardoe.com","username":"cardoe"},"change_message_id":"783ce3b921cffdd0fe81c42719d9814a6a2fecea","unresolved":true,"context_lines":[{"line_number":118,"context_line":"* When a particular chart is changed, we will bump the version of this chart only."},{"line_number":119,"context_line":"  So all charts will be versioned independently of each other (2024.2.X where X"},{"line_number":120,"context_line":"  can be different for every chart). All the test jobs will be run with this"},{"line_number":121,"context_line":"  updated chart and with other charts taken from the public helm repository (tarballs)."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Alternatively, we could pin the helm-toolkit version in the charts, but this would"},{"line_number":124,"context_line":"make the maintenance of the charts more complicated."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5fe5f79f_81f2e707","line":121,"range":{"start_line":121,"start_character":2,"end_line":121,"end_character":9},"in_reply_to":"dfbd9220_0eb6b3e4","updated":"2024-11-13 18:44:53.000000000","message":"Agreed Vasyl.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":5890,"name":"Doug Goldstein","email":"cardoe@cardoe.com","username":"cardoe"},"change_message_id":"e2cd3903845ea781865a8de22abded38c9a4630a","unresolved":true,"context_lines":[{"line_number":121,"context_line":"  updated chart and with other charts taken from the public helm repository (tarballs)."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Alternatively, we could pin the helm-toolkit version in the charts, but this would"},{"line_number":124,"context_line":"make the maintenance of the charts more complicated."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"Documentation Impact"},{"line_number":127,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"c036c6e5_2dd5da3c","line":124,"updated":"2024-11-08 19:09:42.000000000","message":"You could use something like renovate bot to automatically bump the version when htk gets bumped and attempt to make a release.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"c73e1fa4db6a1820f636557a60c2353d78e0a702","unresolved":true,"context_lines":[{"line_number":121,"context_line":"  updated chart and with other charts taken from the public helm repository (tarballs)."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Alternatively, we could pin the helm-toolkit version in the charts, but this would"},{"line_number":124,"context_line":"make the maintenance of the charts more complicated."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"Documentation Impact"},{"line_number":127,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ee178d1b_e0868910","line":124,"in_reply_to":"c036c6e5_2dd5da3c","updated":"2024-11-13 02:54:34.000000000","message":"There are some solutions out there and here we could even use a simple bash script. But some of the users can consider this as unnecessary complication. Let\u0027s consider not pinning htk but instead using commit sha as build metadata.","commit_id":"da4c005058cd0ea2b68089a6ab3b6706d5061cf7"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"51e211891ba4ff11affbdc73e9f8acf20897ff4e","unresolved":true,"context_lines":[{"line_number":56,"context_line":"  releases will be backward compatible."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"  We will not bump the chart version when we update it. Instead,"},{"line_number":59,"context_line":"  we will increment the PATCH automatically when building the tarball."},{"line_number":60,"context_line":"  All the tarballs will be published with the build metadata showing"},{"line_number":61,"context_line":"  the commit SHA sum with which the tarball is built. The tarball"},{"line_number":62,"context_line":"  version will look like `2025.1.X+\u003cosh_commit_sha\u003e_\u003cosh_infra_commit_sha\u003e`."}],"source_content_type":"text/x-rst","patch_set":8,"id":"f36fc008_8e0de32b","line":59,"range":{"start_line":59,"start_character":10,"end_line":59,"end_character":43},"updated":"2024-11-20 07:39:51.000000000","message":"so this X is the number of commits to the whole repo or to the chart specific directory?\n\nWill we reset X count when doing major version bump for example from 2024.1.X to 2024.1.Y how X and Y will look like?","commit_id":"e0b0f8b914269898e252d9d87efdc154dce34b3c"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"7fec107d081ec7d6e82926793f8676dd5cca5e1e","unresolved":true,"context_lines":[{"line_number":56,"context_line":"  releases will be backward compatible."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"  We will not bump the chart version when we update it. Instead,"},{"line_number":59,"context_line":"  we will increment the PATCH automatically when building the tarball."},{"line_number":60,"context_line":"  All the tarballs will be published with the build metadata showing"},{"line_number":61,"context_line":"  the commit SHA sum with which the tarball is built. The tarball"},{"line_number":62,"context_line":"  version will look like `2025.1.X+\u003cosh_commit_sha\u003e_\u003cosh_infra_commit_sha\u003e`."}],"source_content_type":"text/x-rst","patch_set":8,"id":"647114cc_69d12953","line":59,"range":{"start_line":59,"start_character":10,"end_line":59,"end_character":43},"in_reply_to":"f36fc008_8e0de32b","updated":"2024-11-20 18:30:21.000000000","message":"I was thinking about the following:\nWhen we bump the major version (and set a git repo tag) the tarball version will be 2025.1.0 and then every time when we rebuild the tarball we figure out what the latest version is available here [1] and increment it. \n\nBut now when you asked this question, I changed my mind and indeed it seems the number of commits related to a given directory is going to work better here.\n\nSo let\u0027s use this to determine the PATCH. This is similar but not the same to what you suggested earlier here [2]\n```\ngit log --oneline \u003ctag\u003e.. \u003cchart_directory\u003e | wc -l\n```\n\n[1] https://tarballs.opendev.org/openstack/openstack-helm\n[2] https://review.opendev.org/c/openstack/openstack-helm-infra/+/930261/1/tools/get_version.sh","commit_id":"e0b0f8b914269898e252d9d87efdc154dce34b3c"}]}