| *** mylinux has joined #kata-general | 00:43 | |
| *** mylinux has quit IRC | 00:47 | |
| *** sjas_ has joined #kata-general | 01:23 | |
| *** sjas has quit IRC | 01:26 | |
| kata-dev-irc-bot | <tv> what all is 9p used for? rootfs and ephemeral both? | 02:17 |
|---|---|---|
| kata-dev-irc-bot | <tv> (obviously not what kubernetes calls PersistentVolumes, i hope) | 02:17 |
| kata-dev-irc-bot | <tv> also, asking from the point of view of the container, not internal details of the agent | 02:18 |
| kata-dev-irc-bot | <tv> reading https://github.com/clearcontainers/runtime/issues/852 and thinking i've seen similar | 02:18 |
| kata-dev-irc-bot | <xu> that depends on the case | 02:19 |
| kata-dev-irc-bot | <xu> If you use it via current containerd/cri-o, it is probably used for rootfs and many volumes. If you use it with frakti or hyperd, it is probably used for only some ephemerals such as the service account token volume | 02:22 |
| kata-dev-irc-bot | <tv> does frakti+kata or such combo do something like transfer container images inside the vm, instead of 9p'ing them>? | 02:23 |
| kata-dev-irc-bot | <xu> no transfer. it’s just about the storage engine. | 02:24 |
| kata-dev-irc-bot | <tv> what mechanism does it use then? write to a block device, unmount, attach to vm? | 02:25 |
| kata-dev-irc-bot | <tv> i couldn't find anything explaining these details in the doc side, haven't delved very deep into code yet | 02:25 |
| kata-dev-irc-bot | <xu> the image/rootfs here is tend to storage as block, and pass the block to runtime instead of mount in host and pass filesystem to guest | 02:25 |
| kata-dev-irc-bot | <tv> and then ephemeral is block device that's mounted inside the vm, and presto you get quotas for free?-) | 02:26 |
| kata-dev-irc-bot | <xu> if containerd/crio mounted the rootfs as filesystem, it is impossible to clean pass it to vm as block dev | 02:27 |
| kata-dev-irc-bot | <tv> yeah that's kinda why i'm asking | 02:27 |
| kata-dev-irc-bot | <xu> If possible, we will try to avoid pass a filesystem being mounted on host | 02:28 |
| kata-dev-irc-bot | <tv> yeah while being at the mercy of the conventions of whatever the caller wants; makes sense | 02:30 |
| kata-dev-irc-bot | <tv> hopefully all the relevant things get standardized in a way that works for you | 02:30 |
| kata-dev-irc-bot | <xu> we are working on this, frakti is going to support kata runtime when the runtime merging is done | 02:34 |
| kata-dev-irc-bot | <tv> i'm a little unclear on the scope of e.g. frakti vs kata; where does the OCI api sit? | 02:36 |
| kata-dev-irc-bot | <xu> frakti is a CRI daemon, kubelet calls frakti via CRI | 02:36 |
| kata-dev-irc-bot | <tv> (i'm sorry i'm probably confusing CRI and OCI, too) | 02:37 |
| kata-dev-irc-bot | <xu> and frakti calls runV/kata with their API instead of the commandline. The OCI spec will be shipped in the API | 02:38 |
| kata-dev-irc-bot | <tv> "the standard api kube wants to see" = CRI is what i meant | 02:38 |
| kata-dev-irc-bot | <xu> Let me show you the picture | 02:38 |
| kata-dev-irc-bot | <tv> so kata isn't CRI? | 02:38 |
| kata-dev-irc-bot | <tv> and frakti is a CRI-to-kata adapter? | 02:38 |
| kata-dev-irc-bot | <xu> https://docs.google.com/document/d/109pxj-90Ly58ma8CoeRKcMoPWBD0G911E53MeK2zhhA/edit | 02:39 |
| kata-dev-irc-bot | <xu> this doc describes how the kata runtime will work with kubernetes | 02:39 |
| kata-dev-irc-bot | <tv> thanks! | 02:39 |
| *** mylinux has joined #kata-general | 03:41 | |
| *** mylinux has quit IRC | 03:45 | |
| kata-dev-irc-bot | <tv> fwiw likely typo in that doc: "Frakti is a more CRI specified runtime" | 04:10 |
| kata-dev-irc-bot | <tv> or at least confusing sentence | 04:10 |
| kata-dev-irc-bot | <tv> okay so Frakti will talk directly to Kata Agent, bypassing the need for Proxy and Shim? | 04:12 |
| kata-dev-irc-bot | <tv> i was getting worried about all these glue layers | 04:13 |
| kata-dev-irc-bot | <tv> if what i understood is correct, this is much saner | 04:14 |
| kata-dev-irc-bot | <tv> (even if i would have personally aimed to putting frakti and kata in one project ;) | 04:14 |
| kata-dev-irc-bot | <tv> okay so with Frakti, what splits trusted/untrusted workloads? | 04:20 |
| kata-dev-irc-bot | <tv> if you use cri-o for that, you need OCI not CRI underneath cri-o | 04:20 |
| kata-dev-irc-bot | <tv> hrmm runtime.frakti.alpha.kubernetes.io/OSContainer is said to delegate to Docker | 04:21 |
| kata-dev-irc-bot | <tv> OCI/CRI would be saner than explicitly docker, though | 04:22 |
| kata-dev-irc-bot | <xu> using kata runtime lib (or runv lib currently), don’t need additional proxy/shim processes | 04:24 |
| kata-dev-irc-bot | <tv> "FYI, we decided to have Kata agent to mixed handle Linux container and VM container, so no need to maintain a cache or CRI proxy at all." https://github.com/kubernetes/frakti/issues/245#issuecomment-350583493 | 04:33 |
| kata-dev-irc-bot | <tv> what does resouer mean by "to mixed handle" | 04:34 |
| kata-dev-irc-bot | <xu> this is still in proposal stage. it is possible to run kata agent in both vm or a namespace, the former is how it is designed, and for the latter, it is a possible unified way to support container and vm with kata components. As the kata agent is based on libcontainer, it is indeed possible. | 04:38 |
| kata-dev-irc-bot | <tv> so many glue layers with overlapping functionality :( | 04:39 |
| kata-dev-irc-bot | <xu> frakti is the way with fewest indirect layers | 04:40 |
| kata-dev-irc-bot | <tv> so it seems, but my hopes are even higher ;) | 04:40 |
| *** jodh has joined #kata-general | 07:29 | |
| *** jodh has joined #kata-general | 07:29 | |
| *** kasidit has joined #kata-general | 08:06 | |
| *** kasidit has quit IRC | 08:22 | |
| kata-dev-irc-bot | <kasidit.vasabilab> hi, I am new to container but use qemu a lot. I have tried kata-runtime and cc-runtime. Would it be possible to use raw image and qcow2 instead of 9p? I'd to checkpoint or migrate a pod. Thank you. | 08:32 |
| *** gwhaley has joined #kata-general | 09:05 | |
| kata-dev-irc-bot | <samuel.ortiz> @tv Storage documentation for Clear Containers: https://github.com/clearcontainers/runtime/blob/master/docs/architecture/architecture.md#storage | 09:09 |
| kata-dev-irc-bot | <samuel.ortiz> @tv @xu when using cri-containerd or CRI-O, the 9pfs usage is entirely dependent on the overlay that you give to the CRI. If it's block based, 9pfs will only be used for volumes, not for the container rootfs. | 09:12 |
| kata-dev-irc-bot | <samuel.ortiz> @kasidit.vasabilab if your container rootfs is a raw image or qcow2, it may be possible. But unless you're using a custom overlay driver, it won't be that way. | 09:18 |
| *** mylinux has joined #kata-general | 09:31 | |
| *** mylinux has quit IRC | 09:36 | |
| kata-dev-irc-bot | <kasidit.vasabilab> @samuel.ortiz I got it now. thank you. | 09:50 |
| kata-dev-irc-bot | <xu> @samuel.ortiz but in that case, if touch files in the rootfs from host, it may break the superblock of the filesystem | 10:02 |
| *** mylinux has joined #kata-general | 10:09 | |
| *** mylinux has quit IRC | 10:13 | |
| kata-dev-irc-bot | <kasidit.vasabilab> @xu, @samuel.ortiz, Thank you for your insights. | 11:51 |
| * gwhaley missed some of this thread - @samuel.ortiz @xu - so, if writing to a block mounted rootfs is dangerous, we should mount them readonly then? | 11:53 | |
| kata-dev-irc-bot | <xu> @graham.whaley the mount operation on the host is not handled by kata, and the mount operation on the guest should decided by the spec/request as well. And even if you mount it read-only, there still may be some metadata writing ops. The point is, try double mounting a local filesystem is a temp workaround. | 11:58 |
| *** gwhaley has quit IRC | 12:20 | |
| *** mylinux has joined #kata-general | 13:32 | |
| *** mylinux has quit IRC | 13:37 | |
| *** gwhaley has joined #kata-general | 13:50 | |
| *** mylinux has joined #kata-general | 14:11 | |
| kata-dev-irc-bot | <salvador.fuentes> @verytired1 hi, I tried to send a mail to kata-dev mailing list a couple of times , but seems that it is not being delivered, do you know if something is not working? I can see the message got here http://lists.katacontainers.io/pipermail/kata-dev/2018-February/000025.html | 14:41 |
| kata-dev-irc-bot | <verytired1> @salvador.fuentes it's being delivered to the list and i received them | 14:55 |
| gwhaley | might be at our end then @salvador.fuentes - as you know @jodh and I did not see them either :-/ | 14:57 |
| gwhaley | but we have seen other emails... | 14:57 |
| kata-dev-irc-bot | <salvador.fuentes> @verytired1 @graham.whaley weird... | 14:58 |
| kata-dev-irc-bot | <verytired1> are these all @intel.com addresses? | 14:58 |
| kata-dev-irc-bot | <salvador.fuentes> yes | 14:59 |
| kata-dev-irc-bot | <verytired1> ok. i'll see if i can find any delivery failures in the logs with more info | 15:01 |
| kata-dev-irc-bot | <salvador.fuentes> thanks @verytired1 | 15:02 |
| gwhaley | I've kicked off an internal thread to try and find the right person to check if they got to our servers, and then what happened etc. If I get any updates I'll send back here | 15:17 |
| *** jodh_ has joined #kata-general | 15:38 | |
| *** jodh has quit IRC | 15:38 | |
| *** jodh_ has quit IRC | 15:39 | |
| *** jodh has joined #kata-general | 15:39 | |
| *** jodh has joined #kata-general | 15:39 | |
| kata-dev-irc-bot | <verytired1> for all of the intel.com addresses i'm seeing C="250 ok: Message 969658 accepted" on the mail server side | 16:37 |
| kata-dev-irc-bot | <verytired1> @salvador.fuentes i DM-ed you the log line with your address which also identifies the intel mail server that responded | 16:38 |
| kata-dev-irc-bot | <salvador.fuentes> thanks @verytired1 | 16:40 |
| *** mylinux has quit IRC | 17:08 | |
| *** mylinux has joined #kata-general | 17:26 | |
| *** jodh has quit IRC | 18:02 | |
| *** archana has joined #kata-general | 18:38 | |
| *** archana has quit IRC | 19:34 | |
| *** mylinux has quit IRC | 20:14 | |
| *** mylinux has joined #kata-general | 20:20 | |
| *** gwhaley has quit IRC | 20:29 | |
| *** mylinux has quit IRC | 23:45 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!