Thursday, 2019-01-03

*** Jeffrey4l has joined #kata-dev00:08
kata-irc-bot<fupan> Hi @eric.ernst,  yes, for shimv2, the BinaryName is redundant, containerd will translate “runtime_type” into a binary name and try to find it in $PATH.02:21
kata-irc-bot<eric.ernst> I like explicit path better, but oh well!02:38
kata-irc-bot<eric.ernst> I’m trying to recall @xu ‘s presentation. I thought there were tests for performance when using block based rootfs. Am I mistaken?02:39
kata-irc-bot<eric.ernst> I was testing with firecracker and was quickly reminded of the lack of devicemapper support in the latest.02:49
kata-irc-bot<eric.ernst> So, I’m guessing in all your testing overlay is used?  Can you clarify @xu @fupan ?02:49
kata-irc-bot<xu> We didn’t test with block snapshotter. But we should have one02:51
kata-irc-bot<xu> we don’t need this actually, but I just copied a configuration file from @bergwolf and didn’t removed it :,)02:52
kata-irc-bot<bergwolf> That one is used by v1 shim. v2 shim will just ignore it ,:)02:54
kata-irc-bot<eric.ernst> I’m looking at what amazon containerd folks are making and also what crio already has03:00
kata-irc-bot<eric.ernst> Would love to retest w this in place.03:01
kata-irc-bot<eric.ernst> Then we can really play with your test suite + fc03:01
kata-irc-bot<xu> cool, should we create a issue for the test suite?03:01
kata-irc-bot<eric.ernst> The existing? It’ll work today03:02
kata-irc-bot<eric.ernst> Just not w v2shim03:02
kata-irc-bot<xu> do you mean our integration tests?03:03
kata-irc-bot<eric.ernst> The metric tests in kata-containers/tests03:03
kata-irc-bot<eric.ernst> Yes.03:03
kata-irc-bot<xu> ah I see03:03
kata-irc-bot<eric.ernst> If y’all have a repo, we should augment that as well03:04
kata-irc-bot<eric.ernst> this'll be something i'll try to start looking at otherwise.  Though, Im hopeful someone over there beats me to it :slightly_smiling_face:04:05
*** eernst_ has quit IRC04:52
*** stackedsax has joined #kata-dev05:00
*** stefanha has quit IRC05:23
*** lpetrut has joined #kata-dev08:03
*** jodh has joined #kata-dev08:35
*** davidgiluk has joined #kata-dev09:04
*** gwhaley has joined #kata-dev09:04
*** lpetrut has quit IRC09:32
*** gwhaley has quit IRC11:52
*** gwhaley has joined #kata-dev12:58
*** Bhujay has joined #kata-dev15:15
*** Bhujay has quit IRC15:16
kata-irc-bot<raravena80> I had to use `runtime_type = "io.containerd.runc.v1"` with `BinaryName = "/opt/kata/bin/kata-runtime"` to make it work initially15:34
kata-irc-bot<eric.ernst> that'll end up using runc afaiu?15:34
kata-irc-bot<eric.ernst> Ah, that'll work for v1 afaiu.15:34
kata-irc-bot<eric.ernst> For v2 it doesn't15:34
kata-irc-bot<xu> yep, v2 doesn’t need BinaryName15:35
kata-irc-bot<eric.ernst> For v2 interface, that BinaryName field is not used.15:35
kata-irc-bot<eric.ernst> which is confusing and lame, imo :slightly_smiling_face:15:35
kata-irc-bot<eric.ernst> It doesn't use an 'OCI runtime' - it uses a shim, whos name is deduced from the runtime-type name15:36
kata-irc-bot<eric.ernst> its kind of like magic.15:36
kata-irc-bot<eric.ernst> :slightly_smiling_face:  remove a few periods, and a couple words and the rest is sed magic15:37
kata-irc-bot<xu> shim binary is translated from the `runtime_type`, and the BinaryName is a parameter passed to the shim. `io.containerd.kata.v2` don’t need such a parameter, and `io.containerd.runc.v1` has `runc` as the default parameter, which could be override by `BinaryName`.15:38
kata-irc-bot<xu> sometimes I think containerd is too sophisticated to understand by average people like me :thinking_face:15:40
kata-irc-bot<eric.ernst> yeah, i need to go back to school before I can submit a patch, or really fix something in their code base15:40
kata-irc-bot<eric.ernst> ;)15:40
kata-irc-bot<eric.ernst> its fine - it just wasn't very intuitive15:41
kata-irc-bot<xu> i need draw a big figure before I read the code :,)15:41
kata-irc-bot<eric.ernst> one thing -- Xu - how do ya'll determine the config file path for the kata shim?15:41
kata-irc-bot<eric.ernst> I was testing yesterday - it seems the containerd-kata-shim-v2 assumes the path of the config file.15:42
kata-irc-bot<eric.ernst> it'd be ideal if we had an option, either at compile or runtime, to specificy the path.15:42
kata-irc-bot<xu> let me check with @fupan15:42
kata-irc-bot<eric.ernst> I *think* it only assumes its at /usr/share/defaults/kata-containers/configuration.toml15:42
kata-irc-bot<eric.ernst> in kata-runtime, we have a --config option where we can override (and can do this at build time as well)15:42
kata-irc-bot<eric.ernst> I don't think either are taken into account.15:43
kata-irc-bot<eric.ernst> for v2sim15:43
kata-irc-bot<eric.ernst> at least, that's what I saw when testing.15:43
kata-irc-bot<xu> as a packager for years, I don’t think we should assume it under `/user/share/`15:43
kata-irc-bot<eric.ernst> yes.  100% agree.15:43
kata-irc-bot<eric.ernst> :slightly_smiling_face:15:43
kata-irc-bot<eric.ernst> ah you're a packager - i may pull you into some packaging issues :slightly_smiling_face: :slightly_smiling_face:15:44
kata-irc-bot<eric.ernst> the truth is out.15:44
kata-irc-bot<xu> will check it, and will file issue and pr if it is15:44
kata-irc-bot<eric.ernst> thx.  for now i can work around it.15:44
kata-irc-bot<eric.ernst> but, i don't want to ln -s over to /usr/share...15:45
kata-irc-bot<raravena80> everything needs to be an option :slightly_smiling_face:15:45
kata-irc-bot<eric.ernst> we have too many options15:45
kata-irc-bot<eric.ernst> in this case i agree though :slightly_smiling_face:15:45
kata-irc-bot<raravena80> I'm amazed at the amount of options for qemu...15:45
kata-irc-bot<xu> I understand a bit of `deb `, you know, the deb tool chain is really huge, and so do the DFSG15:45
kata-irc-bot<xu> traditionally, `/usr/` stores the static files for distro packagers, and `/usr/local/` for the host admin. the `/etc/` is for static configuration. And some runtime configuration should located under `/var/lib` or somewhere.15:49
*** gwhaley has quit IRC18:04
*** jodh has quit IRC18:04
*** davidgiluk has quit IRC20:16
kata-irc-bot<claire> Hey team - in addition to the CFP that’s currently open for the Open Infrastructure Summit scheduled in Denver, April 29 - May 1 -  the call for space is also now open for the co-located Project Teams Gathering (PTG) event that’s held at the end of the week, on May 2-4. I don’t believe that the Kata team has taken advantage of the opportunity to meet at the previous standalone PTG events held last year, but now that the event is22:40
kata-irc-botco-located with the Summit it may be a good time to reconsider it. The PTG offers focused, quiet, meeting facilities allowing the various technical community groups to meet in-person, exchange and get work done in a productive setting. The in person time allows the projects to discuss their priorities for the upcoming cycle, assign work items, iterate quickly on solutions for complex problems, and make fast progress on critical issues. The22:40
kata-irc-botco-location of those various meetings, combined with the dynamic scheduling of the event, make it easy to get specific people in the same room to discuss a specific topic, or participate in multiple team meetings. Evenings allow for relationship building and problem sharing. If Kata would like to reserve dedicated space at the PTG, I need to know by January 20 to complete the form. @eric.ernst I’ll add this as a topic for next Monday’s AC call22:40
kata-irc-bot<manohar.r.castelino> @raravena80 ping23:15
kata-irc-bot<raravena80> @manohar.r.castelino hey23:39
kata-irc-bot<manohar.r.castelino> @raravena80 was trying to understand your comment https://github.com/kata-containers/runtime/issues/1082#issuecomment-45130399723:39
kata-irc-bot<manohar.r.castelino> are you suggesting that we do not support multiple isolation mechanisms on the same node?23:40
kata-irc-bot<raravena80> yes. so my question I guess why do we need multiple isolation mechanisms on a single node23:40
kata-irc-bot<manohar.r.castelino> The more restrictive you are.. the less capabilities you have... so for bin packing with kata it is better if we allow multiple on the same node.. so that you do not need dedicated nodes23:42
kata-irc-bot<manohar.r.castelino> Even if we decide to do only one per node.. it is better if we explicitly choose the one we want via some sort of configurable option exposed as a seperate runtime class23:43
kata-irc-bot<manohar.r.castelino> It makes packaging and deployment simpler23:43
kata-irc-bot<raravena80> so I guess is just to provide more flexibility for the user, and having mixed clusters, with qemu nodes and firecracker nodes.23:44
kata-irc-bot<raravena80> cool, makes sense, was only curious :slightly_smiling_face:23:44
kata-irc-bot<raravena80> and I guess taking it a step further, having nodes with firecracker and qemu support23:46
kata-irc-bot<manohar.r.castelino> @raravena80 yes. You comment captures it perfectly23:55

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