09:01:12 <jakeyip_> #startmeeting magnum
09:01:12 <opendevmeet> Meeting started Wed Sep 25 09:01:12 2024 UTC and is due to finish in 60 minutes.  The chair is jakeyip_. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:01:12 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:01:12 <opendevmeet> The meeting name has been set to 'magnum'
09:01:18 <opendevmeet> jakeyip_: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
09:01:26 <jakeyip_> #link https://etherpad.opendev.org/p/magnum-weekly-meeting
09:01:30 <jakeyip_> Please put your topics into to Agenda
09:01:33 <jakeyip_> #topic Roll Call
09:01:35 <jakeyip_> o/
09:01:56 <jakeyip> o/
09:02:01 <dalees> o/
09:03:18 <jakeyip> mnasiadka: you around? :)
09:03:36 <mnasiadka> I am, but semi-available (on a different call)
09:04:12 <jakeyip> that's ok :)
09:05:33 <jakeyip> #topic reviews
09:05:47 <jakeyip> 930190: Use capi_helm_chart_version label from cluster | https://review.opendev.org/c/openstack/magnum-capi-helm/+/930190
09:06:08 <jakeyip> (added this to the front since freshes in our minds)
09:07:06 <dalees> yeah, that one is waiting on me it seems. I havn't "understood" it yet or tested myself, but it reads okay if others are fine with it
09:07:12 <jakeyip> dalees: I think your point is valid.
09:07:23 <dalees> oh I'm looking at the wrong patchset
09:07:45 <dalees> I was thinking of 926143. Sorry. back to 930190
09:08:20 <jakeyip> sorry I reordered
09:08:29 <dalees> jakeyip: yeah; there is so much in the Helm charts that we change from release to release. One cluster could sit on a single chart but it'd eventually go stale (addon versions, CAPO and all that)
09:09:04 <jakeyip> I think immutab
09:09:07 <dalees> stackhpc bump all kinds of versions in there, and they all upgrade really well.
09:11:20 <jakeyip> my experience is: creating a cluster froma CT with a different `capi_helm_chart_version` label value, magnum now accepts it and makes it seem like it overrides, but it doesn't
09:12:09 <jakeyip> i think immutable labels is the right way forward
09:13:04 <dalees> oh ok, yeah that is a bit misleading to have the label set but not do anything in the driver.
09:14:14 <jakeyip> I think I'll abandon this change and explore immutable label.
09:14:37 <jakeyip> if you are aware of other immutable labels let me know
09:14:49 <dalees> they're already immutable, you can't change them ;)
09:14:52 <dalees> do you mean mutable?
09:15:35 <jakeyip> I guess I meant can't be overridden
09:16:13 <dalees> ah i understand now
09:18:44 <jakeyip> FYI paste https://paste.openstack.org/show/bmELswdzV3nJPe8U91Iv/
09:19:12 <jakeyip> currently this can be done for all labels
09:20:05 <dalees> i see, that output assumes all labels from the cluster template can be overridden at the cluster level.
09:20:27 <jakeyip> yeah
09:21:02 <dalees> feels like labels need a bit of attention to let the driver determine how they can be changed and overridden.
09:22:17 <jakeyip> yeah we don't have any rules for making one label act differently from another
09:23:03 <jakeyip> feels like this affects upgrade. similarly also no rules governing which templates can be upgraded to which
09:24:10 <dalees> yah, I've got ideas around that too but not scheduled to implement yet. Maybe I should write the proposals anyway for feedback and someone else who might pick them up.
09:24:36 <jakeyip> it sort of feels like it's not the job of magnum-capi-helm driver to determine what template can be upgraded to what
09:24:39 <dalees> I have a list of 8 labels that we can support being mutable in CAPI drivers.
09:25:51 <dalees> no, but driver matters - we had a customer downgrade a CAPI cluster to a Heat template. That didn't go so well ;)
09:26:27 <jakeyip> yeah
09:27:55 <jakeyip> the upgrade path is so finnicky
09:29:19 <dalees> I feel like it needs another API endpoint that you ask Magnum for a list of Templates that are upgrade candidates for the given cluster.
09:29:40 <dalees> that same function can validate the upgrade requests.
09:30:57 <jakeyip> yeah I am thinking the same. the validation needs to be somewhere else maybe
09:32:09 <jakeyip> so a CT has labels, and also properties (image_id)
09:33:22 <jakeyip> labels can be overridden when spinning up clusters, but (some) properties (like image_id) can't
09:34:56 <jakeyip> so maybe some labels shouldn't be labels if they are what is being used to determine if a cluster from CT A can be upgraded to CT B
09:36:53 <dalees> that's an interesting distinction
09:37:09 <jakeyip> OR driver just make sure it can't be overridden.
09:38:01 <jakeyip> I don't know how that fits in to your mutable vs immutable labels idea though, maybe I should wait to read your proposal before thinking about it
09:39:09 <dalees> well yeah, it's a good point. I'm trying to determine if Overridable always means mutable, or if these need to be separate concepts.
09:40:45 <dalees> Maybe I will list some concrete examples when I write the proposal, and see where they fit.
09:41:03 <jakeyip> that'll be good
09:41:09 <jakeyip> ok shall we go on to other topic
09:41:16 <dalees> sure
09:42:01 <jakeyip> https://review.opendev.org/c/openstack/magnum/+/926143 - Fix certs ops as trustee for existing clusters
09:42:47 <jakeyip> I think you don't run heat driver now so unable to verify?
09:44:43 <dalees> yeah, but also running Antelope without the RBAC policies. I need to upgrade to understand this and the db problems
09:45:33 <jakeyip> ok. does your cloud still have heat-driver clusters?
09:45:46 <dalees> yes
09:46:24 <jakeyip> ok then this will still affect you when you upgrade to bobcat
09:47:08 <jakeyip> there's a second part to it that is actually more complicated. I'm hoping to revisit that soon but prob miss D cut off
09:47:16 <jakeyip> can explain to you when you hit it
09:47:30 <jakeyip> maybe let's aim to get this simpler one in for D
09:48:50 <dalees> oh yeah, i think the change is reasonable and needed. I'm happy to +2 and trust ricolin and mnasiadka understand it if that helps things move along. For me, I just need to breakpoint there to understand it because trusts are still confusing :)
09:49:22 <jakeyip> :D
09:49:40 <jakeyip> I really wish you don't have to learn that
09:53:22 <jakeyip> anyway we are almost at time
09:55:13 <jakeyip> last thing is there's a bug which affects C but I haven't had the free time to upgrade to C. I hope to get on to that soon, just finishing up capi driver now on our cloud
09:55:47 <jakeyip> if you can help with that please do, it's affecting some users
09:55:54 <jakeyip> nothing else from me
09:56:31 <jakeyip> anything else you want to bring up dalees ?
09:57:56 <dalees> Nah nothing from me, though I did refresh the patchsets for Control plane resize(906086) and the RPC initialize (927555)
09:58:12 <dalees> you've already seen the control plane one, of course
09:58:32 <opendevreview> Dale Smith proposed openstack/magnum master: Add RPC call to initialize cluster before creation  https://review.opendev.org/c/openstack/magnum/+/927555
09:59:34 <jakeyip> ok. zuul -1 927555, you know what's wrong?
10:00:24 <dalees> yeah, just rebased. it'll be fixed by  930214
10:01:10 <jakeyip> ah ok
10:01:21 <jakeyip> I'll take a look
10:02:21 <dalees> all good, thanks
10:02:52 <jakeyip> #endmeeting