| dalees | hello, any around for tonights meeting? jakeyip has sent his apologies. | 07:58 |
|---|---|---|
| hemanth | hey | 07:58 |
| hemanth | I have added one item for code review.. | 07:58 |
| hemanth | Review need not be on this meeting anyhow .. will appreciate if someone can take a look and provide feedback | 07:59 |
| mnasiadka | dalees: I’m around | 07:59 |
| mnasiadka | darmach: should be as well | 08:00 |
| dalees | great, i'll start us up then | 08:00 |
| dalees | #startmeeting magnum | 08:00 |
| opendevmeet | Meeting started Tue Aug 5 08:00:42 2025 UTC and is due to finish in 60 minutes. The chair is dalees. Information about MeetBot at http://wiki.debian.org/MeetBot. | 08:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:00 |
| opendevmeet | The meeting name has been set to 'magnum' | 08:00 |
| dalees | #topic Roll Call | 08:00 |
| dalees | o/ | 08:00 |
| sd109 | o/ | 08:01 |
| hemanth | o/ | 08:01 |
| dalees | #topic Reviews | 08:03 |
| dalees | hemanth: thanks for adding the topic and link to https://review.opendev.org/c/openstack/magnum-capi-helm/+/955984 | 08:04 |
| dalees | so to support this, do you have different helm charts that will be deployed for canonical's k8s? | 08:05 |
| hemanth | I am trying to use magnum-capi-helm driver to deploy canonical k8s using clusterAPI and saw the driver has controlplane CRD as kubeadmcontrolplane which should be configurable so that to allow any other k8s deployment control plane | 08:05 |
| hemanth | Yes I am preparing a new helm charts for this work | 08:05 |
| dalees | the part I'm not sure on is the approach to turn CRD details into config; it feels like this is a fixed set of names that should be in code. | 08:08 |
| sd109 | Do you mean the new api_resources and k8s_control_plane_resource_conditions config options? | 08:10 |
| hemanth | If i introduce set of names in the code, do you expect to have some functional testing as well as part of upstream with the whole set of new helm charts? | 08:10 |
| dalees | but I'm happy to see expanded use of the driver, be aware there may be breakages until we have CI testing of both capo and canonical k8s | 08:10 |
| dalees | sd109: yeah; that is what i mean. what are your thoughts? | 08:11 |
| dalees | hemanth: perhaps, maybe config is easier to keep these details separate? | 08:11 |
| hemanth | yeah I think config is simpler to make the driver support any k8s deployment tool which have corresponding capi pieces | 08:12 |
| hemanth | so that there will be clean on what upstream tests and supports.. kubeadm | 08:13 |
| sd109 | I quite like the idea of being able to at least modify the api_versions for the CAPI CRDs in config because it further detaches the driver from the mgmt cluster and means we don't need a compatibility matrix in the driver docs | 08:14 |
| sd109 | The supported CAPI API versions are really the responsibility of the chosen Helm charts anyway I guess | 08:15 |
| sd109 | And being able to configure something other than Kubeadm control plane provider via config is, I think, a nice way of widening the driver's adoption | 08:16 |
| dalees | these are good points | 08:19 |
| hemanth | +1 | 08:19 |
| hemanth | If we are on consensus on this approach, will appreciate further feedback on PR when you get time | 08:21 |
| sd109 | I'll try to take a closer look at it this week | 08:21 |
| hemanth | thanks | 08:22 |
| sd109 | hemanth: do you intend to use the Manifest and HelmRelease CRDs for cluster addons too? | 08:22 |
| hemanth | My preference right now is to use https://github.com/kubernetes-sigs/cluster-api-addon-provider-helm unless there is something missing here to use Manifest and HelmRelease CRDs | 08:23 |
| sd109 | I thought that might be the case, we've talked about (and still plan to at some point) move to that upstream project too so would be interested to hear how it works for you | 08:25 |
| hemanth | sure i will let you know | 08:25 |
| dalees | I'm not sure the CRD names and details match, but perhaps they can with the proposed config file options. Likewise we plan to move to using that repo, but still use azimuth/cluster-api-addon-provider | 08:27 |
| dalees | so yeah, it'll be good to hear how you get on with that. Certainly any driver changes to allow supporting both would be welcomed as it's the expected migration path. | 08:28 |
| sd109 | +1 | 08:29 |
| dalees | any more on this topic? | 08:29 |
| hemanth | no, thank you both | 08:29 |
| sd109 | Nothing from me | 08:29 |
| dalees | #topic Proposals | 08:29 |
| dalees | A brief topic, mostly for the other cores - there are two specs created that could use some feedback. | 08:30 |
| dalees | the Flamingo feature freeze is pretty soon, so we'll be getting the first patches up for these two shortly for review. | 08:30 |
| dalees | mnasiadka: please have a read, links in agenda | 08:31 |
| dalees | #topic Open Discussion | 08:31 |
| dalees | anything else to raise? | 08:32 |
| hemanth | there is a question in the channel couple of days ago | 08:32 |
| hemanth | any idea about if it's possible to override the kubeNetwork:pods:cidrBlocks without having to fork and maintain my own version of that helm chart? | 08:32 |
| hemanth | I would like to know your thoughts on this | 08:32 |
| sd109 | Not at the moment, we've encountered similar problems with other default values. It would be possible via driver config if this patch is accepted though: https://review.opendev.org/c/openstack/magnum-capi-helm/+/951966 | 08:34 |
| dalees | yeah we've hit this with a customer too, where having cluster labels for pod and services CIDR lists would be helpful. | 08:36 |
| dalees | sd109: that would be site wide, which I would avoid. perhaps it would work for andrewbogott_ 's use case however. | 08:36 |
| hemanth | Isnt it better solution if we can provide those values in openstack cluster create command? | 08:36 |
| hemanth | * Isnt it better solution if we can provide those override values in openstack cluster create command? | 08:37 |
| dalees | something like this https://github.com/stackhpc/magnum-capi-helm/pull/30 | 08:38 |
| dalees | but also coming from cluster labels. Also if I were to rework that, perhaps only providing the labels if they were defined. Else they should be left to default to whatever the chart values are. | 08:39 |
| hemanth | Ok I am thinking if the helm chart value overrides should be site specific or should be at user level | 08:40 |
| hemanth | esp when i look at the capi-helm-chart in https://azimuth-cloud.github.io/capi-helm-charts there are so many cluster addons which might not be required by all the users | 08:42 |
| sd109 | IIRC John was quite keen on only making it site specific to prevent users from accidentally breaking there clusters with malformed values, but I can see both sides | 08:42 |
| sd109 | Although it's also worth noting that John's proposed patch does it on a per cluster template basis rather than site wide | 08:43 |
| hemanth | ack.. good to know about the ongoing PR.. | 08:43 |
| hemanth | I will take a keen look on the PR | 08:43 |
| dalees | sd109: right, of course. | 08:45 |
| dalees | that patch 951966 does allow quite a few helpful things for the deployer. I need to get back to reviewing that | 08:48 |
| dalees | anything else? I will close out the meeting if we're all good. | 08:57 |
| hemanth | nothing from me | 08:57 |
| sd109 | Likewise | 08:58 |
| dalees | ok, thanks for the discussions | 08:59 |
| dalees | #endmeeting | 08:59 |
| opendevmeet | Meeting ended Tue Aug 5 08:59:31 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 08:59 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/magnum/2025/magnum.2025-08-05-08.00.html | 08:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/magnum/2025/magnum.2025-08-05-08.00.txt | 08:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/magnum/2025/magnum.2025-08-05-08.00.log.html | 08:59 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!