| *** brtknr is now known as brtkwr | 12:38 | |
| *** brtkwr is now known as brtknr | 12:39 | |
| *** brtknr is now known as brtkwr | 12:40 | |
| *** brtkwr is now known as brtknr | 12:41 | |
| *** brtknr is now known as brtkwr | 12:43 | |
| darmach | #startmeeting magnum | 13:00 |
|---|---|---|
| opendevmeet | Meeting started Tue Oct 6 13:00:09 2026 UTC and is due to finish in 60 minutes. The chair is darmach. Information about MeetBot at http://wiki.debian.org/MeetBot. | 13:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 13:00 |
| opendevmeet | The meeting name has been set to 'magnum' | 13:00 |
| darmach | #topic rollcall | 13:00 |
| darmach | o/ | 13:00 |
| mgrzybek | o/ | 13:00 |
| mgrzybek | I have a pending neview for https://review.opendev.org/c/openstack/magnum-capi-helm/+/1005511 | 13:01 |
| darmach | Nothing new on the agenda today, mgrzybek do you have something? | 13:01 |
| mgrzybek | A big upgrade of compenents | 13:01 |
| mgrzybek | Otherwise I would be happy to get some feedback about my HCP blueprint. | 13:02 |
| darmach | I see, that -1 comment was resolved. Let me take further look, and we'll get this rolling | 13:02 |
| mgrzybek | Great! | 13:03 |
| mgrzybek | I guess that people will have a look at my blueprint during the next coming PTG: https://review.opendev.org/c/openstack/magnum-specs/+/999596 | 13:04 |
| mgrzybek | Just get in touch if anyone wants to talk about it. | 13:05 |
| darmach | can you add that to etherpad notes? | 13:05 |
| darmach | https://etherpad.opendev.org/p/magnum-weekly-meeting#L5 | 13:05 |
| jakeyip | o/ sorry am late | 13:06 |
| darmach | Hi Jake! mnasiadka said you might skip today | 13:06 |
| darmach | Do you have anything for todays meeting? | 13:07 |
| darmach | #topic Discussion | 13:08 |
| jakeyip | I don't have much to do, you guys need help in pushing anything? | 13:08 |
| darmach | We have that change above from mgrzybek, waiting for review. Not much to push for now. | 13:09 |
| darmach | Will you be coming to PTG? | 13:09 |
| jakeyip | sorry, reword - I don't have much to push. :D still have (work) stuff to do :P | 13:09 |
| jakeyip | darmach: I shared with mnasiadka; I'll come if I can | 13:10 |
| darmach | All right. Any timeslot preferences? | 13:10 |
| darmach | We can sort it out after the meeting :) | 13:11 |
| darmach | If noone is coming up with anything we can finish for today. If anyone wants to add something - feel free to add it to etherpad, also topics to discuss for the next meeting agenda. | 13:13 |
| darmach | #endmeeting | 13:13 |
| opendevmeet | Meeting ended Tue Oct 6 13:13:40 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 13:13 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/magnum/2026/magnum.2026-10-06-13.00.html | 13:13 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/magnum/2026/magnum.2026-10-06-13.00.txt | 13:13 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/magnum/2026/magnum.2026-10-06-13.00.log.html | 13:13 |
| jakeyip | yeah I'd need to go thru kamaji. haven't touched that before | 13:14 |
| jakeyip | mgrzybek: why did you want to add it to magnum-capi-helm instead of another driver? | 13:15 |
| mgrzybek | This is the only tool designed as a backoffice engine. Some other solutions exist but they are standalone products. | 13:16 |
| mgrzybek | So this is the easiest way to use it with Magnum. | 13:17 |
| jakeyip | on a brief look, I feel like it's different enough to warrant it as a separate driver. you can have multiple coe drivers with magnum | 13:19 |
| mgrzybek | Hmmm, mnasiadka told me it could also be a dedicated driver. | 13:20 |
| jakeyip | I am worried that extending magnum-capi-helm to do too many things mean it can't evolve fast and/or break other things when it changes. | 13:21 |
| mgrzybek | Writing some glue using Helm is fine, maybe using a dedicated Helm chart. But you are right: one tool --> one use case | 13:21 |
| mnasiadka | I don’t know if we want to replicate Helm usage in the same way that we currently do in magnum-capi-helm | 13:23 |
| mnasiadka | It’s fragile | 13:23 |
| jakeyip | yeah if new driver, do without the helm layer, don't need one more level of indirection | 13:23 |
| jakeyip | I wrote this previously to cater for multiple drivers https://review.opendev.org/c/openstack/magnum/+/907297 . see if that works | 13:24 |
| mgrzybek | I would love to remove Helm too and manage raw YAMLs. A lot easier for me! | 13:24 |
| jakeyip | go crazy :) | 13:25 |
| mnasiadka | Go boring I’d say | 13:26 |
| mnasiadka | Python, API, yaml, that’s more like it | 13:27 |
| jakeyip | :) | 13:27 |
| mnasiadka | But we need to think in a wider perspective, I’d like to go forward with multiple management clusters and a kubeadm driver to manage them | 13:27 |
| mgrzybek | True. I try to avoid layers of layers of layers. | 13:27 |
| mnasiadka | And them some approach to manage cluster extensions by a user (use Helm for that) | 13:28 |
| mnasiadka | And Kamaji seems to fit in that direction as well | 13:28 |
| jakeyip | what's the use case for multiple mgmt clusters? | 13:29 |
| mnasiadka | Well, tried running more than 30-40 tenant clusters? | 13:30 |
| mnasiadka | And upgrading CAPI mgmt cluster? | 13:30 |
| mnasiadka | clusterctl move is way easier | 13:30 |
| mnasiadka | And there are people that don’t really want the cloud admin to have keys to their cluster | 13:31 |
| mgrzybek | From what I see there are two layers: 1. upgrading many clusters. 2. upgrading addons on many clusters. | 13:32 |
| jakeyip | will be good to document those use cases | 13:34 |
| jakeyip | also think we are talking about 2 things - 1. allow multiple management clusters, 2. multiple tenant control planes a management cluster | 13:35 |
| jakeyip | 2. multiple tenant control planes *on* a management cluster | 13:36 |
| mgrzybek | Indeed. | 13:37 |
| jakeyip | each solve differnt problems? (1) is basically sharding to split load (2) reduces inefficiency by using a management cluster for all CP instead of multiple CP nodes (x3 for HA) | 13:39 |
| mgrzybek | True. | 13:44 |
| jakeyip | chat agian next meeting. seeya | 13:56 |
| andrewbogott__ | Regarding the magnum-cluster-api... I'm late to realizing that there is a fair amount of state about tenant clusters stored in the capi mgmt cluster. Can I get advice about how to preserve/maintain/recreate/whatever that state? I'm worried that if my management cluster breaks or is lost for other reasons all the user clusters will be unmaintainable orphans. | 15:41 |
| jrosser | we made a backup/restore thing for it | 15:44 |
| jrosser | cluster-api has something for exporting the cluster state, though its has big warnings associated with it | 15:44 |
| andrewbogott__ | What are you backing up? Does your backup/restore thing use the cluster-api export feature? | 15:46 |
| jrosser | yes it does | 15:46 |
| andrewbogott__ | And I take it that works for you despite the big warnings? | 15:47 |
| andrewbogott__ | Is your code public or just internal? | 15:47 |
| jrosser | https://opendev.org/openstack/openstack-ansible-plugins/src/branch/master/playbooks/k8s.yml#L166-L230 | 15:48 |
| mgrzybek | Backup tools like Velero dumps the whole etcd database. So you can restore easily. | 15:48 |
| andrewbogott__ | ok! That's useful. I might have an etcd backup tool handy already. | 15:48 |
| jrosser | ^ yes theres lots of approaches and I think at the time the clusterctl export/import was not guaranteed to work | 15:49 |
| mgrzybek | I guess these features were mainly written to create `clusterctl move` | 15:49 |
| andrewbogott__ | thanks y'all! | 15:50 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!