kata-irc-bot | <fidencio> @ssheribe, could you also add https://github.com/kata-containers/kata-containers/pull/2223 to your backports? Those are quite important as those would prevent the situation where `cargo vendor` wouldn't work from a tarball. | 07:06 |
---|---|---|
kata-irc-bot | <ssheribe> @fidencio would it make sense to avoid updating the vendored code? (and not only because of the conflicts :slightly_smiling_face: ) | 12:22 |
kata-irc-bot | <fidencio> you should avoid backporting that patch for sure. | 12:23 |
kata-irc-bot | <fidencio> but you should run `make -C src/runtime handle_vendor` and get the vendored code updated on the stable-2.1 side | 12:24 |
kata-irc-bot | <fidencio> because as it's right now someone consuming a downstream release would face issues | 12:24 |
kata-irc-bot | <fidencio> (as Eduardo faced) | 12:24 |
kata-irc-bot | <ssheribe> @fidencio you mean just to check it works? | 12:30 |
kata-irc-bot | <fidencio> no, I mean to actually update them | 12:30 |
kata-irc-bot | <ssheribe> ok , let me try it | 12:31 |
kata-irc-bot | <ssheribe> @fidencio vendored govmm brings SEV code, I'm not sure whether it make sense | 12:39 |
kata-irc-bot | <fidencio> or do you need to change the code on the runtime side to also support SEV otherwise something will break? | 12:41 |
kata-irc-bot | <ssheribe> IDK I'll push it and we'll see | 12:42 |
kata-irc-bot | <ssheribe> should i avoid "Restrict static checks to go 1.15 and 1.16"? | 12:43 |
kata-irc-bot | <fidencio> Hmm. that's a good question. | 12:44 |
kata-irc-bot | <fidencio> Let's avoid for now and if we face some issue with different version of golang & go mod vendor (which I saw in the past) we re-evaluate | 12:45 |
kata-irc-bot | <dan.middleton> Just watched @david_hay’s cool presentation and demo in the confidential compute meeting. As I come up to speed on kata, I’m curious, how does kata handle container image pulling today? Does it rely on the images to have already been delivered by other k8s tooling for example? | 16:04 |
kata-irc-bot | <fidencio> Yep, currently the pull is done by the CRI runtime (CRI-O or containerd). | 16:07 |
kata-irc-bot | <david_hay> Thanks for the kind feedback @dan.middleton The image(s) either need to be available on the Kubernetes Compute Node, or pulled down on-demand when the Pod is created | 16:07 |
kata-irc-bot | <david_hay> e.g. this is what I used for my demo today ``` apiVersion: v1 kind: Pod metadata: name: nginx-kata spec: runtimeClassName: kata containers: - name: nginx image: nginx``` | 16:07 |
kata-irc-bot | <david_hay> where `image: nginx` describes the image; it's already available on the K8s Compute Node, but K8s allows me to specify an `ImagePullPolicy` to, for example, always pull a fresh copy, whether/not it's already there | 16:08 |
kata-irc-bot | <david_hay> Also, in some environments, it's necessary to "prefetch" the image because the K8s Compute Node(s) aren't connected to the 'net or (b) to ensure that | 16:09 |
kata-irc-bot | <david_hay> The Pod definition can also reference an `ImagePullSecret` to allow one to authenticate to the container registry with the appropriate API key etc. | 16:10 |
kata-irc-bot | <fidencio> @david_hay, if you happen to have the code public, even if based on an older version of the runtime, I'd be quite interested to look at that | 16:11 |
kata-irc-bot | <fidencio> The same goes for the changes you may have done on contaienrd | 16:11 |
kata-irc-bot | <david_hay> Hey @fidencio so *most* the changes are in my `create_container` branch of my fork of Kata Containers Need to commit a few more changes, and also refactor but the `PullImage` etc. stuff is therein | 16:17 |
kata-irc-bot | <dan.middleton> thanks for the additional background! | 16:59 |
kata-irc-bot | <david_hay> No worries, great questions, please keep 'em coming ... Remember, team work makes ..... :slightly_smiling_face: | 16:59 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!