09:01:55 <jakeyip> #startmeeting magnum
09:01:55 <opendevmeet> Meeting started Wed Jun 19 09:01:55 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:55 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:01:55 <opendevmeet> The meeting name has been set to 'magnum'
09:02:05 <jakeyip> #link https://etherpad.opendev.org/p/magnum-weekly-meeting
09:02:10 <jakeyip> #topic Roll Call
09:02:14 <jakeyip> o/
09:02:30 <dalees> o/
09:03:52 <jakeyip> thanks for coming :)
09:04:15 <jakeyip> don't have much on the agenda, dalees feel free to add something
09:04:37 <dalees> neither this week, been working on CAPO code. might be a short one
09:05:10 <jakeyip> I worked through one of your magnum-ui change
09:06:00 <jakeyip> while doing that I found an issue, I've put it in the agenda
09:06:16 <jakeyip> basically the 3.12 SSL change broke devstack magnum-ui
09:07:12 <dalees> hmm, thats interesting. do you know why?
09:08:18 <jakeyip> basically devstack uses IP and horizon using magnumclient can't verify ssl certs against that
09:09:05 <jakeyip> I don't know why it wasn't a problem for the old way of setting up httpclient, if we were verifying at all it won't have worked
09:09:18 <jakeyip> have you came across the same doing your magnum-ui changes?
09:10:19 <dalees> No, but I wasn't using devstack, nor that change as it only merged this month.
09:14:02 <jakeyip> ok nvm I'll work thru it
09:14:30 <jakeyip> any reviews you need pushing let me know
09:15:25 <dalees> lots of bitsy ones, but as last week I need to check them again and make sure they're updated.
09:15:34 <jakeyip> ok
09:15:52 <jakeyip> I want to talk about something else that's not on agenda
09:15:54 <dalees> the main ones for magnum-ui are progressing through, thanks :)
09:15:58 <jakeyip> do you have a registry?
09:15:59 <dalees> ok
09:16:06 <dalees> an oci registry? yes
09:16:14 <jakeyip> harbor?
09:16:37 <dalees> it should be, but for now it's just docker registry:2
09:16:41 <jakeyip> we are having an issue with our harbor registry backed by swift; I'm trying to hunt down a bug
09:17:15 <dalees> another team uses harbor here, not sure if it's swift backed though.
09:17:36 <jakeyip> I can't push docker.io/library/python:3.10-bookworm to our registry, it errors out with 503
09:17:38 <mkjpryor> We use Harbor in Azimuth but right now it is backed by a Cinder PVC
09:18:04 <mkjpryor> I have used the S3 store before though, not with Swift or Ceph RGW though
09:18:05 <jakeyip> hi mkjpryor :) can you try that :)
09:18:38 <jakeyip> we are running Version v2.10.2-1a741cb7
09:19:06 <dalees> jakeyip: so you can push/pull other images, but just not that one?
09:19:12 <jakeyip> yeah
09:19:43 <jakeyip> at first I thought it was something affecting our production swift (we have had other issues), but turns out it affects our test registry/swift also
09:19:45 <jakeyip> super weird
09:20:54 <mkjpryor> That is odd
09:21:02 <dalees> i dont have an environment to replicate with, but there's a few things you could try to narrow that down. separate out tagging, blob pushing, manifest pushing, reading swift logs etc.
09:23:48 <jakeyip> yeah I've traced a bunch of things
09:24:12 <jakeyip> just finished setting up another separate instance without swift, guess what that worked
09:25:47 <jakeyip> anyway, it's ok, I just have to continue digging, just thought it's good to check
09:25:55 <jakeyip> #topic open discussion
09:28:08 <dalees> nothing from me this week
09:28:25 <mkjpryor> I saw that there has been a commit to the magnum-capi-helm-charts repo - who is actively working on that?
09:29:02 <jakeyip> I just forked it, was planning to work on it
09:29:27 <mkjpryor> We are looking to start the paperwork to contribute Azimuth to the CNCF shortly
09:29:53 <jakeyip> that's good
09:30:02 <mkjpryor> I wonder if using the CAPI Helm charts from that project would be sufficiently "not single vendor", and would also allow us to continue to use our working GitHub CI?
09:30:12 <mkjpryor> :shrugs:
09:31:26 <jakeyip> I find the 'not single vendor' requirement weird
09:31:27 <mkjpryor> Porting the CI to Zuul is, as we have previously discussed, my main concern with moving the CAPI Helm charts to OpenDev
09:32:16 <mkjpryor> It was noted by a few members of the community, so it does seem to be an issue
09:32:17 <jakeyip> so many things are single vendor. but like if it's google/microsoft it's ok, stackhpc is not?
09:32:56 <mkjpryor> Maybe "belongs to a foundation, with StackHPC as custodians" sits better
09:33:08 * jakeyip shrugs
09:33:17 <mkjpryor> Mainly, it stops us from unilaterally changing the licence
09:33:23 <mkjpryor> *license
09:33:54 <mkjpryor> Which I think is what most people are scared of with "single vendor open-source"
09:34:28 <mkjpryor> After all the recent incidents
09:34:33 <jakeyip> nah nothing preventing that, see elk
09:34:47 <jakeyip> anyway that's not I'm concerned with
09:34:52 <mkjpryor> Elastic never belonged to a foundation
09:35:04 <mkjpryor> ElasticSearch, rather
09:35:21 <mkjpryor> So Elastic were able to just change the license as and when they wished
09:35:25 <jakeyip> I think the fork makes sense because there are some features which you will want in your version, but magnum will just ship with the barebones
09:35:57 <jakeyip> and cloud providers will extend from magnum's
09:36:20 <mkjpryor> In that case, you should make some effort to port that fork to the upstream Helm addon provider
09:36:21 <mkjpryor> https://github.com/kubernetes-sigs/cluster-api-addon-provider-helm
09:37:01 <mkjpryor> It didn't exist when we first developed our Cluster API components, and it is different enough that porting is enough of a pain
09:37:11 <jakeyip> ok
09:37:30 <dalees> I was wondering how that differed from yours
09:37:34 <mkjpryor> But Magnum should probably make efforts to use as many upstream components as possible I think
09:37:43 <mkjpryor> If you are going to fork the charts
09:38:06 <mkjpryor> It does broadly the same thing
09:40:14 <dalees> right, i see - it is quite new
09:42:09 <mkjpryor> In fact, we were involved in the initial conversation and their template syntax for the values was inspired by our provider
09:42:23 <mkjpryor> But we just didn't have the time to get involved in the dev
09:43:38 <jakeyip> I think this will be good, will be great if someone can help with this
09:44:21 <jakeyip> my priority now is getting CI working and hopefully that'll be able to unblock people working on this
09:44:26 <jakeyip> can't merge changes without CI
09:44:44 <jakeyip> or well, can if we YOLO it
09:47:11 <mkjpryor> I am planning to add support for producing Flux resources to our addon provider, rather than directly calling Helm ourselves, so we will likely continue to use our provider
09:47:39 <mkjpryor> Flux has some nice functionality for detecting and correcting drift, which we are interested in for managed clusters
09:48:25 <mkjpryor> (We might chose to use Argo, which has similar functionality)
09:48:35 <mkjpryor> choose*
09:52:11 <jakeyip> what will drift?
09:56:25 <mkjpryor> The resources installed on the tenant clusters by the addons
09:57:04 <mkjpryor> So basically, if the user does something stupid like delete or reconfigure the CNI, Flux will detect the "drift" and correct it
09:58:53 <jakeyip> ah ok. will this be auto or a 'reset my cluster' functionality
10:01:38 <mkjpryor> So for us in Azimuth, it will be constantly reconciling
10:02:13 <jakeyip> ok we are at time I should end the meeting
10:02:17 <jakeyip> #endmeeting