Monday, 2018-06-11

*** yingjun has joined #kata-dev00:21
*** yingjun has quit IRC00:37
*** yingjun has joined #kata-dev00:51
*** zerocoolback has joined #kata-dev00:58
*** zerocoolback has quit IRC01:03
*** zerocoolback has joined #kata-dev01:03
*** zerocoolback has quit IRC01:08
*** dlw has joined #kata-dev01:48
*** yingjun has quit IRC02:22
*** zerocoolback has joined #kata-dev02:40
*** yingjun has joined #kata-dev02:45
*** yingjun has quit IRC03:20
*** zerocoolback has quit IRC03:30
*** zerocoolback has joined #kata-dev03:30
*** zerocoolback has quit IRC03:31
*** zerocoolback has joined #kata-dev03:31
*** zerocoolback has quit IRC03:36
*** zerocoolback has joined #kata-dev03:37
*** zerocoolback has quit IRC03:37
*** zerocoolback has joined #kata-dev03:38
*** zerocoolback has joined #kata-dev03:39
*** zerocoolback has quit IRC03:40
*** zerocoolback has joined #kata-dev03:40
*** zerocoolback has quit IRC03:40
*** zerocoolback has joined #kata-dev03:41
*** zerocoolback has quit IRC03:41
*** dklyle has joined #kata-dev04:25
*** dklyle has quit IRC04:31
*** psuriset has joined #kata-dev04:39
*** yingjun has joined #kata-dev04:47
*** yingjun has quit IRC04:51
*** jodh has joined #kata-dev05:49
*** yingjun has joined #kata-dev05:54
*** yingjun has quit IRC06:15
*** sjas has joined #kata-dev06:40
*** jodh has quit IRC07:09
*** jodh has joined #kata-dev07:11
*** jodh has quit IRC07:11
*** jodh has joined #kata-dev07:11
*** sameo has joined #kata-dev07:36
*** zerocoolback has joined #kata-dev07:42
*** zerocoolback has quit IRC07:42
*** zerocoolback has joined #kata-dev07:43
*** zerocoolback has quit IRC07:43
*** zerocoolback has joined #kata-dev07:44
*** zerocoolback has quit IRC07:44
*** zerocoolback has joined #kata-dev07:44
*** zerocoolback has quit IRC07:45
*** zerocoolback has joined #kata-dev07:45
*** zerocoolback has quit IRC07:46
*** zerocoolback has joined #kata-dev07:46
*** zerocoolback has quit IRC07:46
*** davidgiluk has joined #kata-dev07:55
*** gwhaley has joined #kata-dev08:02
kata-irc-bot<niteshkonkar007> Do we have a documentation for what all kernel configs ``` must ``` be enabled when using it with kata? One can always refer ther kernel config file given in the github, but is it mentioned anywhere explicitly.09:12
kata-irc-bot<james.o.hunt> Hi @niteshkonkar007 - no, but I agree it would be *very* useful. I'm wondering how easy that be to do - wdyt @graham.whaley, @eric.ernst?09:18
gwhaleyyeah, James was just asking me that.... I think we could have a short list of some things that *must* be configured, and it would be nice if we could also have some reasoning/explanatory text to go along with those, but09:20
gwhaleyI don't think we can have a 100% coverage of what must be set in the .config - that sort of *is* the .config ;-)09:21
gwhaley@niteshkonkar007 - I'm sort of thinking, maybe whilst you work out what must and must not be set, that would be the ideal opportunity to gather the data for the document?09:21
kata-irc-bot<james.o.hunt> that would be great indeed @niteshkonkar007. I'm sure that @julio.montes and @bergwolf could also offer input. Since it might take a while to work out what `CONFIG_*` options are actually required, you could consider creating a wiki page on https://github.com/kata-containers/community/wiki and asking on the mailing list and here for folk to contribute. Once the doc has "stabilised" a bit ;), you could raise a PR to add it to one of09:29
kata-irc-botthe repos.09:29
kata-irc-bot<james.o.hunt> @niteshkonkar007 - by the way, we prefer "official" in-repo docs to wiki docs since the former are heavily reviewed. However, for Clear Containers we occasionally used wikis as "drafting areas" for new docs and that worked quite well. As long as we remember to "clean up" once the doc becomes official (lands in a repo) by pointing the wiki page to the official version ;)09:31
kata-irc-bot<zhangwei555> I found a special usage in CRI-O, but I want to make sure I understand it correctly.09:49
kata-irc-bot<zhangwei555> In CRIO, I see ```09:50
kata-irc-bot<zhangwei555> That leads to another question, from runtime spec: ``` // LinuxDevice represents the mknod information for a Linux special device file   type LinuxDevice struct {                                                                // Path to the device.                                                               Path string `json:"path"`                                                            // Device type, block, char, etc.09:52
kata-irc-bot                                           Type string `json:"type"`                                                            // Major is the device's major number.                                               Major int64 `json:"major"`                                                           // Minor is the device's minor number.                                               Minor int64 `json:"minor"`09:52
kata-irc-bot                // FileMode permission bits for the device.                                          FileMode *os.FileMode `json:"fileMode,omitempty"`                                    // UID of the device.                                                                UID *uint32 `json:"uid,omitempty"`                                                   // Gid of the device.                                                                GID09:52
kata-irc-bot*uint32 `json:"gid,omitempty"`                                               }         ``` Does `crio` consider `Path` as device name in container instead of device path on host?09:52
kata-irc-bot<bergwolf> @niteshkonkar007 Most of the config options in kata kernel config are considered essential for kata containers, unless you want to avoid certain features in which case you can disable them accordingly. E.g., the initrd support can be disabled if not needed. Or the nvdim support can be disabled if you do not want to use a rootfs based image. And you can disable one of vsock or serial port support if you just use the enabled one (but I10:08
kata-irc-botdon't think we really have vsock working right now, so you might just disable vsock).10:08
kata-irc-bot<niteshkonkar007> @bergwolf: So, IIUC all the configs mentioned here https://raw.githubusercontent.com/kata-containers/packaging/master/kernel/configs/x86_kata_kvm_4.14.x are minimalist to get the kata-container working ?10:29
kata-irc-bot<bergwolf> @niteshkonkar007 Yes, all of them are essential at some point. kata containers have options to use or not to use some features. If you seek minimal kernel features, you can disable those you do not need then you get a minimal kernel config set for your kata configuration.10:48
*** cdent has joined #kata-dev11:00
*** bgmccollum has quit IRC11:11
*** gwhaley has quit IRC11:16
*** zerocoolback has joined #kata-dev12:03
*** zerocoolback has quit IRC12:19
*** zerocoolback has joined #kata-dev12:20
*** gwhaley has joined #kata-dev12:28
*** fuentess has joined #kata-dev12:34
kata-irc-bot<niteshkonkar007> @bergwolf: Okay Thanks.12:38
kata-irc-bot<niteshkonkar007> @graham.whaley: @james.o.hunt Although I am also not sure what all options are a must and what can be skipped (hence the original question :slightly_smiling_face: ), but let me go through the kernel config options and see what all can be optimized. I would use @bergwolf comment on kernel config options as a reference and see the same for ppc64le as well.  @james.o.hunt: Should I go ahead and create a wiki page for this then? Can12:44
kata-irc-bot@bergwolf comment on what all configs are must have or if all are must have for full functionality of kata-containers, then what do we put into the wiki page to start things off?12:44
*** devimc has joined #kata-dev12:45
*** sjas has quit IRC12:46
*** cdent has left #kata-dev12:51
*** lamego has joined #kata-dev13:28
kata-irc-bot<wei.chen> @bergwolf May I know why should we have to enable netfilter in guest kernel config? I have disabled it for Arm64 in https://github.com/kata-containers/packaging/pull/5413:33
kata-irc-bot<wei.chen> Is it used for multiple containers in one VM? just like multiple containers in Pods?13:34
kata-irc-bot<james.o.hunt> @niteshkonkar007 - yes - feel free to create a wiki page. I don't think it makes sense to have to document *every* kernel `CONFIG_*` option, but we should probably list the important ones. wdyt @graham.whaley, @bergwolf?13:34
kata-irc-bot<bergwolf> @niteshkonkar007 if you just want a generic config for ppc64le, I'd suggest keeping all the features like in X86_6413:35
kata-irc-bot<bergwolf> You just need to modify the arch specific options13:36
kata-irc-bot<bergwolf> For port mapping I think. We do not support it now but will need the feature in future13:38
*** zerocoolback has quit IRC13:41
*** zerocoolback has joined #kata-dev13:41
kata-irc-bot<wei.chen> @bergwolf Thanks. @julio.montes Should I revert my changes in Arm64 guest kernel config? Or just keep this. We can enable this feature when we're using it.13:43
kata-irc-bot<bergwolf> And when we first started off, it was believed that we need to run iptables. Although it turned out that we have not developed such dependency yet. And it reminds me that we have put iptables in osbuilder for a long time. Do you think we should take it out for now? @james.o.hunt13:44
kata-irc-bot<wei.chen> @bergwolf Yes, we have placed iptables in initrd. That's also curious13:45
kata-irc-bot<wei.chen> In a privilege container (no vm-based), it will call iptables to adjust host network13:46
*** zerocoolback has quit IRC13:46
kata-irc-bot<wei.chen> In my opinion, we have to use agent-proxy to call host iptables to do similar operation13:47
kata-irc-bot<bergwolf> Yes, in runv, we are using iptables rules to sync the guest network filters with the outside netns one. It's convenient since iptables does not really have a well defined API except for the command lines.13:48
kata-irc-bot<bergwolf> When we add port mapping support to kata containers, I believe we will still use iptables, and thus the netfilter kernel configs.13:51
kata-irc-bot<wei.chen> Yes, exactly. : ) @james.o.hunt maybe we need not just a wiki page, we may need a script to check the kernel config like docker_check_kernel_config.sh ; )13:54
kata-irc-bot<james.o.hunt> @bergwolf - yep! /cc @jose.carlos.venegas.m, @sebastien.boeuf.13:57
kata-irc-bot<james.o.hunt> @wei.chen - I would much rather a script if we can automate this. I tried to compare the x86_64 and arm64 configs for example but even removing what appeared to be the architecture-specific options, my diff was still big.13:58
kata-irc-bot<julio.montes> @wei.chen no, your pr lgtm13:59
*** eernst has joined #kata-dev14:00
kata-irc-bot<julio.montes> @bergwolf what do you think ?14:00
kata-irc-bot<eric.ernst> think we need both netfliter/iptables.14:01
kata-irc-bot<eric.ernst> we were doing some experiments with ISTIO and this was one of the first things that we needed to enable.14:01
kata-irc-bot<bergwolf> I agree it should be reverted, or we remove netfilter from other architectures as well. It better to keep the kernel configs similar for all architectures, with the only difference being the arch specific ones.14:05
kata-irc-bot<wei.chen> @julio.montes Thanks :slightly_smiling_face:14:10
kata-irc-bot<wei.chen> I have a suggestion that can we enable the config options when features are actually used? I think this would be better for us to track the config options' history14:10
kata-irc-bot<wei.chen> While I was composing the Arm64 config file, in deed, I had a lot of options that I don't know why we have to enable them14:10
kata-irc-bot<wei.chen> For example, we have lots of physical NIC drivers14:10
*** annabelleB has joined #kata-dev14:15
kata-irc-bot<eric.ernst> It's a balance, I guess.14:16
kata-irc-bot<eric.ernst> Having selected options better defined would be good, though (git hist? idk...)14:16
kata-irc-bot<sebastien.boeuf> @bergwolf we need netfilter in the guest for cases such as ISTIO, where the sidecar has to interact with iptables14:17
kata-irc-bot<eric.ernst> we had discussed for a while having a multilevel config, and utilizting defconfig (for baseline) and diffconfigs (for arch)14:17
kata-irc-bot<eric.ernst> I both like the idea, and generally hate the impl of these kinds of layering (I prefer "what you see is what you get" for configs, instead of a multi-step process and wondering what the final .config will look like)14:18
*** dklyle has joined #kata-dev14:40
kata-irc-bot<bergwolf> @wei.chen Most NIC drivers should be built as modules and loaded on demand, even if they are enabled in the kernel config.14:46
kata-irc-bot<bergwolf> @sebastien.boeuf yes, that is my preference as well. We will need iptables support at some point anyway.14:46
*** dklyle has quit IRC14:47
*** sameo has quit IRC14:49
kata-irc-bot<sebastien.boeuf> @bergwolf good ;)14:50
kata-irc-bot<anne> Hey all--remember there is a new zoom link for this morning's meeting. It's updated in google calendar and the ical files on the site, but is this one: https://zoom.us/j/83713940514:57
* gwhaley tries new zoom link....14:59
kata-irc-bot<eric.ernst> hrmm.  i thought i grabbed latest gcal...15:00
*** fiddletwix has joined #kata-dev15:25
*** psuriset has quit IRC15:52
*** psuriset has joined #kata-dev16:04
*** eernst has quit IRC16:38
gwhaleyhi @ane @annabelleB - had a thought whilst on the architecture call - is there any reason we don't have the etherpad link inthe ical/gcal invites on the web site - that migth be handy ;-)16:41
annabelleBgwhaley: that’s a great point! I overlooked that one! It’s easy for me to add it to the gcal and regenerate the icals16:43
*** eernst has joined #kata-dev16:44
annabelleBgoing to need another cup of coffee before I yaml, but I’ll update those today16:47
gwhaleyyaml... was not my friend last week ;-)16:47
gwhaleyjodh will point you to yamllint @annabellB :-)16:47
*** jodh has quit IRC17:01
*** annabelleB has quit IRC17:02
*** annabelleB has joined #kata-dev17:14
*** dklyle has joined #kata-dev17:32
*** gwhaley has quit IRC17:33
*** dklyle has quit IRC18:17
kata-irc-bot<eric.ernst> Saw this posted from MSFT: https://github.com/Microsoft/Freeflow18:22
kata-irc-bot<eric.ernst> @archana.m.shinde @krsna1729 - something to add to the backlog?18:23
kata-irc-bot<eric.ernst> ah, ```-v /dev/:/dev/ --privileged``` should be interesting....18:24
kata-irc-bot<archana.m.shinde> @eric.ernst Interesting!18:28
kata-irc-botAction: eric.ernst wonders if we can setup a brendanburns twitter -> kata github issue bot18:29
kata-irc-bot<archana.m.shinde> would be fun  to see if we can get around that one..18:29
kata-irc-bot<eric.ernst> i'm going to open an issue for this18:30
kata-irc-bot<eric.ernst> not for the bot, but as a backlog item for taking a look at it.18:30
kata-irc-bot<archana.m.shinde> @eric.ernst sounds good18:31
kata-irc-bot<archana.m.shinde> i wonder if they need privileged for kernel modules..18:32
kata-irc-bot<archana.m.shinde> yup RDMA drivers18:33
*** oikiki has joined #kata-dev18:34
*** annabelleB has quit IRC18:41
*** dklyle has joined #kata-dev18:48
*** annabelleB has joined #kata-dev19:02
*** davidgiluk has quit IRC19:09
*** annabelleB has quit IRC19:20
kata-irc-bot<sebastien.boeuf> @eric.ernst the bot sounds very promising though :P19:31
kata-irc-bot<eric.ernst> twitter to git issue.  @anne does OSF have this yet?19:31
*** annabelleB has joined #kata-dev19:41
kata-irc-bot<archana.m.shinde> @sebastien.boeuf Can you take a look at this: https://github.com/kata-containers/runtime/pull/38519:56
kata-irc-bot<eric.ernst> If i read it correctly, the logic was there for rebinding the NIC.20:03
kata-irc-bot<eric.ernst> We just never got to that path?20:03
kata-irc-bot<eric.ernst> @archana.m.shinde ^20:03
*** oikiki has quit IRC20:06
*** oikiki has joined #kata-dev20:07
kata-irc-bot<eric.ernst> and... @archana.m.shinde - our current CI really doesn't exercise the physical endpoint flow.  I wonder if we should consider adding a machine to our CI which covers some more of our device flows...  wdyt?20:10
*** annabelleB has quit IRC20:11
kata-irc-bot<archana.m.shinde> @eric.ernst We have manually tested that flow just for docker before20:46
kata-irc-bot<archana.m.shinde> using our CNM plugin20:46
kata-irc-bot<archana.m.shinde> but never for CNI case20:46
kata-irc-bot<archana.m.shinde> @eric.ernst We should definitely add a machine that tests this flow20:48
kata-irc-bot<eric.ernst> Another item to add to our "ci" list...20:48
kata-irc-bot<archana.m.shinde> @eric.ernst I see that there is accelerated networking available in Azure20:56
kata-irc-bot<archana.m.shinde> which may give us an sriov virtual function20:57
kata-irc-bot<archana.m.shinde> may help us to test CNM plugin, but for testing the Device plugin flow this will not be sufficient I think20:58
*** eernst has quit IRC21:02
*** oikiki has quit IRC21:13
kata-irc-bot<eric.ernst> yeah, but that's already using SRIOV.21:15
kata-irc-bot<eric.ernst> it'd be second level pass-through to get to kata.21:16
kata-irc-bot<eric.ernst> there is vIOMMU out there already...21:16
*** oikiki has joined #kata-dev21:17
*** annabelleB has joined #kata-dev21:17
kata-irc-bot<eric.ernst> I'm not sure it'll be viable.21:19
*** oikiki has quit IRC21:20
*** eernst has joined #kata-dev21:31
*** devimc has quit IRC21:56
*** annabelleB has quit IRC22:02
*** lamego has quit IRC22:07
kata-irc-bot<krsna1729> @eric.ernst aws i3 instance maybe? baremetal22:13
kata-irc-bot<archana.m.shinde> @eric.ernst yeah, you are right22:34
kata-irc-bot<archana.m.shinde> @eric.ernst Can you merge this one : https://github.com/kata-containers/runtime/issues/35622:35
kata-irc-bot<archana.m.shinde> rather this one : https://github.com/kata-containers/runtime/pull/35722:36
*** annabelleB has joined #kata-dev22:49
*** sameo has joined #kata-dev23:04
kata-irc-bot<eric.ernst> merged.23:13
kata-irc-bot<archana.m.shinde> thanks @eric.ernst23:30
*** annabelleB has quit IRC23:42
*** sameo has quit IRC23:51

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