| kata-irc-bot | <samuel.ortiz> Hey Dave, Jakob | 08:17 |
|---|---|---|
| kata-irc-bot | <samuel.ortiz> @david_hay Just so I understand: your `kata-agent` pull/unpack functions inside the agent invoke skopeo and umoci, right? | 08:18 |
| kata-irc-bot | <samuel.ortiz> @david_hay And iiuc, you’re triggering those functions from an additional agent grpc endpoint that you call from the runtime? | 08:19 |
| kata-irc-bot | <david_hay> Yep, that's correct - I've added `PullImage` and `VerifyImage` functions that leverage `skopeo` inside the Pod Sandbox and `UnpackImage` using `umoci` This means that I end up with three subdirectories - `/tmp/image_manifest` which contains the "normal" image with its signature, `/tmp/image_oci` which contains the image _sans_ signature ( I use `skopeo` to re-copy the image without its signature because `umoci` doesn't know what | 08:29 |
| kata-irc-bot | to do with a signed image ) and `/tmp/image_bundle` which contains the image in a bundle format ... e.g. `ls -al /tmp/image_bundle/` ```total 320 drwx------ 4 root root 140 Jul 27 07:39 . drwxrwxrwt 6 root root 120 Jul 27 06:52 .. -rw-r--r-- 1 root root 3272 Jul 27 06:52 config.json drwxr-xr-x 20 root root 420 Jan 1 1970 rootfs -rw-r--r-- 1 root root 315410 Jul 27 06:52 | 08:29 |
| kata-irc-bot | sha256_40859eb4d97466e50982d00c0cfe63b61e635ad00f604ca5363784d801013327.mtree -rw-r--r-- 1 root root 373 Jul 27 06:52 umoci.json``` Right now, I'm using `/tmp` as it's read/write inside the Pod Sandbox; we're working on another piece of work to make a piece of block storage available to the Sandbox when it starts up, which we'll use for `PullImage` etc. We can then LUKS the heck out of that block storage in due course ...... | 08:29 |
| kata-irc-bot | <david_hay> As you say, thus far, we've just extended `kata-agent-ctl` to poke the new gRPC endpoints for `PullImage` etc. | 08:30 |
| kata-irc-bot | <samuel.ortiz> Looking at the agent code now… | 08:31 |
| kata-irc-bot | <david_hay> This morning, I was thinking about the existing `CreateContainer` command that `kata-agent-ctl` exposes, specifically in terms of what that wants for its input parameter - wondering whether I can leverage the CID Even read the architecture/flow - https://github.com/kata-containers/documentation/blob/master/design/architecture.md - whilst out walking this morning :slightly_smiling_face: | 08:32 |
| kata-irc-bot | <david_hay> https://github.com/kata-containers/documentation/blob/master/design/architecture.md#create etc. | 08:32 |
| kata-irc-bot | <samuel.ortiz> @david_hay Have you looked at `setup_bundle` from the `rpc.rs` agent code? | 08:35 |
| kata-irc-bot | <samuel.ortiz> That’s where it mounts the container bundle from e.g. a virtiofs mount point from the host into a guest mount point (at `/run/kata-containers/<cid>`) | 08:38 |
| kata-irc-bot | <samuel.ortiz> I guess if you’d update the spec `setup_bundle` gets to use e.g. `/tmp/your-pulled-bundle` as the root path, it might work? | 08:39 |
| kata-irc-bot | <david_hay> Yeah, and I was trying to work out how to leverage that - if I understand correctly, that function creates the bundle ( including `config.json` etc. ) *inside* the Pod Sandbox within `CONTAINER_BASE` under a `cid` subdirectory e.g. `48a122f9cd5824a804909c00dfb5ce57c645e49f1dc9836ba7fb4a06b731eb99` | 08:39 |
| kata-irc-bot | <samuel.ortiz> It *mounts* the existing bundle passed from the host. | 08:40 |
| kata-irc-bot | <david_hay> Right, sorry, poor choice of language on my part ... | 08:40 |
| kata-irc-bot | <samuel.ortiz> No worries :slightly_smiling_face: | 08:40 |
| kata-irc-bot | <samuel.ortiz> No pedantism from my side, I just meant that it basically takes an existing bundle and mount it into the guest fs. | 08:41 |
| kata-irc-bot | <david_hay> So I was thinking similar - instead of having `CONTAINER_BASE` pointing to `/var/run` I have it pointing at `/tmp/image_bundle` .... Of course, I can't afford to break the existing `CONTAINER_BASE` constant and `setup_bundle` otherwise we'll never get the original "parent" container / Pod Sandbox to come up .... | 08:41 |
| kata-irc-bot | <david_hay> So I'm effectively creating a duplicate `setup_bundle` function using a duplicate `CONTAINER_BASE` constant | 08:42 |
| kata-irc-bot | <samuel.ortiz> I would actually let setup_bundle use your /tmp/image_bundle as its root and let it mount into its expected mount point | 08:42 |
| kata-irc-bot | <david_hay> Ah.... | 08:42 |
| kata-irc-bot | <samuel.ortiz> So that after that the code flow is completely unchanged. | 08:42 |
| kata-irc-bot | <samuel.ortiz> If you can have the spec argument passed to setup_bundle point to /tmp/image_bundle as its root, you should be good. | 08:43 |
| kata-irc-bot | <david_hay> Right, so the existing function has `spec_root` https://github.com/kata-containers/kata-containers/blob/fff76d5e903ac7a61ca9858a907b3714894f40e0/src/agent/src/rpc.rs#L1620 | 08:43 |
| kata-irc-bot | <samuel.ortiz> Exactly. | 08:44 |
| kata-irc-bot | <david_hay> Great minds think alike .... | 08:44 |
| kata-irc-bot | <david_hay> I think we only invoke `setup_bundle` once here https://github.com/kata-containers/kata-containers/blob/fff76d5e903ac7a61ca9858a907b3714894f40e0/src/agent/src/rpc.rs#L172 | 08:44 |
| kata-irc-bot | <samuel.ortiz> So if you can modify the received spec from there, and change the root to point to your pulled bundle, then after that the code flow would be unchanged. | 08:45 |
| kata-irc-bot | <david_hay> passing in the CID ( Container ID ) and the OCI - I was struggling to work out that the OCI is .... it "feels" like that'd be the `config.json` from the bundle | 08:45 |
| kata-irc-bot | <samuel.ortiz> Just a sec… | 08:48 |
| kata-irc-bot | <david_hay> No worries, mate :slightly_smiling_face: | 08:49 |
| kata-irc-bot | <samuel.ortiz> The oci passed to setup_bundle is the spec we got from grpc (`req.OCI`) that gets converted to an `oci::Spec` structure, as defined in `agent/oci/src/lib.rs` | 08:52 |
| kata-irc-bot | <samuel.ortiz> The conversion is done by the rustjail (weird…) `grpc_to_oci` routine. | 08:53 |
| kata-irc-bot | <david_hay> Ah, OK, as you say, weird :slightly_smiling_face: | 08:54 |
| kata-irc-bot | <david_hay> Thanks for this, mate, really really appreciate your assistance - will tinker with the code shortly, and report back :slightly_smiling_face: | 08:54 |
| kata-irc-bot | <samuel.ortiz> Thanks for working on this…For our v0/PoC, I’d do_create_containers so that the converted grpc.req.OCI structure (i.e. the oci::Spec one) gets its root field modified if there is an existing /tmp/bundles/<cid> bundle for it that you’d have pulled previously. | 08:56 |
| kata-irc-bot | <david_hay> Yeah, that's my plan ..... | 08:57 |
| kata-irc-bot | <david_hay> Gotta start somewhere, right :slightly_smiling_face: MVP all the way | 08:57 |
| kata-irc-bot | <samuel.ortiz> Yup. | 08:58 |
| kata-irc-bot | <samuel.ortiz> Iterate and improve… | 08:58 |
| kata-irc-bot | <david_hay> Yeah, only challenge was that is that `/run/kata-containers` is not read-write when I was hacking around inside the Pod Sandbox via the shell .... but, of course, the Agent can write to it ... so will tinker further .... | 09:05 |
| kata-irc-bot | <fidencio> @sunny, @eric.ernst, @samuel.ortiz, we're facing some issues with the Slack's invitation link. Seems it expires in a way too short timeframe. What's the best way to work this around? | 16:51 |
| kata-irc-bot | <sunny> Hi @fidencio thanks for flagging. I created this link that won’t expire and I’ve updated it on Kata website. Is there anywhere else that you saw the old link? | 16:53 |
| kata-irc-bot | <will> https://github.com/kata-containers/community | 16:56 |
| kata-irc-bot | <will> | 16:56 |
| kata-irc-bot | <will> when I clicked it said it had expired | 16:56 |
| kata-irc-bot | <cameron4mcdermott> I also found that the link was out of date on the IIRC as well | 16:58 |
| kata-irc-bot | <rco> My attempts at installing cri-o v1.21.2 on minikube (v1.22.0) have been unsuccessful. First I tried installing it on a running minikube vm and restarting the cri-o and kubelet services, and then I tried building a new minikube iso with the newer cri-o version already installed. In the former case pods entered a crash loop permanently, and in the latter case the kubelet never came up during initial startup. My next attempt was to make | 17:00 |
| kata-irc-bot | changes to the crio.conf.d/99-kata-deploy and the runtimeClasses.yml, as well as moving the containershim binaries into /usr/bin and rename them. In all cases I did `s/kata-qemu/kataqemu` and `s/kata-fc/katafc`, etc. I think I got a little further with that attempt, because I briefly saw a qemu process running. So the shim got invoked by cri-o, which is progress. However, the pod still fails to create, this time with `Failed to check if grpc | 17:00 |
| kata-irc-bot | server is working: rpc error: code = DeadlineEx ceeded desc = timed out connecting to vsock 1601943095:1024`. I'm checking the crio.service logs now but it was set to debug level so there's a lot to dig through. | 17:00 |
| kata-irc-bot | <sunny> thanks @cameron4mcdermott @will! I can update the IRC link. @fidencio would you be able to edit the https://github.com/kata-containers/community? | 17:31 |
| kata-irc-bot | <fidencio> I will do later Today! | 17:35 |
| kata-irc-bot | <sunny> thank you!! | 17:48 |
| kata-irc-bot | <fidencio> https://github.com/kata-containers/community/pull/224 | 18:08 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!