Monday, 2018-06-04

« Sunday, 2018-06-03 Index Tuesday, 2018-06-05 »
*** dlw has joined #kata-dev01:15
*** zerocoolback has joined #kata-dev02:48
*** zerocoolback has quit IRC02:51
*** zerocool_ has joined #kata-dev02:51
*** eernst has joined #kata-dev03:35
*** LinuxMe has joined #kata-dev03:48
*** LinuxMe has quit IRC03:53
*** LinuxMe has joined #kata-dev04:11
*** sameo has joined #kata-dev04:13
*** LinuxMe has quit IRC04:15
kata-dev-irc-bot<eric.ernst> @jose.carlos.venegas.m - Can you provide feedback on how --privileged is handled in containerd case?04:53
kata-dev-irc-bot<eric.ernst> i.e., it would be great to have a containerd equivalent table, like what we have in the crio section of documentation: https://github.com/kata-containers/documentation/blob/master/architecture.md#mixing-vm-based-and-namespace-based-runtimes04:54
*** eernst has quit IRC05:08
*** zerocool_ has quit IRC05:14
*** zerocoolback has joined #kata-dev05:35
*** sameo has quit IRC05:55
*** zerocoolback has quit IRC05:55
*** zerocoolback has joined #kata-dev06:05
*** dlw1 has joined #kata-dev06:36
*** dlw has quit IRC06:38
*** dlw1 is now known as dlw06:38
*** zerocoolback has quit IRC06:41
*** zerocoolback has joined #kata-dev06:42
*** zerocoolback has joined #kata-dev06:43
*** zerocoolback has quit IRC06:43
*** zerocoolback has joined #kata-dev06:43
*** zerocoolback has joined #kata-dev06:44
*** zerocoolback has quit IRC06:44
*** zerocoolback has joined #kata-dev06:45
*** zerocoolback has quit IRC06:45
*** jodh has joined #kata-dev07:51
*** davidgiluk has joined #kata-dev07:54
*** gwhaley has joined #kata-dev08:02
*** JerryLiu has quit IRC09:06
*** kgz has quit IRC10:20
*** kgz has joined #kata-dev10:28
*** gwhaley has quit IRC11:14
*** dlw has quit IRC11:42
*** zerocoolback has joined #kata-dev11:48
*** changcheng has joined #kata-dev11:53
*** zerocoolback has quit IRC12:06
*** zerocoolback has joined #kata-dev12:07
*** zerocoolback has quit IRC12:08
*** gwhaley has joined #kata-dev12:24
*** fuentess has joined #kata-dev12:27
*** LinuxMe has joined #kata-dev12:28
*** zerocoolback has joined #kata-dev12:42
*** zerocoolback has quit IRC12:48
*** zerocoolback has joined #kata-dev12:48
kata-dev-irc-bot<mnaser> morning everyone12:48
kata-dev-irc-bot<mnaser> kata CI happens in Jenkins, right?12:48
kata-dev-irc-bot<salvador.fuentes> hi @mnaser, yes, that's correct12:51
kata-dev-irc-bot<mnaser> @salvador.fuentes in that case, just a heads about about this -- https://jenkins.io/security/advisory/2018-06-04/12:51
kata-dev-irc-bot<salvador.fuentes> @mnaser, thanks, will take a look12:52
*** zerocoolback has quit IRC12:58
gwhaleythx @mnaser - I believe we use at least two of those plugins13:03
mnaserwell sorry for the extra work this morning :)13:04
*** LinuxMe has quit IRC13:05
stefanhagwhaley: Do you have time to chat about what Kata's requirements are in terms of shared file systems?13:05
*** zerocoolback has joined #kata-dev13:05
stefanhagwhaley: You mentioned that virtio-9p and NFS don't pass tests you are running.  And I've read about performance concerns (hence the virtio-blk/scsi alternative) on GitHub.13:06
gwhaleyhi stefanha. sure. We will probably want some others in the loop (like Eric and amshinde) as well.13:07
gwhaleyYeah, pretty much those are the two key areas :-) - performance and compatability13:07
*** zerocoolback has quit IRC13:07
stefanhagwhaley: Another quality I'm curious about is coherency, because containers with a shared volume expect local file system semantics.13:08
gwhaleyThey two main compatability issues we have seen with 9p have been the unlink/fstat type idiom (trying to access a file that has been unlinked - quite often ends up trying to find it by pathname not inode ref)13:08
stefanhagwhaley: Ah, right!  I see.13:08
gwhaleyand the mmap'ing files is something we see a number of DB type containers do quite often, which fails for certain mmaps13:08
stefanhagwhaley: Do you know when mmap fails?13:09
gwhaleythe unlink one - there is a long and old thread out on the net about it... let me find you an old ref from last time I dug..13:09
gwhaleymmap - let me look - I think 9p does not support one of the mmap options (but I forget which..)13:09
stefanhaI'm not aware of mmap limitations with NFS but there is the coherency problem:13:10
stefanhaif container A mmaps the file and writes to it,13:10
stefanhathen container B's mmap isn't guaranteed to show that new write.13:10
stefanhaI guess some pods may have containers that do this.  They rely on bind mount's local file system semantics, which doesn't work for NFS or virtio-9p.13:11
stefanhaI was curious if this was ever a concern for you13:11
gwhaleylooks like (old thread) 9p does not support mmap_shared on readonly FS https://github.com/intel/cc-oci-runtime/issues/949#issuecomment-31619231613:11
gwhaleyI don't think we've run into the shared FS coherency issue on 9p - *but* - that does sound potentially like a real issue.13:12
gwhaley9p and caching is an 'interesting' area - iirc, the original 9p paper says 'do not do it' - but, the options are there for us, and it gives us more performance.13:12
*** zerocoolback has joined #kata-dev13:13
stefanhagwhaley: I don't see "cache=" in Kata.  So I guess Kata doesn't use the 9P cache by default?13:14
gwhaleystefanha: here is an old thread about the unlink stuff over on rkt, including a link to the ancient upstream chatter: https://github.com/rkt/rkt/pull/3475#issuecomment-26800605413:15
stefanhagwhaley: Great, thanks for finding the links13:15
*** zerocoolback has quit IRC13:15
gwhaleysince then there has been another set of patches iirc, but they are still not upstream in the kernel. 9p maintainership recently got a little bit of a boost though, and AndrewMorton has been reviewing patches13:15
gwhaleyiirc, the fundamental issue with the unlink() is that the 9p API/philosophy does not align well with the linux/VFS API at that point - so there appears to be no perfect/simple solution :-(13:16
stefanhaI see13:17
stefanhagwhaley: I'm thinking about options for improving shared file systems, which is necessary for shared volumes (can't be solved easily with block devices)13:19
stefanhagwhaley: In the NFS GitHub issue there was a questions about the specifics of the tests you ran.  Would it be possible for you to post that information?13:19
stefanhahttps://github.com/kata-containers/runtime/issues/279#issuecomment-38669396413:19
gwhaleystefanha: ah, sure. I was away at that time for 2 weeks, so that got lost in the 'mega email cleanup' :-)13:22
gwhaleylet me stick that on my list and I'll try to get to it soon.13:22
gwhaleyThe tests were not complex13:22
*** zerocoolback has joined #kata-dev13:22
*** LinuxMe_ has joined #kata-dev13:31
*** lamego has joined #kata-dev13:34
stefanhagwhaley: Cool, thank you!13:35
gwhaleystefanha: I should also point you at this: https://github.com/clearcontainers/vhost-9pfs which I think is still WIP. I'll stick a ref on the Issue as well and pull in the author13:39
stefanhagwhaley: Thanks13:43
stefanhagwhaley: Do you know why they decided to implement the 9p server in the kernel?13:45
gwhaleymainly performance I think stefanha, so we can bypass the whole qemuside 9p server - but also I think they were hoping to clear up some of the compatibilty issues as well13:45
stefanhaThe kernel module is just calling vfs_*() though, it's not doing anything that is fundamentally faster in the kernel.13:46
gwhaleyavoids the usermode switch I think was the basis - we would catch and handle the 9p requests in the kernel rather than have to schedule qemu in to then pass the request back to the kernel fs layer iirc13:47
kata-dev-irc-bot<sebastien.boeuf> @graham.whaley well, if you do that, you put more attack surface into the kernel, and if we need to patch it, it will have to go through a new kernel version. Having 9p emulation in userspace is easier for patching13:49
stefanhavhost runs in a kernel thread, so that needs to be scheduled.13:49
gwhaley:-) true @sebastien.boeuf. And none of us want to carry around a kernel module to load do we :-)13:50
stefanhaPutting things in the kernel doesn't automatically make them faster, so I was curious if there was a specific feature that this can take advantage of.13:50
stefanhaAt first glance it's not clear that this would win over an optimized userspace implementation.13:51
gwhaleyI think we'd have to ask @adrinam or @samuel.ortiz if they remember the details. I think we did not (yet?) find the time to properly evaluate that work13:52
*** cdent has joined #kata-dev13:54
*** dlw has joined #kata-dev14:12
*** annabelleB has joined #kata-dev14:15
*** devimc has joined #kata-dev14:28
*** LinuxMe_ has quit IRC14:36
*** LinuxMe has joined #kata-dev14:41
*** cdent has quit IRC14:44
*** dlw has quit IRC14:46
*** eernst has joined #kata-dev14:47
*** eernst has quit IRC14:49
*** eernst has joined #kata-dev14:50
*** cdent has joined #kata-dev15:10
*** fuentess has quit IRC15:18
*** fuentess has joined #kata-dev15:19
*** sameo has joined #kata-dev15:38
kata-dev-irc-bot<anne> WRT Kata infra team, this ML post from the OpenStack infra team might be of interest: @eric.ernst @xu (I missed this and @mnaser kindly pointed it out :slightly_smiling_face: ) http://lists.openstack.org/pipermail/openstack-dev/2018-May/130896.html15:47
*** sameo has quit IRC15:54
*** sameo has joined #kata-dev16:10
*** eernst has quit IRC16:27
*** annabelleB has quit IRC16:43
*** annabelleB has joined #kata-dev16:52
*** jodh has quit IRC17:01
*** gwhaley has quit IRC17:03
*** LinuxMe has quit IRC17:07
*** eernst has joined #kata-dev17:16
*** LinuxMe has joined #kata-dev17:22
*** zerocoolback has quit IRC17:22
*** LinuxMe has quit IRC17:34
kata-dev-irc-bot<anne> hey crew--there is a new zoom link for our weekly meetings. If you use the google calendar, this has been updated. If you use the iCal file, you'll want to grab the new one on the katacontainers.io homepage.17:38
*** LinuxMe has joined #kata-dev17:38
*** sameo has quit IRC17:42
*** sjas has joined #kata-dev17:49
*** sjas has quit IRC17:52
*** sjas has joined #kata-dev17:52
*** annabelleB has quit IRC18:33
*** annabelleB has joined #kata-dev18:37
*** LinuxMe has quit IRC18:38
*** LinuxMe has joined #kata-dev18:54
*** eernst has quit IRC19:01
*** eernst has joined #kata-dev19:02
*** cdent has quit IRC19:05
*** oikiki has joined #kata-dev19:06
*** davidgiluk has quit IRC19:06
*** eernst has quit IRC19:09
*** eernst has joined #kata-dev19:54
*** cdent has joined #kata-dev19:57
*** eernst has quit IRC20:01
*** eernst has joined #kata-dev20:02
*** eernst has quit IRC20:02
*** eernst_ has joined #kata-dev20:02
*** eernst_ has quit IRC20:03
*** annabelleB has quit IRC20:07
*** annabelleB has joined #kata-dev20:22
*** mcastelino has joined #kata-dev20:47
*** annabelleB has quit IRC21:00
*** annabelleB has joined #kata-dev21:02
*** eernst has joined #kata-dev21:03
*** sameo has joined #kata-dev21:12
*** fuentess has quit IRC21:31
*** LinuxMe has quit IRC21:32
*** devimc has quit IRC21:48
*** LinuxMe has joined #kata-dev22:04
*** LinuxMe has quit IRC22:09
*** mcastelino has quit IRC22:12
*** mcastelino has joined #kata-dev22:14
*** lamego has quit IRC22:18
*** annabelleB has quit IRC22:28
*** oikiki has quit IRC22:37
*** oikiki has joined #kata-dev22:39
*** sameo has quit IRC22:42
*** mcastelino has quit IRC22:59
*** cdent_ has joined #kata-dev23:03
*** oikiki has quit IRC23:03
*** cdent has quit IRC23:04
*** cdent_ is now known as cdent23:04
*** oikiki has joined #kata-dev23:07
*** annabelleB has joined #kata-dev23:08
*** oikiki has quit IRC23:15
*** oikiki has joined #kata-dev23:17
*** LinuxMe has joined #kata-dev23:18
*** LinuxMe has quit IRC23:23
*** cdent_ has joined #kata-dev23:24
*** cdent has quit IRC23:26
*** cdent_ is now known as cdent23:26
*** zerocoolback has joined #kata-dev23:55
*** LinuxMe has joined #kata-dev23:59
« Sunday, 2018-06-03 Index Tuesday, 2018-06-05 »

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