Wednesday, 2024-06-19

jakeyipHi all meeting in about 10 mins. Agenda: https://etherpad.opendev.org/p/magnum-weekly-meeting08:48
jakeyipdalees: are you around?08:58
daleeshi jakeyip, i'm online08:59
jakeyip#startmeeting magnum09:01
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.09:01
opendevmeetThe meeting name has been set to 'magnum'09:01
jakeyip#link https://etherpad.opendev.org/p/magnum-weekly-meeting09:02
jakeyip#topic Roll Call09:02
jakeyipo/09:02
daleeso/09:02
jakeyipthanks for coming :)09:03
jakeyipdon't have much on the agenda, dalees feel free to add something09:04
daleesneither this week, been working on CAPO code. might be a short one09:04
jakeyipI worked through one of your magnum-ui change09:05
jakeyipwhile doing that I found an issue, I've put it in the agenda09:06
jakeyipbasically the 3.12 SSL change broke devstack magnum-ui09:06
daleeshmm, thats interesting. do you know why?09:07
jakeyipbasically devstack uses IP and horizon using magnumclient can't verify ssl certs against that09:08
jakeyipI 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 worked09:09
jakeyiphave you came across the same doing your magnum-ui changes?09:09
daleesNo, but I wasn't using devstack, nor that change as it only merged this month.09:10
jakeyipok nvm I'll work thru it09:14
jakeyipany reviews you need pushing let me know 09:14
daleeslots of bitsy ones, but as last week I need to check them again and make sure they're updated.09:15
jakeyipok09:15
jakeyipI want to talk about something else that's not on agenda09:15
daleesthe main ones for magnum-ui are progressing through, thanks :)09:15
jakeyipdo you have a registry? 09:15
daleesok09:15
daleesan oci registry? yes09:16
jakeyipharbor?09:16
daleesit should be, but for now it's just docker registry:209:16
jakeyipwe are having an issue with our harbor registry backed by swift; I'm trying to hunt down a bug09:16
daleesanother team uses harbor here, not sure if it's swift backed though.09:17
jakeyipI can't push docker.io/library/python:3.10-bookworm to our registry, it errors out with 50309:17
mkjpryorWe use Harbor in Azimuth but right now it is backed by a Cinder PVC09:17
mkjpryorI have used the S3 store before though, not with Swift or Ceph RGW though09:18
jakeyiphi mkjpryor :) can you try that :) 09:18
jakeyipwe are running Version v2.10.2-1a741cb709:18
daleesjakeyip: so you can push/pull other images, but just not that one?09:19
jakeyipyeah09:19
jakeyipat first I thought it was something affecting our production swift (we have had other issues), but turns out it affects our test registry/swift also09:19
jakeyipsuper weird09:19
mkjpryorThat is odd09:20
daleesi 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:21
jakeyipyeah I've traced a bunch of things09:23
jakeyipjust finished setting up another separate instance without swift, guess what that worked09:24
jakeyipanyway, it's ok, I just have to continue digging, just thought it's good to check09:25
jakeyip#topic open discussion09:25
daleesnothing from me this week09:28
mkjpryorI saw that there has been a commit to the magnum-capi-helm-charts repo - who is actively working on that?09:28
jakeyipI just forked it, was planning to work on it09:29
mkjpryorWe are looking to start the paperwork to contribute Azimuth to the CNCF shortly09:29
jakeyipthat's good09:29
mkjpryorI 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
mkjpryor:shrugs:09:30
jakeyipI find the 'not single vendor' requirement weird09:31
mkjpryorPorting the CI to Zuul is, as we have previously discussed, my main concern with moving the CAPI Helm charts to OpenDev09:31
mkjpryorIt was noted by a few members of the community, so it does seem to be an issue09:32
jakeyipso many things are single vendor. but like if it's google/microsoft it's ok, stackhpc is not?09:32
mkjpryorMaybe "belongs to a foundation, with StackHPC as custodians" sits better09:32
* jakeyip shrugs09:33
mkjpryorMainly, it stops us from unilaterally changing the licence09:33
mkjpryor*license09:33
mkjpryorWhich I think is what most people are scared of with "single vendor open-source"09:33
mkjpryorAfter all the recent incidents09:34
jakeyipnah nothing preventing that, see elk09:34
jakeyipanyway that's not I'm concerned with09:34
mkjpryorElastic never belonged to a foundation09:34
mkjpryorElasticSearch, rather09:35
mkjpryorSo Elastic were able to just change the license as and when they wished09:35
jakeyipI think the fork makes sense because there are some features which you will want in your version, but magnum will just ship with the barebones09:35
jakeyipand cloud providers will extend from magnum's09:35
mkjpryorIn that case, you should make some effort to port that fork to the upstream Helm addon provider09:36
mkjpryorhttps://github.com/kubernetes-sigs/cluster-api-addon-provider-helm09:36
mkjpryorIt didn't exist when we first developed our Cluster API components, and it is different enough that porting is enough of a pain09:37
jakeyipok09:37
daleesI was wondering how that differed from yours09:37
mkjpryorBut Magnum should probably make efforts to use as many upstream components as possible I think09:37
mkjpryorIf you are going to fork the charts09:37
mkjpryorIt does broadly the same thing09:38
daleesright, i see - it is quite new09:40
mkjpryorIn fact, we were involved in the initial conversation and their template syntax for the values was inspired by our provider09:42
mkjpryorBut we just didn't have the time to get involved in the dev09:42
jakeyipI think this will be good, will be great if someone can help with this09:43
jakeyipmy priority now is getting CI working and hopefully that'll be able to unblock people working on this09:44
jakeyipcan't merge changes without CI09:44
jakeyipor well, can if we YOLO it09:44
mkjpryorI 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 provider09:47
mkjpryorFlux has some nice functionality for detecting and correcting drift, which we are interested in for managed clusters09:47
mkjpryor(We might chose to use Argo, which has similar functionality)09:48
mkjpryorchoose*09:48
jakeyipwhat will drift?09:52
mkjpryorThe resources installed on the tenant clusters by the addons09:56
mkjpryorSo basically, if the user does something stupid like delete or reconfigure the CNI, Flux will detect the "drift" and correct it09:57
jakeyipah ok. will this be auto or a 'reset my cluster' functionality09:58
mkjpryorSo for us in Azimuth, it will be constantly reconciling10:01
jakeyipok we are at time I should end the meeting10:02
jakeyip#endmeeting10:02
opendevmeetMeeting ended Wed Jun 19 10:02:17 2024 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)10:02
opendevmeetMinutes:        https://meetings.opendev.org/meetings/magnum/2024/magnum.2024-06-19-09.01.html10:02
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/magnum/2024/magnum.2024-06-19-09.01.txt10:02
opendevmeetLog:            https://meetings.opendev.org/meetings/magnum/2024/magnum.2024-06-19-09.01.log.html10:02
jakeyipfeel free to stay10:02
jakeyipok feels like one of those things that will be annoying if you want to test something :) 10:03
jakeyipalso some CNI things can't be changed or changed back so it's gonna be interesting10:03
mkjpryorIn the Azimuth case, part of the "contract" with users is that if they want us to look after their cluster (via the Azimuth automation) then they don't mess with the system-installed componenets10:05
mkjpryorIt is more about protecting users from accidentally doing something10:05
mkjpryorOr at least flagging when the resources don't look like they should (if we decide not to automatically correct the drift)10:05
jakeyipyeah that will be good10:06
mkjpryorSo we will be using Flux (or Argo) to do that10:07
mkjpryorBut the CAPI-specific templating that is provided by the addon provider is still useful, which is why we will generate Flux/Argo resources based on the current addon objects10:07
mkjpryorIt also helps us with migrating10:08
jakeyipseems like it'll be nice to not give such users admin privileges10:09
mkjpryorThat is also in our plan10:09
jakeyipreminds me of someone asking if is it possible in RBAC to exclude certain namespaces :) 10:09
mkjpryorHowever we don't want to limit users to only specific namespaces10:10
mkjpryorSo I am planning to look at using Kyverno (or similar) to deny access to system namespaces by policy10:10
mkjpryorWhile still letting users create new namespaces and access thhose10:10
jakeyiphm interesting idea10:13
mnasiadkahello (late as always)10:16
jakeyiphi mnasiadka 10:17
jakeyipstill busy with DC work? :) 10:18
mnasiadkanaah, somebody scheduled me full day of back to back calls11:00
mnasiadkathat's it for being productive today11:00

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!