WEBVTT 00:00.000 --> 00:21.120 All right, for a clock. Thanks for coming, so my name is Tom, I'm a bit of an alien here, 00:21.120 --> 00:28.560 because I'm one of the guys from the cloud native communities, so usually we operate 00:28.560 --> 00:40.400 with APIs and not with hardware, so this is going to be interesting, oh, this is maybe, 00:40.400 --> 00:48.720 we need that for the recording, right? Okay. Yeah, so I'm about to tell you about something 00:48.720 --> 00:56.400 about Kubernetes on Resk 5, so I'm a maintainer of KZOS, which is a CNCF host at Kubernetes 00:56.480 --> 01:02.080 distribution. I'm working at Mirantes at the open source program office, and I'm one of the 01:02.080 --> 01:11.680 maintainers, and we have KZOS, and it's sibling project Cosmachon. KZOS is, does anybody know what 01:11.680 --> 01:19.520 that is? Actually, no one does anybody know what K3 is? Yeah, it's kind of like that, it's a Kubernetes 01:19.520 --> 01:25.920 distribution, so like you have a Linux kernel and like your distributions, it's rather like this, 01:26.880 --> 01:34.240 right? And I'm not going to tell you anything that you already know, because like I'm coming 01:34.240 --> 01:38.880 from the complete out of front, I have been here in this room for the whole day, and I was listening 01:38.880 --> 01:43.680 to the stuff that you were presenting, and I was thinking, wow, I don't have, I didn't have a clue 01:43.680 --> 01:52.000 about this, so this is not, so I'm coming from the direct, the other angle, but I can tell you what 01:52.080 --> 01:57.920 I will do today, so as a fast maintainer of Kubernetes related project, I will just try to share my 01:57.920 --> 02:06.800 experiences, and what it took us to make KZOS workable on risk five, and what does Kubernetes 02:06.800 --> 02:13.520 on risk five mean for me, or for you, maybe it's clear to you, maybe not, let's see, and if you 02:13.520 --> 02:19.120 have any questions or comments just like shoot and ask directly and don't wait until the end 02:19.120 --> 02:26.880 of these, and yeah, so what does that mean for the KZOS project, and one, one more important, 02:26.880 --> 02:30.960 the most important part of all of this is like how to build, what's your architecture, or the 02:30.960 --> 02:38.640 IMGs, so, because that is how Kubernetes distributes its stuff, and so we will be talking about 02:38.640 --> 02:44.560 a bit of, a bit how to do that, right? And in the end, I will also have a demo, if the demo 02:44.640 --> 02:51.680 starts with me, I have a set up there with the risk five, four, which is a battery powered, 02:51.680 --> 03:02.080 so let's see if the Wi-Fi, let's thank you, let's see if the Wi-Fi has good connectivity, 03:02.080 --> 03:09.040 otherwise I will need to switch back to the serial cable, let's see, okay, so what, what, 03:09.040 --> 03:15.360 why did I even try to do it, right? So I, I was not nerds night on this, I promise, you know, 03:15.920 --> 03:22.640 yeah, so I have to come up with some considerations, why do I want to do this? Obviously a risk five 03:22.640 --> 03:31.040 is the future, but for me, this is not enough to justify work on this, so I have to come up with 03:31.120 --> 03:38.880 some other like considerations, in this case, porting stuff makes the project better, 03:38.880 --> 03:45.520 it usually also like uncovers backs in everything, and it makes the whole software a bit 03:45.520 --> 03:51.120 better and and rounder and everything, and also of course it's the hot stuff and it's interesting to 03:51.120 --> 03:58.000 do that, right? And yeah, finally enough, I mean, yeah, I mean, I learned today a risk has a 32-bit 03:58.000 --> 04:03.120 mode, I'm not talking about this, we do support 32-bit architecture, and this is not that easy 04:03.120 --> 04:10.560 for example, RMB7, it's especially like in the in the high level of the stack that is always like 04:10.560 --> 04:18.320 problems if you're trying to build something for RMB7, all right, but what does it even mean, 04:18.320 --> 04:23.680 Kubernetes on risk five, so for once you need to know like Kubernetes is basically 04:24.000 --> 04:30.560 analogous to Linux kernel, right? If you're saying you're running Linux, you're not saying 04:31.200 --> 04:36.000 anything, and like it's the Linux kernel, but you all know there has to be a distribution that you 04:36.000 --> 04:41.920 will be using, you have to have the user land in place and all that stuff, and it's comparable 04:41.920 --> 04:48.160 to that in the Kubernetes landscape as well, so Kubernetes at the core, like the cloud kernel, 04:48.160 --> 04:55.280 if you want to call it like this, and then you need basically on top of that whole ship load of 04:55.280 --> 05:03.360 other software that you will be running on that, and from that point of view, it is like if you're 05:03.360 --> 05:10.000 running Kubernetes on risk five, it's like an app or it's like an empty app store, you know, 05:10.000 --> 05:16.000 and OS with an empty app store, you can run the OS, yes, but you can't do anything with it, and 05:16.880 --> 05:24.000 where this is a bit different from like where the analogy no longer holds with all those 05:24.000 --> 05:32.000 distros, so if you're deploying Kubernetes, you're just having that foundation, and there is no 05:32.000 --> 05:37.600 like distribution that packages everything else for you, like if you're installing fedora or arch 05:37.600 --> 05:43.680 or whatever, you have a whole sheet load of software repositories where you can just grab your software 05:43.760 --> 05:49.920 and run on it, so if you would like, for example, go and convince the distribution to support 05:49.920 --> 05:57.040 risk five, they will have a coherent place where they can work on software, and where they can 05:57.040 --> 06:04.320 make it, where they can define processes, build standards, and all those kinds of things, 06:04.320 --> 06:11.360 they can, for example, also like set up a test farm to like build and test the software on 06:11.440 --> 06:17.120 the native architectures, and all of that is not true for Kubernetes, so Kubernetes, like 06:18.720 --> 06:23.600 the software that you run on that is containerized, of course, so you have all those OSI images, 06:23.600 --> 06:30.400 and along with those OSI images, you also have like helm charts, configuration files, 06:31.200 --> 06:36.080 all your Kubernetes resource manifests, right, so for example, the OSI images are 06:36.960 --> 06:42.400 so to say the binary, the binary chart balls, which contain all your binaries, 06:42.400 --> 06:47.920 and the resource manifests in the helm charts are basically installation scripts, if you want to 06:47.920 --> 06:53.920 follow that analogy, and that leads to the fact that you have all of your software stack, 06:53.920 --> 07:01.600 which is like cluttered around like how many different organizations and and upstream projects 07:01.680 --> 07:06.640 and whatnot, and they all have to find their own solution, how to support risk file, 07:09.360 --> 07:18.160 and so let's have a look at Kubernetes, the core itself, it currently doesn't officially 07:18.160 --> 07:24.880 support risk file, so you can find pre-built binaries for risk file or any test coverage or 07:24.880 --> 07:31.280 anything of that, it's just that you're on your own, there has been like community 07:31.360 --> 07:35.440 requests of supporting that, but for the aforementioned reasons, they're usually not 07:36.480 --> 07:44.000 willing to like put that into official upstream for the lack of manpower, for the lack of 07:45.040 --> 07:52.080 testing infrastructure, and all of those kinds of things, and there's currently not enough like 07:52.080 --> 08:00.000 downstream demand from folks to support that, and that is also like well, why most of the big 08:00.000 --> 08:04.640 are companies, which are usually like playing in that cloud native area, and supporting a lot 08:04.640 --> 08:09.360 of the resource work that's happening there, they're not having this on their radar, and they're 08:09.360 --> 08:14.400 not putting money into this, and that's hence it's not very much moving there, right? 08:16.960 --> 08:22.160 That's it, like if you grab the sources and go for it, it mostly works, right? 08:22.160 --> 08:26.560 But then you're basically like Linux from scratch, you're Kubernetes from scratch, right? 08:26.560 --> 08:34.800 So you're doing all this stuff yourself, for case 0S, which is a Kubernetes distribution, so 08:34.800 --> 08:40.960 we are packaging like core Kubernetes plus plus a few add-ons and make it easy to install and run 08:40.960 --> 08:47.760 more or less, hopefully, if not like showed at me, we're currently at like a 08:47.760 --> 08:56.320 quote-unquote TS3 level for risk file, so we are officially supporting it, but we're not doing anything 08:56.320 --> 09:04.880 like testing or preparing binaries for this, and all of our stock, all the images, most of all 09:04.880 --> 09:10.480 are stocking, all the images support risk file, there is like a few things missing, but that will 09:10.480 --> 09:18.800 be just a matter of time until we fix that as well, and what you can actually do with KZRS, 09:18.800 --> 09:24.320 you can like check out the sources from GitHub and run make on a risk file board, or on a risk 09:24.320 --> 09:28.320 file machine, and then you get a risk file binary for KZRS that you can directly run. 09:30.400 --> 09:35.360 Some features are not supported, which is mostly because of the OSI images haven't been 09:35.360 --> 09:41.520 converted yet, for example, the Kalyko, which one of the CNIs, the container network, 09:41.520 --> 09:46.960 which king implementations, it's not supported, so we have in KZRS, we have two of them, 09:46.960 --> 09:53.520 so you can only use cube router at the moment, that set like a few days ago, 09:53.520 --> 10:01.520 I just try to make that happen for Kalyko as well, and yeah, it worked in my tests, 10:01.520 --> 10:06.800 so I have to just upstream that to KZRS itself, and then we will have that fixed as well, 10:07.840 --> 10:16.560 and that would be another feature of KZRS, which requires envoy, and envoy is built on basil, 10:16.560 --> 10:20.960 and I'm not sure, does anybody know if the basil blitz system works on a risk file? 10:23.760 --> 10:31.360 Yeah, so there you go, yeah, that is basically the problem with that, okay, um, 10:32.640 --> 10:40.480 so we still have, we have KZRS now, but you don't have anything of these, and if you're usually 10:40.480 --> 10:46.960 running a Kubernetes cluster or multiple Kubernetes clusters, you will all want to have those things, 10:46.960 --> 10:53.200 and there is no, and then you're basically in the land of Kubernetes from scratch, 10:53.520 --> 10:58.160 you have to find all of your projects, check how you can run them on a risk file, 10:58.720 --> 11:05.600 and you manage may vary, so support is growing, especially because of all of all of the 11:05.600 --> 11:10.480 main distributions, which are usually being used in bucket files to build stuff, 11:10.480 --> 11:13.840 they are usually now, they're also supporting a risk file right now, 11:14.720 --> 11:22.240 so that makes things a lot easier for an upstream project to basically adopt a risk file, 11:23.200 --> 11:31.600 but there's of course more to it, so the problem is that you have, you don't have the hardware available, 11:31.600 --> 11:37.280 so of course there's hardware, right, so we have seen a lot of hardware, I mean there's hardware over there, 11:37.280 --> 11:42.400 but the thing is for those projects, it has to be like easily accessible, right, 11:42.400 --> 11:46.880 so the problem is you can't just click on the top or you get left, what have you, 11:46.960 --> 11:52.960 and select risk files in architecture, that is not the thing, you can't go to cloud provider 11:52.960 --> 12:00.240 and get risk file, I do know that scale way has that offering with the risk file on demand machines, 12:00.240 --> 12:07.520 I tried to get some for the demo for today, they're out of stock, so, and that's just what I'm 12:07.520 --> 12:15.600 talking about, and then we're going back again to the initial fact that for distributions, it's 12:15.680 --> 12:21.360 easy, they are building tens of thousands of packages, they have their build farms, they can manage it, 12:21.360 --> 12:27.440 right, it doesn't work for the random cloud native project on the internet, they do need to 12:27.440 --> 12:36.480 rely on public services which make that available for them, so, and I mean for knsurice itself, 12:36.480 --> 12:43.520 I also have the problem that GitHub actions run us on a risk file are more or less, I mean the 12:43.600 --> 12:49.200 last time I checked it was not that easy to run them on real hardware because they're based on 12:49.200 --> 12:56.560 that and there's anybody know how good that network works on risk file, kind of, right, 12:56.560 --> 13:08.800 do they have official builds, okay, second, a build, okay, there are a lot of 13:09.360 --> 13:24.640 community, okay, right, so, right, the community is basically on it, but still no upstream support, 13:24.640 --> 13:32.720 right, and that is a basic problem because like all of those, see, I set up that those projects 13:32.720 --> 13:37.120 are running into it in case you're as of course, they're heavily based on those things and if they 13:37.120 --> 13:43.040 can't run natively, then you have a problem and it is very hard to convince a project for the 13:43.040 --> 13:49.200 single architecture to switch the whole CI system or to like introduce another CI system just to support 13:49.200 --> 13:55.040 that architecture, so that is also like a very, very important requirement to make the adoption 13:55.120 --> 14:03.120 better, that's it, what we can of course do is emulation and cross compiling, which you probably 14:03.840 --> 14:13.600 are all aware of, so we've been funding this game QMO, you can just run your talker builds just 14:13.600 --> 14:20.720 like you do for the other architectures and then you cross your fingers, wait, six hours also, 14:20.800 --> 14:27.840 and I maybe have built a successful build, so this works, but it is very slow and usually it's 14:27.840 --> 14:31.920 it's not what you usually want to do, you just want to build on the native architecture, 14:31.920 --> 14:40.000 that's usually what we strive for, but you know, things are as they are, so we can't do it like this, 14:40.000 --> 14:47.280 so, the other thing is cross compiling of course, so it depends on what what you're 14:47.280 --> 14:53.760 letting, what the language you're using, like the cloud native ecosystem has, has its edge on go, 14:53.760 --> 14:59.280 so many of the projects are in go, which makes things a lot of easier because go as a cross compiling 14:59.280 --> 15:04.720 from the beginning, so you can usually just say on your native architecture that you want to build for 15:04.720 --> 15:11.040 it's five and then it will produce risk five binaries, just like for example LLDM can do the same 15:11.360 --> 15:18.240 with playing and so on, which is not as easy with GCC because it's not the cross compiling 15:18.240 --> 15:23.680 from the beginning, so you always have to install a lot of cross-to-root chains and stuff like this, 15:23.680 --> 15:30.960 which makes things rather complicated and I'm not really an expert in this, but I think most of 15:30.960 --> 15:38.080 you will agree if I say it is not that easy, especially for your random project on the internet, 15:39.040 --> 15:44.640 and yeah, of course you can also like mix a niche that, this is what we are doing for our 15:44.640 --> 15:52.400 KZOS images, we use like both approaches where applicable because we do have a certain 15:52.400 --> 15:59.120 stuff which is built on C and we need to see compile out there and those are usually run by 15:59.120 --> 16:06.320 our emulation because like setting up a cross compiling to a Chinese is just to just to complicated 16:06.320 --> 16:16.080 in comparison to for example for Go, right, and Kubernetes itself, like it's as I said, 16:16.080 --> 16:22.560 it doesn't support a risk five out of the box, but you can just grab the sources, you need to 16:22.560 --> 16:26.800 patch the build system which is a bit ugly because they are hard coding the architecture they're 16:26.800 --> 16:32.880 supporting there, so the build, the patches are of a trivial but you do need to patch the source 16:32.880 --> 16:39.120 tree and then you can just compile it, so there's no problem in that, but you know the delivery 16:39.120 --> 16:49.680 boy is still not satisfied with this, and there you go, and that brings us to the most important 16:49.680 --> 16:55.680 part of this of of bringing risk five or bringing Kubernetes to risk five, where risk five to 16:55.680 --> 17:02.320 Kubernetes are both together, you have to have a look at how Kubernetes package software, 17:02.320 --> 17:11.120 so how many of you do have a good idea about multi-arch, OCI images, what that is, not so many, 17:11.120 --> 17:19.520 okay and OCI images basically five systems snapshot plus a layered five systems snapshot that you 17:19.520 --> 17:27.360 can download from the internet and then you extract that and and run that containerized and multi-arch, 17:27.360 --> 17:36.960 OCI images are basically an envelope version with different images, so you can basically look 17:36.960 --> 17:43.360 up in the envelope which image to choose, so you have basically multiple architectures in one 17:43.360 --> 17:48.160 envelope and when you're downloading that image you can select the right architecture for your 17:48.160 --> 17:53.760 target, and that's how you usually want to build the OCI images, the thing is why do you want to 17:53.760 --> 17:59.280 use it like that, because otherwise you would have to publish a new image under a new name, 17:59.280 --> 18:05.120 so you have usually OCI registries where images have names and versions, and for example if you 18:05.120 --> 18:13.440 want to have a cluster which has which runs x86, arm 64 and risk five together in in one cluster, 18:13.440 --> 18:18.480 you don't want to configure all your stuff differently for each architecture, so you just want to say, 18:18.480 --> 18:24.640 okay well I will install engine x, so and that's the system figure out what engine x actually needs to 18:24.640 --> 18:29.680 be pulled like the risk five one or the 164 one and so on and so on and so forth, so that is the 18:29.680 --> 18:38.960 way to go, and then we can like you look at how to how to actually build OCI images, you can 18:38.960 --> 18:43.760 various different techniques like you can just use plain Docker build and put them build and 18:44.720 --> 18:50.640 build all those images separately and then package them together by a manifest, there is also like 18:50.640 --> 18:56.720 commands for this, then you can like do low level planning, with CLI tools, with build a and stuff 18:56.720 --> 19:02.320 like this, so there is a lot of ways to do it, we are doing it with Docker build links and put 19:02.400 --> 19:11.360 main build links, which is probably for KZ West the most easy part, and if you want to know more about 19:11.360 --> 19:19.760 this just ask me, just connect I'm happy to talk about that, so that is usually the way you do it 19:19.760 --> 19:25.920 with Docker build links, you just say you run the same Docker file for multiple architectures, 19:25.920 --> 19:34.240 and the result will be that you have like the same the same image being built for those architectures, 19:34.240 --> 19:40.880 and this automatically includes things like emulation with a Qemu and Benfund miss, 19:40.880 --> 19:49.360 and this is usually an easy way to get started with risk five, you can do cross compilation without 19:50.240 --> 19:56.240 without emulation in the same Docker file, so there is for example the trick that you can say 19:56.240 --> 20:02.480 dash dash platform equals build platform, that means that you're even if you're targeting risk five, 20:02.480 --> 20:11.120 you're building on the on the build machine, like you on x8664, and that that way you can like 20:11.120 --> 20:17.040 just do the usual cross compilation natively without Benfund miss, and that's usually a kind of 20:17.040 --> 20:23.840 easy way, kind of easy way to to cross compile go, and for example if you use for example 20:23.840 --> 20:29.520 a sequpilar you wouldn't specify platform dash a equals build platform, and then automatically 20:29.520 --> 20:40.000 you would get an emulated build with Qemu, Qemu, another problem is what is if my 20:40.000 --> 20:46.000 what is my upstream build image that I'm using for building doesn't support risk five because of 20:46.000 --> 20:54.640 reasons, then you basically need to like have a switch case in your Docker file to select the 20:54.640 --> 21:00.560 right one, this is the trick, this is a trick that we're using in case you asked to do that for 21:00.560 --> 21:09.200 for the destroyless image, so you can basically hardcode your select statement, so here, so that 21:09.360 --> 21:17.440 you basically select the image via the target argument, which is a bit ugly because you need to 21:17.440 --> 21:23.200 list all the support platforms in advance, even if the base image would support them, but that's 21:24.240 --> 21:28.960 currently the only way to make it work without external tooling, like having different Docker files, 21:28.960 --> 21:36.800 and writing scripts made files whatever around that. Okay, um, when I do my off, obviously I am 21:36.800 --> 21:43.120 in just what I'm doing with this, I want to test them, I need perform it hardware for that, 21:43.120 --> 21:49.360 then we have the upstream kernel support, my experience with risk five is usually that, for example, 21:49.360 --> 21:56.560 for that TH, 15, 20 bucks I have over there, there is usually weird kernel force trees out there, 21:56.560 --> 22:04.720 which are not very much aligned with upstream, and then like things like the CNI, which is networking 22:04.800 --> 22:10.240 stack, or CSI, which is storage, storage, stack, storage, stack in the cloud native world, 22:10.240 --> 22:16.080 come along and want to require what not kind of kernel features that you need to enable, 22:16.640 --> 22:23.280 and usually then you're in a in a in a bad trouble and trying to fix your fix your kernel 22:23.280 --> 22:29.600 builds and try to to compile the right modules and then you realize that it's not easy as you would 22:29.680 --> 22:35.280 just take an upstream kernel, which is much easier. Yeah, and get out of actions I already mentioned. 22:37.360 --> 22:44.640 All right, so let's see, if I have connectivity to my little, to my little system there, 22:45.200 --> 22:51.040 oh yeah, it's working. So basically this is the, this is the risk five board over there, 22:51.120 --> 23:03.920 it's T8, 15, 20, as I said, and now I also like have thanks to Natanel Cooper from from the 23:03.920 --> 23:15.360 outpine community, I also have a thing in the cloud, which is also the same device, but this is one 23:15.440 --> 23:23.120 of the outpine risk five CI nodes, which which Natanel has landed to me for this demo today, 23:23.120 --> 23:42.800 so I have something in the internet, and we have a source free there, right, we have a source free 23:42.800 --> 23:50.240 here, which is like the latest KZRS tech, and you can build it with make, 23:55.280 --> 23:59.840 which I did it and we tried it before, I just I'm just skipping it right now, because I, 23:59.840 --> 24:12.400 oh god, this is, I hope it won't yell at me. All right, so we do have the KZRS binary here, 24:13.120 --> 24:31.120 and now we want to run a Kubernetes control on this machine, I have set up a config file here, 24:31.120 --> 24:38.240 so what I, what I need to do is I do need to run Q Bruta as a network provider, I want to run 24:38.240 --> 24:44.560 kind as a storage engine at CD would work, but at CD still wants this pesky at CD at some 24:44.560 --> 24:53.520 portage argument, so we still we just want to have a single controller, so like that 24:53.520 --> 24:59.360 thing is fine, that we can just use kind, you just need at CD if you want to have a highly available 24:59.360 --> 25:05.280 control plane, and then we need to patch the connectivity image, because like when I prepared that 25:05.280 --> 25:13.200 demo like a few days ago, I realized that missing test coverage may break things that have been 25:13.200 --> 25:21.520 working before, I needed to patch our risk file variant exactly in the in the code that I showed 25:21.520 --> 25:28.480 before, where I had that select statement for the code, where I had different base images, 25:28.480 --> 25:32.880 and the base image for risk file was a bit different from from that from the rest of the 25:32.880 --> 25:38.480 architectures, and we needed a single instruction to add there to make that work, so I have 25:38.480 --> 25:44.400 to override the connectivity image, and we can't use the baseline KZRS common activity image, 25:45.600 --> 25:51.600 but I mean that's just the fix is a pull request away, you know that, so I'm just installing 25:51.600 --> 26:03.440 a controller here, KZRS install controller right, and then I want to run that controller, KZRS 26:03.520 --> 26:17.440 start, looking all H top, five, okay now things start to work, you need to wait a bit, 26:18.400 --> 26:24.720 kind comes on, connectivity server, cube API so it's a fourth, so this is starting up nicely 26:24.720 --> 26:31.600 apparently, and now we want to have a worker, so the worker will be the device on the on the desk 26:31.680 --> 26:46.000 over there, to join a worker we need to token, we create a token, what on typing are there any questions 26:46.000 --> 27:00.320 so far, okay, okay I have a token here, now I'm going back to my desk system, now I'm trying to 27:02.560 --> 27:06.560 join 27:16.080 --> 27:30.000 oh gosh the connection slow, a Cp, oh there it, there you go, I'm copying over the token hopefully, 27:30.080 --> 27:34.960 yeah, and now I can just run my KZRS worker, 27:34.960 --> 27:58.400 I'll of course not, 28:04.960 --> 28:28.560 there you go and hopefully, we see things happening, yeah let's see 28:34.960 --> 28:45.920 boy vice, a bit slower 29:04.960 --> 29:14.960 Where's my? 29:14.960 --> 29:23.960 There is. 29:23.960 --> 29:24.960 Ah sure, I'm an idiot. 29:24.960 --> 29:31.960 I have to do it on the control plane. 29:31.960 --> 29:35.960 Right. 29:35.960 --> 29:36.960 There you go. 29:36.960 --> 29:40.960 It's a bit slower than expected, but it will be working in the end. 29:40.960 --> 29:50.960 I just wanted to deploy an engine X on top of that. 29:50.960 --> 29:52.960 Just a standard engine X deployment. 29:52.960 --> 29:59.960 Just to prove that we can actually run something on it. 29:59.960 --> 30:06.960 Right. 30:06.960 --> 30:07.960 Right. 30:07.960 --> 30:14.960 And now. 30:14.960 --> 30:20.960 So that. 30:20.960 --> 30:22.960 Okay, the Wi-Fi is a bit slow. 30:22.960 --> 30:25.960 But in theory, like the engine X should come up. 30:25.960 --> 30:34.960 And you should be able to test it from the Wi-Fi if you have the IPv4 Wi-Fi on. 30:34.960 --> 30:36.960 By the port. 30:36.960 --> 30:39.960 380. 30:39.960 --> 30:42.960 And. 30:42.960 --> 30:47.960 The address is 151.16. 30:47.960 --> 30:51.960 132.51. 30:51.960 --> 30:55.960 Which might be in my browser history. 30:55.960 --> 31:01.960 And maybe. 31:01.960 --> 31:03.960 Maybe I see something. 31:03.960 --> 31:05.960 Or not. 31:05.960 --> 31:07.960 All right. 31:07.960 --> 31:09.960 So. 31:09.960 --> 31:11.960 I'm over time already. 31:11.960 --> 31:18.960 So any questions. 31:18.960 --> 31:24.960 Yeah. 31:24.960 --> 31:25.960 Yeah. 31:25.960 --> 31:28.960 That's the slide. 31:28.960 --> 31:29.960 Yeah. 31:29.960 --> 31:31.960 Sorry. 31:31.960 --> 31:32.960 What. 31:32.960 --> 31:34.960 What would it take to make KZRS? 31:34.960 --> 31:36.960 T1 platform or risk 5. 31:36.960 --> 31:38.960 T1 platform for KZRS. 31:38.960 --> 31:40.960 So it is. 31:40.960 --> 31:41.960 The built hardware. 31:41.960 --> 31:43.960 We need to build and test it somehow. 31:43.960 --> 31:44.960 So right now. 31:44.960 --> 31:49.960 One thing could be you could like try to contribute upstream cross compilation support. 31:49.960 --> 31:52.960 So that you can cross compile KZRS more easily. 31:52.960 --> 31:58.960 So that we can could like set up the pre compiled binary is already cross compiled. 31:58.960 --> 32:01.960 But then we could could at least not provide test support for it. 32:01.960 --> 32:06.960 For that we definitely need real hardware. 32:06.960 --> 32:07.960 Yes. 32:07.960 --> 32:25.960 So the question was that K3S has of course the same problem with that city. 32:25.960 --> 32:28.960 How do we get at city folks to make risk 5. 32:28.960 --> 32:29.960 Supportive platform? 32:29.960 --> 32:31.960 I think just pushing for it. 32:31.960 --> 32:35.960 I'm not even sure what what it even means to not be supported. 32:35.960 --> 32:37.960 I mean it compiles it runs. 32:37.960 --> 32:42.960 Maybe they do it for the same reasons as we are doing it to tell them. 32:42.960 --> 32:43.960 Okay. 32:43.960 --> 32:46.960 This is unsupported because they don't have test coverage. 32:46.960 --> 32:48.960 I think I'm not sure. 32:48.960 --> 32:49.960 I'm just guessing. 32:49.960 --> 32:54.960 But that would be my guess for the same reason that many projects don't support risk 5. 32:54.960 --> 32:58.960 So the problem is the image portion is not really. 32:58.960 --> 33:00.960 Can not handle this 5 yet. 33:00.960 --> 33:07.960 Can not push the range or it's may or because they may or hold the image. 33:07.960 --> 33:09.960 No, no you're kidding me it's that easy. 33:09.960 --> 33:15.960 I mean okay the statement was that there's the container registry which doesn't support risk 5 33:15.960 --> 33:18.960 because they're doing some mirroring with container registry and everything. 33:18.960 --> 33:21.960 So it's not even that they can't build the risk 5 image. 33:21.960 --> 33:22.960 They can't distribute it. 33:23.960 --> 33:26.960 You can't build it because I build both of them. 33:26.960 --> 33:27.960 We do too. 33:27.960 --> 33:29.960 Yeah. 33:29.960 --> 33:35.960 So maybe just going just going to the Etsy report just going to the CNCFs, 33:35.960 --> 33:39.960 like or Kubernetes like whatever they use and just ask, 33:39.960 --> 33:41.960 be kind and ask. 33:41.960 --> 33:42.960 Would be good. 33:42.960 --> 33:43.960 I mean it's working. 33:43.960 --> 33:49.960 It just needs that pesky environment variable exposed. 33:50.960 --> 33:51.960 Yeah. 33:56.960 --> 33:58.960 Okay, now we talked about Etsy. 33:58.960 --> 34:02.960 Now we're talking about Kubernetes upstream itself. 34:02.960 --> 34:06.960 I think we need to kick some big company asses. 34:06.960 --> 34:08.960 Sorry for that. 34:08.960 --> 34:11.960 I mean it's all about like if there's money behind it, 34:11.960 --> 34:14.960 they will like do it directly. 34:14.960 --> 34:19.960 And right now it's mostly community driven and like the hot asset, 34:19.960 --> 34:20.960 the hotware isn't there. 34:20.960 --> 34:23.960 So the folks are not there. 34:23.960 --> 34:27.960 Like many folks are contributing for bigger companies. 34:27.960 --> 34:30.960 So I think that's a bit of momentum that is missing there. 34:30.960 --> 34:32.960 But that's just my two cents. 34:32.960 --> 34:33.960 I could be wrong on that. 34:33.960 --> 34:34.960 It's just me guessing. 34:34.960 --> 34:39.960 A couple of days ago, cloud fee has mirrored all the 34:39.960 --> 34:41.960 builds to Kubernetes. 34:41.960 --> 34:44.960 And I'm not providing this pipe in. 34:44.960 --> 34:46.960 Can I have a second? 34:46.960 --> 34:49.960 Cloud fee project started. 34:49.960 --> 34:55.960 And that fit now all the people of the images for this five. 34:55.960 --> 34:57.960 About six. 34:57.960 --> 34:59.960 Okay, cloud fee. 34:59.960 --> 35:00.960 Okay. 35:00.960 --> 35:02.960 And they are doing what exactly? 35:03.960 --> 35:05.960 The native Kubernetes. 35:05.960 --> 35:06.960 Oh. 35:06.960 --> 35:07.960 Okay. 35:07.960 --> 35:09.960 So cloud fee is publishing risk five. 35:09.960 --> 35:11.960 Builds of Kubernetes itself. 35:11.960 --> 35:13.960 A couple of days ago, I saw the heat today. 35:13.960 --> 35:15.960 But then I saw that they are doing that now. 35:15.960 --> 35:16.960 Nice. 35:16.960 --> 35:21.960 The build that are just five to support them. 35:21.960 --> 35:22.960 Yeah. 35:22.960 --> 35:24.960 Nice. 35:24.960 --> 35:25.960 Cool. 35:25.960 --> 35:28.960 Anything else? 35:28.960 --> 35:29.960 Okay. 35:29.960 --> 35:30.960 I'm done anyways. 35:30.960 --> 35:31.960 Time-wise. 35:31.960 --> 35:32.960 Thanks. 35:33.960 --> 35:34.960 Thank you. 35:34.960 --> 35:35.960 Thank you. 35:35.960 --> 35:36.960 Thank you. 35:36.960 --> 35:37.960 Thank you. 35:37.960 --> 35:42.960 Thank you.