Tuesday, 2019-01-22

*** sameo_ has quit IRC00:32
kata-irc-bot<bergwolf> @samuel.ortiz hi01:36
kata-irc-bot<bergwolf> what's up01:36
*** Bhujay has joined #kata-general04:05
*** Bhujay has quit IRC04:06
*** Bhujay has joined #kata-general04:07
*** Bhujay has quit IRC04:08
*** Bhujay has joined #kata-general04:08
*** Bhujay has quit IRC04:09
*** Bhujay has joined #kata-general04:10
*** Bhujay has quit IRC04:11
*** Bhujay has joined #kata-general04:11
*** Bhujay has quit IRC04:12
*** Bhujay has joined #kata-general04:13
*** Bhujay has quit IRC04:14
*** Bhujay has joined #kata-general04:14
*** stackedsax has joined #kata-general04:26
*** eguan has joined #kata-general04:33
*** Bhujay has quit IRC04:58
*** Bhujay has joined #kata-general05:09
*** Bhujay has quit IRC05:37
*** lpetrut has joined #kata-general07:12
kata-irc-bot<samuel.ortiz> @bergwolf Hey, I was wondering if your raw block device snapshotter is available somewhere?08:14
*** sameo_ has joined #kata-general08:16
kata-irc-bot<bergwolf> @samuel.ortiz here it is https://github.com/bergwolf/containerd/commits/rawblock Still failing on some UT though. image pulling and container creation are working08:16
kata-irc-bot<samuel.ortiz> @bergwolf Thanks alot.08:47
kata-irc-bot<samuel.ortiz> Later today at the AC meeting, we'll be talking about storage for Kata.08:48
kata-irc-bot<bergwolf> cool, I'm looking forward to it08:50
kata-irc-bot<xu> I guess we will have a “bigger” meeting :slightly_smiling_face:08:51
*** gwhaley has joined #kata-general09:29
*** kata-irc-bot has quit IRC10:03
*** kata-irc-bot has joined #kata-general10:05
kata-irc-bot<samuel.ortiz> @bergwolf My brain dump so far: https://gist.github.com/sameo/a878c5f44d7f274a68128fb4ba65d22e10:55
kata-irc-bot<bergwolf> Thanks @samuel.ortiz . A small nit, for containerd snapshotters, the container layer mount/umount is handled by container runtime instead. That's why we can possibly bypass mounting block based rootfs in containerd shimv2 for kata. See https://github.com/kata-containers/runtime/issues/115811:07
kata-irc-bot<bergwolf> btrfs snapshotter in containerd  uses host directory subvolume rather than file volume. When they are used by kata, we need to use 9pfs to pass it to the guest.11:11
kata-irc-bot<bergwolf> It seems cri-o storage interface is very close to docker's original graph driver interface. One thing I like with containerd's snapshotter interface is that it exposes the snapshot mount info and let container runtime handle it. It opens up opportunities for different handling methods for different storage types, -- we can even use the interface to support remote storage like rbd based rootfs.11:20
*** gwhaley has quit IRC12:01
*** stackedsax has quit IRC12:03
*** gwhaley has joined #kata-general13:07
kata-irc-bot<samuel.ortiz> @bergwolf I like the fact that the snapshotter interface is completely decoupled from the container lifecycle.13:10
kata-irc-bot<samuel.ortiz> @bergwolf Thanks for the correction.13:13
*** lpetrut has quit IRC13:20
*** lpetrut has joined #kata-general13:28
kata-irc-bot<samuel.ortiz> @bergwolf How slow is your raw block snapshotter on e.g. an ext4 partition?14:47
kata-irc-bot<bergwolf> It will be pretty slow on ext4. New snapshots are created via `cp --reflink=auto` and ext4 doesn't support reflink14:51
kata-irc-bot<samuel.ortiz> yep.14:52
kata-irc-bot<bergwolf> It works better on btrfs and xfs, or NFSv4214:52
kata-irc-bot<samuel.ortiz> So what do you say are the advantages of creating a dedicated xfs partition and running a raw block snapshotter on it vs using a dedicated partition for e.g. an lvm2 based snapshotter?14:53
kata-irc-bot<bergwolf> You get rid of the lvm setup complexity. No local device is created when it is used with kata (well, in a future sense, kata still needs to change a bit to support bypassing 9pfs).14:55
kata-irc-bot<bergwolf> rawblock will have write amplification that might hurt write performance. OTOH lvm snapshot IIRC also suffers from its own performance problem when there are many layers.14:57
kata-irc-bot<samuel.ortiz> Yes, I was wondering about performance. Because I think lvm setup is almost an implementation detail.14:57
kata-irc-bot<bergwolf> I think we should support both of them and most importantly implement the block level support throughout the stack so that it is easy to use any kind of block storages that support snapshots.15:00
kata-irc-bot<bergwolf> Which snapshotter works best can vary for different users and deployments. We can have a recommendation but we don't block other options.15:02
kata-irc-bot<samuel.ortiz> "throughout the stack": you mean the Kata Containers stack (runtime, etc)? Or more generally the containers stack?15:03
kata-irc-bot<bergwolf> generally the container stack, start from kubernetes (I know that's the hard part :)15:03
kata-irc-bot<samuel.ortiz> Ok, I see.15:04
kata-irc-bot<bergwolf> we should fix the kata part first of course ;) containerd snapshotter + shimv2 already allows us to use block storage directly.15:07
kata-irc-bot<samuel.ortiz> That's the easy one.15:08
kata-irc-bot<bergwolf> that's what I've been doing with rawblock and #115815:08
kata-irc-bot<bergwolf> yup, then we move up the stack to kubernetes external snapshotter and its internal data structures15:09
kata-irc-bot<bergwolf> That will allow us to have rootfs part solved. For the volumes, it is more complicated. We might have to change the OCI spec15:10
*** lpetrut has quit IRC15:46
*** sameo_ has quit IRC17:07
*** gwhaley has quit IRC17:57
*** sameo_ has joined #kata-general18:25
*** lcastell has joined #kata-general19:58
*** lcastell has quit IRC20:00
*** lcastell has joined #kata-general20:01
*** sameo_ has quit IRC20:28
kata-irc-bot<arshad.rad> why kata-runtime doesn't cleanup properly once a docker stopped and even system cleaned by docker eng. it removes rootfs but still the empty directories remained and few meta files! is there any subcommand in this case?21:51
kata-irc-bot<eric.ernst> @sebastien.boeuf —^22:37

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!