| dalees | Hello, meeting scheduled to start in 10 minutes. | 08:50 |
|---|---|---|
| dalees | I see some notes in the agenda, thanks for adding those. | 08:51 |
| jakeyip | hi dalees :) | 08:51 |
| jakeyip | might need to step away for a bit in the middle of the meeting for something, just letting you know first | 08:53 |
| dalees | ok, all good. | 08:53 |
| dalees | #startmeeting magnum | 09:00 |
| opendevmeet | Meeting started Wed May 7 09:00:09 2025 UTC and is due to finish in 60 minutes. The chair is dalees. Information about MeetBot at http://wiki.debian.org/MeetBot. | 09:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 09:00 |
| opendevmeet | The meeting name has been set to 'magnum' | 09:00 |
| dalees | #topic Roll Call | 09:00 |
| dalees | hi everyone! who is around to talk today? | 09:00 |
| dalees | o/ | 09:00 |
| jakeyip | o/ | 09:00 |
| dalees | courtesy ping: mnasiadka | 09:01 |
| dalees | we'll make a start shortly | 09:02 |
| dalees | #topic magnum-capi-helm-chart | 09:02 |
| dalees | let's discuss this first topic, is this yours jakeyip ? | 09:02 |
| jakeyip | yeah the first few are mine | 09:05 |
| dalees | so i looked at what we do with our fork of these charts | 09:06 |
| dalees | and we publish them to our oci registry with a ci pipeline, it should be handling the dependencies too (from openstack-cluster to the rest) | 09:07 |
| dalees | with something like: | 09:07 |
| dalees | 1. helm dependency build charts/openstack-cluster | 09:07 |
| dalees | 2. helm package --app-version $(git describe --always) --version $(git describe --tags) charts/openstack-cluster | 09:07 |
| dalees | 3. helm push charts/openstack-cluster/openstack-cluster-$(git describe --tags).tgz oci://example.com/capi-helm-charts | 09:07 |
| dalees | (CI triggering on git tags) | 09:08 |
| jakeyip | yeah I think that's similar to what azimuth-cloud is doing, but I find the tight coupling annoying | 09:08 |
| dalees | does that help, or have I missed the point? | 09:08 |
| jakeyip | some things I don't like - (1) a change in any of the chart means you need to bump all 3 versions | 09:10 |
| dalees | well it's a chart (and dependency) which then refer to several other charts. you *could* change what it's referring to in the values: https://github.com/azimuth-cloud/capi-helm-charts/blob/main/charts/cluster-addons/values.yaml#L186 | 09:11 |
| jakeyip | (2) it is not easy for a user to just clone and build a particular version; they have to know the pipeline | 09:11 |
| dalees | what are the options? split the etcddefrag chart out of this repo? | 09:12 |
| jakeyip | instead of just complaining, we (Nectar) do have a modification on it and is working, would like to see what the wider community thinks | 09:12 |
| dalees | it feels a bit separate from the other two, now i'm reading about it. | 09:13 |
| jakeyip | https://github.com/NeCTAR-RC/magnum-capi-helm-charts/commits/nectar/0.14.1/ | 09:14 |
| jakeyip | I'm sorry if it is a bit confusing because there are many different small issues that can be improve of in different ways | 09:17 |
| dalees | i see you're pinning the version onto azimuth clouds version, is this so it doesn't move unexpectedly or to avoid an issue because it's defaulting to whatever tag is used to deploy it? | 09:19 |
| dalees | seems that moving the etcd defrag chart to it's own repo could help in either case? (and then increment the tag with the bot) | 09:20 |
| jakeyip | so it'll use the azimuth one because I don't want to push another change to update the chart repo. I think you must have a change for that? | 09:21 |
| dalees | for now, we don't deploy that etcd defrag chart. we probably should be. | 09:22 |
| jakeyip | ah ok. but you can see if you want to deploy that, you'll have to do a change for the repo | 09:25 |
| dalees | yeah, indeed. we'd need to publish the etcd defrag chart either at the exact same version as the addon chart, or set the tag explicitly like you've done. | 09:27 |
| dalees | do you have suggestions to make the situation better? | 09:27 |
| jakeyip | you can't publish exactly the same version cos yoru versions are using `git describe` | 09:28 |
| jakeyip | I think we should version everything for starters | 09:29 |
| dalees | couldn't we just publish both at once in the same CI pipeline that triggers off the tag? it's publishing two separate artifacts, which may be disagreeable, but it should function okay? | 09:30 |
| jakeyip | yes you can do that, but that'll bring me to my second thing which is how to override the repo | 09:31 |
| jakeyip | etcdDefrag.chart.repo and also k8sKeystoneAuth.chart.repo | 09:32 |
| dalees | jakeyip: do those values allow you to override the chart repos? | 09:39 |
| dalees | in our fork, we'd just update the chart repo paths instead of providing values. But that's not quite as elegant. I'm not sure what the other options are? | 09:40 |
| dalees | the separation of k8skeystoneauth to a different repo at least means it's versioned separately ;) | 09:41 |
| jakeyip | yeah keystoneauth is ok | 09:41 |
| jakeyip | I don't really have a straightforward answer really because it's all very tangled | 09:42 |
| dalees | yeah, neither. I can only see the benefit of splitting out the etcddefrag chart to simplify forking either the openstack-cluster chart or etcddefrag chart. you wouldn't have to untangle the two, just fork and publish (and then refer to your own repo/version). | 09:44 |
| jakeyip | do you think changing repo for etcd-defrag chart should be a patch on the helm chart, or should we have a way to bring it in from label or driver ? | 09:45 |
| jakeyip | remember we used to have `container_infra_prefix` ? | 09:46 |
| jakeyip | oh dear I think this took up all the time | 09:47 |
| jakeyip | can we go to next topic | 09:47 |
| dalees | haha, it did. | 09:47 |
| dalees | sure, let's move on for now. we can revisit another time, i think there's more to discuss. | 09:47 |
| dalees | #topic compatibility matrix | 09:47 |
| dalees | so you mentioned this previously, and there are definitely hard requirements for the helm charts and capo versioning. | 09:48 |
| dalees | and i think more I've forgotten. So a compatibility matrix is a good idea - where should this go and who can start it off for us? | 09:48 |
| jakeyip | both the driver and helm chart needs the info. but we only control driver so that's where we can start | 09:50 |
| jakeyip | I think the table will be 3 columns? driver - helm chart - capo ? | 09:52 |
| jakeyip | also will need some way of signalling upgrade process | 09:52 |
| dalees | kubernetes version possibly; there is a change to the helm chart needed for 1.33. But that might be a bit much, starting with those three is probably best. | 09:53 |
| jakeyip | like what you mentioned, upgrading the helm chart alone isn't enough, also need to all the clusters to upgrade | 09:54 |
| jakeyip | I guess the question is - does anyone have this info somewhere already or is this something I have to come up with? | 09:54 |
| dalees | yeah, for `v1alpha7` to be fully replaced by `v1beta1`, otherwise you're blocked by an upper capo version. | 09:55 |
| dalees | i don't think it's written anywhere else; capo wasn't too interested in this info when i mentioned it. it's really our problem to document and upgrade away from | 09:56 |
| jakeyip | ok | 09:57 |
| dalees | capo has a supported version table somewhere, but it doesn't have any helm chart info on it. | 09:57 |
| jakeyip | I'm happy to write something up if this isn't documented already. if you find helpful links send them to me | 09:59 |
| dalees | great thanks; if you write the first draft I will add what I know to it | 10:00 |
| jakeyip | need a patch here too I think https://github.com/openstack/magnum-capi-helm/blob/master/magnum_capi_helm/kubernetes.py#L289 | 10:00 |
| jakeyip | I was lookng through open changes in case I missed any for this | 10:01 |
| dalees | yeah - i don't think v1alpha6 is served anymore in our capo version. hmm. | 10:01 |
| jakeyip | there is https://review.opendev.org/c/openstack/magnum-capi-helm/+/942698 but not really same | 10:02 |
| jakeyip | do we need to unstuck ^ somehow also? | 10:02 |
| dalees | that was fixed in the chart instead of the capi helm driver. | 10:04 |
| dalees | https://github.com/azimuth-cloud/capi-helm-charts/pull/501 | 10:05 |
| dalees | I'll link that to the gerrit review | 10:05 |
| dalees | ok, i think we're out of time today. | 10:06 |
| jakeyip | yes | 10:06 |
| dalees | we can come back to the remaining topics during the week, or next week. | 10:06 |
| dalees | anything else before I close? | 10:07 |
| jakeyip | nah let's chat next week | 10:08 |
| dalees | #endmeeting | 10:08 |
| opendevmeet | Meeting ended Wed May 7 10:08:59 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 10:08 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/magnum/2025/magnum.2025-05-07-09.00.html | 10:08 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/magnum/2025/magnum.2025-05-07-09.00.txt | 10:08 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/magnum/2025/magnum.2025-05-07-09.00.log.html | 10:08 |
| dalees | ok, thanks for joining | 10:09 |
| jakeyip | thanks for holding dalees | 10:09 |
| opendevreview | Dale Smith proposed openstack/magnum master: Debug logs now use cluster UUID instead of DB ID. https://review.opendev.org/c/openstack/magnum/+/949091 | 21:27 |
| opendevreview | Dale Smith proposed openstack/magnum master: Poll more Clusters for health status updates https://review.opendev.org/c/openstack/magnum/+/948681 | 21:29 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!