jakeyip | Hi all meeting in about 10 mins. Agenda: https://etherpad.opendev.org/p/magnum-weekly-meeting | 08:48 |
---|---|---|
jakeyip | dalees: are you around? | 08:58 |
dalees | hi jakeyip, i'm online | 08:59 |
jakeyip | #startmeeting magnum | 09:01 |
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 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 09:01 |
opendevmeet | The meeting name has been set to 'magnum' | 09:01 |
jakeyip | #link https://etherpad.opendev.org/p/magnum-weekly-meeting | 09:02 |
jakeyip | #topic Roll Call | 09:02 |
jakeyip | o/ | 09:02 |
dalees | o/ | 09:02 |
jakeyip | thanks for coming :) | 09:03 |
jakeyip | don't have much on the agenda, dalees feel free to add something | 09:04 |
dalees | neither this week, been working on CAPO code. might be a short one | 09:04 |
jakeyip | I worked through one of your magnum-ui change | 09:05 |
jakeyip | while doing that I found an issue, I've put it in the agenda | 09:06 |
jakeyip | basically the 3.12 SSL change broke devstack magnum-ui | 09:06 |
dalees | hmm, thats interesting. do you know why? | 09:07 |
jakeyip | basically devstack uses IP and horizon using magnumclient can't verify ssl certs against that | 09:08 |
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 |
jakeyip | have you came across the same doing your magnum-ui changes? | 09:09 |
dalees | No, but I wasn't using devstack, nor that change as it only merged this month. | 09:10 |
jakeyip | ok nvm I'll work thru it | 09:14 |
jakeyip | any reviews you need pushing let me know | 09:14 |
dalees | lots of bitsy ones, but as last week I need to check them again and make sure they're updated. | 09:15 |
jakeyip | ok | 09:15 |
jakeyip | I want to talk about something else that's not on agenda | 09:15 |
dalees | the main ones for magnum-ui are progressing through, thanks :) | 09:15 |
jakeyip | do you have a registry? | 09:15 |
dalees | ok | 09:15 |
dalees | an oci registry? yes | 09:16 |
jakeyip | harbor? | 09:16 |
dalees | it should be, but for now it's just docker registry:2 | 09:16 |
jakeyip | we are having an issue with our harbor registry backed by swift; I'm trying to hunt down a bug | 09:16 |
dalees | another team uses harbor here, not sure if it's swift backed though. | 09:17 |
jakeyip | I can't push docker.io/library/python:3.10-bookworm to our registry, it errors out with 503 | 09:17 |
mkjpryor | We use Harbor in Azimuth but right now it is backed by a Cinder PVC | 09:17 |
mkjpryor | I have used the S3 store before though, not with Swift or Ceph RGW though | 09:18 |
jakeyip | hi mkjpryor :) can you try that :) | 09:18 |
jakeyip | we are running Version v2.10.2-1a741cb7 | 09:18 |
dalees | jakeyip: so you can push/pull other images, but just not that one? | 09:19 |
jakeyip | yeah | 09:19 |
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 |
jakeyip | super weird | 09:19 |
mkjpryor | That is odd | 09:20 |
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:21 |
jakeyip | yeah I've traced a bunch of things | 09:23 |
jakeyip | just finished setting up another separate instance without swift, guess what that worked | 09:24 |
jakeyip | anyway, it's ok, I just have to continue digging, just thought it's good to check | 09:25 |
jakeyip | #topic open discussion | 09:25 |
dalees | nothing from me this week | 09:28 |
mkjpryor | I saw that there has been a commit to the magnum-capi-helm-charts repo - who is actively working on that? | 09:28 |
jakeyip | I just forked it, was planning to work on it | 09:29 |
mkjpryor | We are looking to start the paperwork to contribute Azimuth to the CNCF shortly | 09:29 |
jakeyip | that's good | 09:29 |
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 |
mkjpryor | :shrugs: | 09:30 |
jakeyip | I find the 'not single vendor' requirement weird | 09:31 |
mkjpryor | Porting the CI to Zuul is, as we have previously discussed, my main concern with moving the CAPI Helm charts to OpenDev | 09:31 |
mkjpryor | It was noted by a few members of the community, so it does seem to be an issue | 09:32 |
jakeyip | so many things are single vendor. but like if it's google/microsoft it's ok, stackhpc is not? | 09:32 |
mkjpryor | Maybe "belongs to a foundation, with StackHPC as custodians" sits better | 09:32 |
* jakeyip shrugs | 09:33 | |
mkjpryor | Mainly, it stops us from unilaterally changing the licence | 09:33 |
mkjpryor | *license | 09:33 |
mkjpryor | Which I think is what most people are scared of with "single vendor open-source" | 09:33 |
mkjpryor | After all the recent incidents | 09:34 |
jakeyip | nah nothing preventing that, see elk | 09:34 |
jakeyip | anyway that's not I'm concerned with | 09:34 |
mkjpryor | Elastic never belonged to a foundation | 09:34 |
mkjpryor | ElasticSearch, rather | 09:35 |
mkjpryor | So Elastic were able to just change the license as and when they wished | 09:35 |
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 |
jakeyip | and cloud providers will extend from magnum's | 09:35 |
mkjpryor | In that case, you should make some effort to port that fork to the upstream Helm addon provider | 09:36 |
mkjpryor | https://github.com/kubernetes-sigs/cluster-api-addon-provider-helm | 09:36 |
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 |
jakeyip | ok | 09:37 |
dalees | I was wondering how that differed from yours | 09:37 |
mkjpryor | But Magnum should probably make efforts to use as many upstream components as possible I think | 09:37 |
mkjpryor | If you are going to fork the charts | 09:37 |
mkjpryor | It does broadly the same thing | 09:38 |
dalees | right, i see - it is quite new | 09:40 |
mkjpryor | In fact, we were involved in the initial conversation and their template syntax for the values was inspired by our provider | 09:42 |
mkjpryor | But we just didn't have the time to get involved in the dev | 09:42 |
jakeyip | I think this will be good, will be great if someone can help with this | 09:43 |
jakeyip | my priority now is getting CI working and hopefully that'll be able to unblock people working on this | 09:44 |
jakeyip | can't merge changes without CI | 09:44 |
jakeyip | or well, can if we YOLO it | 09:44 |
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 |
mkjpryor | Flux has some nice functionality for detecting and correcting drift, which we are interested in for managed clusters | 09:47 |
mkjpryor | (We might chose to use Argo, which has similar functionality) | 09:48 |
mkjpryor | choose* | 09:48 |
jakeyip | what will drift? | 09:52 |
mkjpryor | The resources installed on the tenant clusters by the addons | 09:56 |
mkjpryor | So basically, if the user does something stupid like delete or reconfigure the CNI, Flux will detect the "drift" and correct it | 09:57 |
jakeyip | ah ok. will this be auto or a 'reset my cluster' functionality | 09:58 |
mkjpryor | So for us in Azimuth, it will be constantly reconciling | 10:01 |
jakeyip | ok we are at time I should end the meeting | 10:02 |
jakeyip | #endmeeting | 10:02 |
opendevmeet | Meeting ended Wed Jun 19 10:02:17 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 10:02 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/magnum/2024/magnum.2024-06-19-09.01.html | 10:02 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/magnum/2024/magnum.2024-06-19-09.01.txt | 10:02 |
opendevmeet | Log: https://meetings.opendev.org/meetings/magnum/2024/magnum.2024-06-19-09.01.log.html | 10:02 |
jakeyip | feel free to stay | 10:02 |
jakeyip | ok feels like one of those things that will be annoying if you want to test something :) | 10:03 |
jakeyip | also some CNI things can't be changed or changed back so it's gonna be interesting | 10:03 |
mkjpryor | In 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 componenets | 10:05 |
mkjpryor | It is more about protecting users from accidentally doing something | 10:05 |
mkjpryor | Or at least flagging when the resources don't look like they should (if we decide not to automatically correct the drift) | 10:05 |
jakeyip | yeah that will be good | 10:06 |
mkjpryor | So we will be using Flux (or Argo) to do that | 10:07 |
mkjpryor | But 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 objects | 10:07 |
mkjpryor | It also helps us with migrating | 10:08 |
jakeyip | seems like it'll be nice to not give such users admin privileges | 10:09 |
mkjpryor | That is also in our plan | 10:09 |
jakeyip | reminds me of someone asking if is it possible in RBAC to exclude certain namespaces :) | 10:09 |
mkjpryor | However we don't want to limit users to only specific namespaces | 10:10 |
mkjpryor | So I am planning to look at using Kyverno (or similar) to deny access to system namespaces by policy | 10:10 |
mkjpryor | While still letting users create new namespaces and access thhose | 10:10 |
jakeyip | hm interesting idea | 10:13 |
mnasiadka | hello (late as always) | 10:16 |
jakeyip | hi mnasiadka | 10:17 |
jakeyip | still busy with DC work? :) | 10:18 |
mnasiadka | naah, somebody scheduled me full day of back to back calls | 11:00 |
mnasiadka | that's it for being productive today | 11:00 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!