Thursday, 2018-12-13

*** zerocoolback has joined #kata-dev00:25
*** dklyle has joined #kata-dev00:53
*** LinuxMe has joined #kata-dev01:28
*** LinuxMe has quit IRC01:29
*** zerocoolback has quit IRC01:54
*** LinuxMe has joined #kata-dev02:22
*** LinuxMe has quit IRC02:26
*** dklyle has quit IRC03:22
*** zerocoolback has joined #kata-dev03:29
*** zerocoolback has quit IRC03:42
*** LinuxMe has joined #kata-dev03:45
*** zerocoolback has joined #kata-dev04:08
*** zerocoolback has quit IRC04:36
*** zerocool_ has joined #kata-dev04:36
*** LinuxMe has quit IRC05:20
*** LinuxMe has joined #kata-dev05:26
*** zerocool_ has quit IRC05:28
*** zerocoolback has joined #kata-dev05:28
*** LinuxMe has quit IRC05:35
*** zerocoolback has quit IRC05:38
*** zerocoolback has joined #kata-dev05:38
*** zerocoolback has quit IRC05:46
*** zerocoolback has joined #kata-dev05:46
*** zerocoolback has joined #kata-dev05:48
*** zerocoolback has quit IRC05:48
*** zerocoolback has joined #kata-dev05:49
*** zerocoolback has joined #kata-dev05:50
*** zerocoolback has joined #kata-dev05:50
*** zerocoolback has joined #kata-dev05:51
*** zerocoolback has joined #kata-dev05:52
*** zerocoolback has quit IRC05:52
*** zerocoolback has joined #kata-dev05:53
*** zerocoolback has joined #kata-dev05:53
*** zerocoolback has joined #kata-dev05:54
*** zerocoolback has quit IRC05:55
*** zerocoolback has joined #kata-dev05:55
*** zerocoolback has joined #kata-dev05:56
*** zerocoolback has quit IRC05:56
*** zerocoolback has joined #kata-dev05:56
*** zerocoolback has joined #kata-dev05:57
*** zerocoolback has joined #kata-dev05:58
*** zerocoolback has quit IRC05:58
*** zerocoolback has joined #kata-dev05:59
*** zerocoolback has joined #kata-dev06:00
*** zerocoolback has joined #kata-dev06:00
*** zerocoolback has joined #kata-dev06:01
*** zerocoolback has quit IRC06:17
*** zerocoolback has joined #kata-dev06:18
*** zerocoolback has quit IRC06:34
*** zerocoolback has joined #kata-dev06:34
*** zerocoolback has quit IRC06:35
*** zerocoolback has joined #kata-dev06:35
*** zerocoolback has quit IRC06:35
*** zerocoolback has joined #kata-dev06:36
*** zerocoolback has joined #kata-dev06:36
*** zerocoolback has quit IRC06:37
*** zerocoolback has joined #kata-dev06:37
*** zerocoolback has joined #kata-dev06:38
*** zerocoolback has quit IRC06:39
*** zerocoolback has joined #kata-dev06:39
*** zerocoolback has quit IRC06:39
*** zerocoolback has joined #kata-dev06:39
*** zerocoolback has quit IRC06:40
*** zerocoolback has joined #kata-dev06:40
*** zerocoolback has quit IRC06:41
*** zerocoolback has joined #kata-dev06:41
*** zerocoolback has quit IRC06:42
*** zerocoolback has joined #kata-dev06:42
*** zerocoolback has quit IRC06:42
*** zerocoolback has joined #kata-dev06:43
*** zerocoolback has joined #kata-dev06:43
*** zerocoolback has joined #kata-dev06:44
*** zerocoolback has quit IRC06:45
*** zerocoolback has joined #kata-dev06:45
*** zerocoolback has quit IRC06:49
*** zerocoolback has joined #kata-dev06:53
*** zerocoolback has quit IRC06:53
*** zerocoolback has joined #kata-dev07:17
*** zerocoolback has quit IRC07:34
*** dklyle has joined #kata-dev08:07
*** dklyle has quit IRC08:27
*** zerocoolback has joined #kata-dev08:30
*** zerocoolback has quit IRC08:33
*** zerocool_ has joined #kata-dev08:33
*** jodh has joined #kata-dev08:34
*** zerocool_ has quit IRC08:44
*** zerocoolback has joined #kata-dev08:49
*** gwhaley has joined #kata-dev09:05
*** davidgiluk has joined #kata-dev09:07
*** zerocoolback has quit IRC10:43
kata-irc-bot<graham.whaley> hi @salvador.fuentes - an update and a query on CI stuff.  First, I enabled the 'slave reboot' hack onto all the metrics build jobs - so now we reboot the slave once for every metrics build - which makes the 'build history' a touch messy, as the reboot jobs themselves will always 'fail', so we have 50% of jobs 'red'. But, hopefully it will settle down the actual metrics jobs and results themselves.11:09
kata-irc-bot<graham.whaley> secondly, it seems I cannot view the 'full logs' of failed jobs right now. Take for instance: http://jenkins.katacontainers.io/job/kata-containers-agent-fedora-master/69/console  - that says the full console log should be '12,919k' - but, when I click the 'full log' link, it doesn't look like I get the full logs - I don't see all the log file grep/dump in the teardown for instance (which is what I was trying to debug a bit ;) ).11:11
kata-irc-botDid we knowingly change anything that restricts the size of the full logs downloaded? I'm also wondering if maybe we are getting short of space or something on the master node (probably not, or it will have fallen over....) thx11:11
*** shrasool has joined #kata-dev12:14
*** LinuxMe has joined #kata-dev12:18
*** gwhaley has quit IRC12:23
kata-irc-bot<mvedovati> maybe someone know the answer: on x86 qemu is configured to boot the rootfs from nvdimm, with memory backend file the kata rootfs image. What's preventing the image file from being modified, since the file system is mounted rw?12:38
*** zerocoolback has joined #kata-dev12:44
kata-irc-bot<mvedovati> If I get it right, the answer is that backend storage is actually not persistent. To make it persistent you need `pmem=on` and qemu built with libpmem12:49
*** LinuxMe has quit IRC13:18
*** gwhaley has joined #kata-dev13:29
*** irclogbot_0 has quit IRC14:00
*** irclogbot_0 has joined #kata-dev14:07
kata-irc-bot<graham.whaley> oh, I was going to ping that to @davidgiluk and @stefenha, as they did DAX stuff for virtio-fs recently - but, I think our irc/slack bot may be down... I don't see things reflected in my irc (but, it could be my end)14:13
davidgiluksees that message14:13
gwhaleyah, and there it is... ;-)14:14
*** irclogbot_0 has quit IRC14:14
davidgilukgwhaley: What's the question?14:15
gwhaley@marcov was asking - when kata mounts the image into the container using nvdimm/DAX, why is that image not writeable - he wondered if it is because we don't pass 'pmem=on' - I thought you might know off the top of your head14:16
gwhaleyrootfs image that is btw14:16
davidgilukah, I don't I'm afraid; I do know there's a whole bunch of different options of how nvdimms appear to the guest (including the consistency stuff) but I've not actually played with them14:21
*** irclogbot_0 has joined #kata-dev14:22
stefanhaWell I think it's a question of MAP_SHARED vs MAP_PRIVATE14:43
kata-irc-bot<salvador.fuentes> Hi @graham.whaley I started to see the console output issue starting this week, my only guess is that the last update introduced this bug. A workaround is to click the `view as plain text` button. I'll try to check the issue today and see if we can get it back to normal14:43
stefanhaIf you don't use shared=on, then changes to the NVDIMM file aren't saved on the host side.14:43
stefanhaSo perhaps what's happening is that QEMU mmaps it with MAP_PRIVATE, the guest is allowed to write to memory, but those pages aren't going to be written out to file again on the host.14:44
stefanhaYou'd need to check the full QEMU command-line14:44
kata-irc-bot<mvedovati> stefanha: thanks, it's indeed `share=on`14:50
stefanhamvedovati; pmem=on guarantees that writes persist but even with just shared=on, some of the writes would make it back to the file.14:59
stefanhamvedovati: It would be worth investigating what you've found more because it's obviously a bad thing if sandbox VMs could write back to the DAX image :-)14:59
stefanhamvedovati: could be a legitimate bug14:59
kata-irc-bot<thierry> ML moderation queue was flushed, thanks @claire15:28
kata-irc-bot<graham.whaley> @salvador.fuentes ah, right - and thanks for the log workaround. the other symptom I saw is that sometimes the ascii extended characters seemed to be leaking into the logs - if you look at the end of the metrics logs they are in **red** ?? - that didn't used to happen ;)15:33
stefanhaThanks @claire!15:37
*** shrasool has quit IRC16:45
kata-irc-bot<thierry> although the ML delivery seems clogged.17:19
kata-irc-bot<thierry> hmm, should be fixed now17:21
*** zerocoolback has quit IRC17:22
*** jodh has quit IRC17:52
*** gwhaley has quit IRC18:35
kata-irc-bot<claire> @stefanha please resend your emails and they should go through now. There was a small glitch with the mailing list that has now been resolved. The emails that you previously sent do show up in the ML archives, but you’ll need to resend them to push to subscriber inboxes. Sorry for the trouble. Thanks for understanding.19:32
*** eernst has joined #kata-dev19:51
kata-irc-bot<eric.ernst> thanks @claire19:54
*** shrasool has joined #kata-dev19:54
*** eernst has quit IRC20:11
*** davidgiluk has quit IRC20:14
*** eernst has joined #kata-dev20:33
*** eernst has quit IRC20:41
*** lpetrut has joined #kata-dev20:53
*** lpetrut has quit IRC22:00
*** LinuxMe has joined #kata-dev22:03
*** dklyle has joined #kata-dev22:05
*** eernst has joined #kata-dev22:08
*** david-lyle has joined #kata-dev22:09
*** dklyle has quit IRC22:12
*** eernst has quit IRC22:18
*** shrasool has quit IRC22:18
*** david-lyle has quit IRC22:23
*** LinuxMe has quit IRC23:10
kata-irc-bot<joshua.reese> wanted to throw out a question here before getting in to details to see if there's any immediate thoughts. we're testing kata with the `sriov-network-device-plugin`, it works great when in `sriov` mode, but when in `vfio` mode the kata runtime is attempting to attach the device twice. once via the qemu cli arguments (due to the netns scan and finding a physical endpoint), then again via hotplug. i believe this is due to the device23:37
kata-irc-botplugin returning device info to k8s when allocating in vfio mode (so it provides the path to the /dev/vfio entry), but not when allocating in sriov modee. i dug around github issues a bit and only came across https://github.com/kata-containers/runtime/pull/872, which doesn't seem related as we aren't using a factory (we're currently running 1.3.0 but will be testing on 1.4.1 shortly).23:37
*** eernst has joined #kata-dev23:43
*** eernst has quit IRC23:48

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