| *** mmalchuk_ is now known as mmalchuk | 03:44 | |
| jakeyip | Hi all, dalees, mnasiadka, I can't make it for today's meeting, so I'm going to cancel it | 05:16 |
|---|---|---|
| mnasiadka | jakeyip: sure | 07:06 |
| mnasiadka | It's Kolla release time, so I have enough on my plate | 07:06 |
| noonedeadpunk | I just had 1 thing to raise actually, which is slightly time-sesetive to decide on | 08:19 |
| noonedeadpunk | And that is again kata support :) If you've seen ML from Kendal, there's another mentorship program for North Dacota right now. The only thing missing to re-purpose https://etherpad.opendev.org/p/2023-BU-Magnum is having actually a mentor that is aware about magnum codebase enough | 08:20 |
| noonedeadpunk | So was wondering if there's a potential volunteer from the magnum core team to be a mentor if it will fly | 08:21 |
| johnthetubaguy | noonedeadpunk: FWIW, I noticed dalees has recently added gVisor: https://github.com/kubernetes-sigs/image-builder/commit/aed2a1ecc24ab720af0ca612d99da2f8e8a0832e I am assuming kata would be a similar change, but that is more an assumption than me really knowing. | 09:12 |
| johnthetubaguy | jakeyip: keen to catch up wtih you all, but sounds like next week | 09:12 |
| dalees | travisholton, did that actually - not my work :) (but we're both Catalyst Cloud) | 09:14 |
| noonedeadpunk | johnthetubaguy: I assume that's the approach for CAPI driver? | 09:15 |
| noonedeadpunk | as heat driver doesn't use that | 09:15 |
| noonedeadpunk | or does it? | 09:16 |
| johnthetubaguy | Correct, but I thought we agreed the heat driver is getting deprecated and removed, so it seems a bad time to add support there. | 09:16 |
| noonedeadpunk | I'm not arguing with that, more asking :) | 09:17 |
| noonedeadpunk | ok, then it makes more really kata-side of things then on magnum | 09:18 |
| johnthetubaguy | noonedeadpunk: no worries, same here to be honest, I thought we agreed that a few cycles ago, but it seems we didn't :) | 09:18 |
| * noonedeadpunk haven't seen deprecation reno | 09:18 | |
| johnthetubaguy | To be explicit, the cool part of adding Kata in Cluster API is it would be easier to use in all Cluster API supporting things... which is a good point, that sounds more like a project for the Kata team. | 09:19 |
| johnthetubaguy | noonedeadpunk: me neither, I should probably propose that, to try to make that PTG discussion stick | 09:20 |
| noonedeadpunk | I guess that clusterapi needs to merge first and be out of beta first though? | 09:25 |
| noonedeadpunk | Or dunno | 09:25 |
| mkjpryor | So in order to support Kata, in the StackHPC Cluster API driver at least, there are three things that need to happen I think | 09:26 |
| johnthetubaguy | noonedeadpunk: Unsure, some people were arguing for no drivers in the upstream repo... I don't like that idea myself, but I like it more than keeping the heat driver around with few people to maintain it properly. That might just be the strange conversation in my head. | 09:27 |
| mkjpryor | First, we need to build Cluster API compatible images with the Kata runtime installed | 09:27 |
| mkjpryor | Second, the required configuration needs to be supported in the CAPI Helm charts | 09:27 |
| mkjpryor | Third, we add labels to enable it in the Magnum driver | 09:27 |
| johnthetubaguy | travisholton: I am wondering if you have gVisor patchs for those bits? | 09:29 |
| noonedeadpunk | mkjpryor: that sounds absolutely fair list | 09:29 |
| johnthetubaguy | mkjpryor: true, I forgot about the two extra bits, I see that in the readme now (facepalm) | 09:29 |
| mkjpryor | johnthetubeguy: Whatever we do r.e. upstream drivers, we undoubtedly need to get better at supporting out-of-tree drivers. I joined late - was there any news on jakeyip's plan for this? | 09:30 |
| travisholton | I don't have anything in capi-helm-charts (yet) | 09:30 |
| mkjpryor | *johnthetubaguy even (!) | 09:30 |
| mkjpryor | johnthetubeguy sounds a bit weird | 09:30 |
| travisholton | just in image_builder | 09:31 |
| johnthetubaguy | travisholton: cool, that is a good step. Seems like kata could follow your lead there | 09:31 |
| mkjpryor | travisholton: It is possible that having the runtime + the required CRI config in the image could be enough? We probably still need something in the CAPI Helm charts to add the RuntimeClass objects where there are multiple runtimes available? | 09:32 |
| johnthetubaguy | mkjpryor: don't know I haven't checked back on the spec, it seemed like a sound approach. | 09:32 |
| travisholton | mkjpryor: as far as I know that is enough. Once an image is built with that it is only necessary to create the rutimeclass pointing to gvisor and use it in a pod | 09:35 |
| travisholton | so it would be generally available for anyone | 09:35 |
| mkjpryor | travisholton: So we just need a way in CAPI Helm charts to specify the RuntimeClass objects to create? | 09:36 |
| travisholton | that should be pretty easy. the spec is not much at all | 09:36 |
| mkjpryor | travisholton: Is the idea that _any_ image built using the CAPI image_builder will have both containerd _and_ Kata available? | 09:36 |
| mkjpryor | Or will there be a configuration option that you have to set? | 09:37 |
| mkjpryor | travisholton: Did you say you have had something for Kata accepted into the image_builder? Or is it still a PR? | 09:38 |
| travisholton | no I have tried kata | 09:38 |
| travisholton | but my gvisor patch is already in | 09:38 |
| travisholton | so for a runtimeclass you just need https://kubernetes.io/docs/concepts/containers/runtime-class/#2-create-the-corresponding-runtimeclass-resources | 09:39 |
| travisholton | and set "handler: gvisor" | 09:39 |
| travisholton | sorry I have *not* tried kata | 09:41 |
| mkjpryor | I see | 09:41 |
| mkjpryor | My misunderstanding | 09:41 |
| mkjpryor | It would be interesting to see some numbers comparing the impact of gvisor vs Kata, as they seem to do similar things. Kata seems to be getting a lot of traction. | 09:43 |
| mkjpryor | It can also do cool things like encrypting the memory, which I'm not sure gvisor can do? | 09:43 |
| noonedeadpunk | kata also has full kernel isolation ) | 09:45 |
| noonedeadpunk | but it's actually creating VMs | 09:45 |
| noonedeadpunk | though from k8s prespective that should be just another CRI indeed | 09:46 |
| johnthetubaguy | mkjpryor: it would be nice to retest this now virtio-fs is more mature: https://www.stackhpc.com/kata-io-1.html | 09:46 |
| * travisholton doesn't see anything in the gvisor docs specifically about encrypting memory | 09:46 | |
| mkjpryor | Yes - of course. Supporting both in CAPI Helm charts, and hence Magnum, is a case of having an image with the required bits installed basically | 09:46 |
| johnthetubaguy | noonedeadpunk: +1 that is my assuption, its just another CRI | 09:47 |
| noonedeadpunk | Ok, then basically I think that initial ehterpad may be just scraped, as concept is completely different now. Though it might be easier to implement then before - ball is not on magnum side | 09:47 |
| mkjpryor | The main difference I can see is that Kata requires nested virt right? And gvisor doesn't. | 09:48 |
| mkjpryor | Assuming we are running in VMs. | 09:48 |
| noonedeadpunk | yeah, true | 09:48 |
| johnthetubaguy | noonedeadpunk: +1 although I still think Magnum support kata would be great :) | 09:49 |
| travisholton | it doesn't require nested virtualisation | 09:49 |
| mkjpryor | Kata? Or gvisor? | 09:49 |
| travisholton | gvisor | 09:49 |
| noonedeadpunk | gvisor don't but kata does | 09:49 |
| mkjpryor | That was what I meant :-) | 09:49 |
| noonedeadpunk | and I read it in same way :) | 09:49 |
| johnthetubaguy | yeah kata does (unless you are in an Ironic instance) | 09:50 |
| mkjpryor | I wonder how much of gvisor can be implemented as rules in Falco :-P | 09:50 |
| mkjpryor | There must be an eBPF version for sure | 09:50 |
| noonedeadpunk | If I'm not mistaken, vexxhost driver has their own image-builder? | 09:51 |
| johnthetubaguy | I think the distionction is probably that Falco doesn't block syscalls directly, it does actions when bad syscalls are made. I think gVisor is more about an allow list. | 09:51 |
| johnthetubaguy | noonedeadpunk: I believe its a CLI wrapper around the standard upstream packer one, but I am not 100% sure | 09:52 |
| noonedeadpunk | yeah, it gets tarball from https://github.com/kubernetes-sigs/image-builder/ | 09:54 |
| johnthetubaguy | We are currently just using a github action to build, validate then publish the images (quite similar to what SCS are doing for their own images): https://github.com/stackhpc/azimuth-images | 09:54 |
| johnthetubaguy | This is the SCS one doing similar, but slightly different things: https://github.com/osism/k8s-capi-images | 09:55 |
| noonedeadpunk | I think gardener does the same but on their own as well actually... | 09:56 |
| noonedeadpunk | https://github.com/gardenlinux/gardenlinux | 09:58 |
| travisholton | we are doing roughly the same as johnthetubaguy | 09:58 |
| noonedeadpunk | ok, thanks folks for this enlightning talk! | 10:00 |
| johnthetubaguy | My preference is for the operator to build and validate images, then publish templates using those. In that flow the user doesn't really need to generate images. At least, that has been my assumption so far (and is roughly what we did with the Heat driver). | 10:00 |
| johnthetubaguy | I should run too, was good to catch up! | 10:01 |
| travisholton | see y'all later | 10:06 |
| -opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be restarting momentarily for a patch update to address a recently observed regression preventing some changes from merging | 21:08 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!