Wednesday, 2018-04-11

*** annabelleB has quit IRC00:08
*** annabelleB has joined #kata-dev00:27
*** mylinux_ has joined #kata-dev00:50
*** annabelleB has quit IRC00:50
*** justJanne has quit IRC01:53
*** justJanne has joined #kata-dev01:53
*** justJanne has quit IRC01:54
*** justJanne has joined #kata-dev02:14
*** justJanne has quit IRC02:17
*** justJanne has joined #kata-dev02:17
*** zerocoolback has joined #kata-dev02:33
*** zerocoolback has quit IRC02:34
*** zerocoolback has joined #kata-dev02:34
*** mylinux_ has quit IRC02:36
*** mylinux has joined #kata-dev03:05
*** zerocoolback has quit IRC04:01
*** zerocoolback has joined #kata-dev04:13
*** mylinux has quit IRC04:22
*** sjas_ has joined #kata-dev04:32
*** sjas has quit IRC04:35
*** mylinux has joined #kata-dev05:00
*** mylinux has quit IRC05:05
*** gwhaley has joined #kata-dev08:01
*** mylinux has joined #kata-dev08:04
*** mylinux has quit IRC08:09
*** zerocoolback has quit IRC08:40
*** zerocool_ has joined #kata-dev08:40
*** cdent has joined #kata-dev09:40
*** mylinux has joined #kata-dev10:04
*** mylinux has quit IRC10:08
*** sameo has joined #kata-dev11:02
*** gwhaley has quit IRC11:06
*** sjas_ is now known as sjas11:29
*** devimc has joined #kata-dev12:10
*** gwhaley has joined #kata-dev12:14
*** fuentess has joined #kata-dev12:29
*** mylinux has joined #kata-dev12:35
kata-dev-irc-bot<julio.montes> @bergwolf Hi13:40
kata-dev-irc-bot<julio.montes> do you know why we are converting OCI to GRPC and GRPC to OCI ?13:40
kata-dev-irc-bot<julio.montes> seems like the conversion is not working correctly13:41
kata-dev-irc-bot<julio.montes> https://github.com/kata-containers/agent/issues/21213:41
kata-dev-irc-bot<julio.montes> IMO we should just send the OCI json as string and unmarshall it in the agent13:43
kata-dev-irc-bot<julio.montes> WDYT?13:43
*** ttx has left #kata-dev13:53
kata-dev-irc-bot<bergwolf> IIRC it is to have a strong typed grpc interface so that we catch any garbage in the OCI spec and be clear about what version of the OCI spec is supported.13:57
kata-dev-irc-bot<bergwolf> @julio.montes ^^13:57
kata-dev-irc-bot<bergwolf> I'm not sure about the error with the conversion though. @samuel.ortiz is most familiar with it since he's the one writing it.13:59
kata-dev-irc-bot<bergwolf> oh, and json (un)marshalling is though to be slower than grpc14:00
kata-dev-irc-bot<julio.montes> @bergwolf thanks  for the info, I thought OCI to GPRC / GRPC to OCI is slower14:05
kata-dev-irc-bot<julio.montes> because unmarsgalling occurs once in the agent, marchall is not needed14:06
kata-dev-irc-bot<julio.montes> *marshall14:06
*** diga has joined #kata-dev14:08
*** eernst has joined #kata-dev14:20
kata-dev-irc-bot<bergwolf> @julio.montes how do you send json through grpc APIs if you do not marshall it?14:31
kata-dev-irc-bot<julio.montes> @bergwolf we already have the json as a string in annotations14:31
kata-dev-irc-bot<julio.montes> @bergwolf https://github.com/kata-containers/runtime/blob/master/virtcontainers/kata_agent.go#L62614:32
kata-dev-irc-bot<julio.montes> instead of using buggy functions to convert OCI to GRPC, we should just send the string14:33
kata-dev-irc-bot<bergwolf> that's because kata cli does the marshalling. And virtcontainers actually need to modify certain part of the spec at some time14:33
kata-dev-irc-bot<julio.montes> and unmarshall it in the agent14:33
kata-dev-irc-bot<julio.montes> @bergwolf but that's should work, right?14:34
kata-dev-irc-bot<bergwolf> surely that can work. They both can work. We had quit a lot of discussion about json string vs. grpc when designing the agent API and the conclusion was to use grpc14:36
kata-dev-irc-bot<julio.montes> x_x14:37
kata-dev-irc-bot<bergwolf> If there is not a deadly blocker, most likely we'd stick with grpc14:39
kata-dev-irc-bot<bergwolf> Searching the earliest few issues and PRs in runtime and agent repos,  you should be able to find related discussions14:40
*** gabyc_ has joined #kata-dev14:41
kata-dev-irc-bot<julio.montes> IMO that conversion is quite inefficient and we are doing it twice, in the runtime and in the agent14:43
kata-dev-irc-bot<julio.montes> and structs are not copied correctly14:43
*** annabelleB has joined #kata-dev14:45
kata-dev-irc-bot<bergwolf> The bug needs to be fixed for sure14:46
kata-dev-irc-bot<bergwolf> And I don't think we can just pass the OCI annotation string without modification to the agent. That  means either the runtime does not unmarshall it, or the runtime cannot change any field of it. Both case do not seem realistic to me.14:48
kata-dev-irc-bot<bergwolf> e.g, https://github.com/kata-containers/runtime/pull/138 is an example of where we want to actually modify the OCI spec14:51
kata-dev-irc-bot<julio.montes> @bergwolf yees, but conversion occurs before OCItoGRPC  https://github.com/kata-containers/runtime/pull/138/files#diff-7ba6ce1174401126aaba6a1cff25434dR76614:54
kata-dev-irc-bot<julio.montes> isn't it ?14:54
kata-dev-irc-bot<julio.montes> *modification14:55
kata-dev-irc-bot<bergwolf> The point is that once you modify the OCI spec, you cannot send the annotation string.. You have to marshall it yourself into json strings to send to the agent. So the claim that you can save one conversion with json string does not stand.14:57
kata-dev-irc-bot<julio.montes> @bergwolf ahh ok, now I understand your point14:59
kata-dev-irc-bot<archana.m.shinde> @bergwolf For https://github.com/kata-containers/runtime/pull/138#discussion_r180619223, I am seeing sync issues if the block device may be passed to 2 different containers15:26
kata-dev-irc-bot<archana.m.shinde> in a single pod15:26
*** zerocool_ has quit IRC15:41
*** annabelleB has quit IRC15:45
*** zerocoolback has joined #kata-dev15:58
*** mcastelino has joined #kata-dev16:02
*** annabelleB has joined #kata-dev16:02
*** mylinux has quit IRC16:04
kata-dev-irc-bot<eric.ernst> @archana.m.shinde ouch.16:06
gwhaleya single pod is a single VM, right - so that would be two mounts of the same block but in different namespaces? sounded like that should work as the single guest VM kernel should manage the superblock and cache coherencies. Maybe put details of what you did and what you saw on an Issue @archana.m.shinde16:08
kata-dev-irc-bot<eric.ernst> even if that worked, the harder case is same volume shared between two pods.16:08
*** mylinux_ has joined #kata-dev16:10
kata-dev-irc-bot<archana.m.shinde> @graham.whaley I'll add more details16:10
kata-dev-irc-bot<archana.m.shinde> this was attaching the same device file twice16:10
kata-dev-irc-bot<archana.m.shinde> since device/volume is a container resource, we may end up attaching the same block device file twice16:11
kata-dev-irc-bot<archana.m.shinde> I think we need to track that and make sure that it is not attached again16:12
kata-dev-irc-bot<archana.m.shinde> @eric.ernst That PR is for a block device file (say /dev/sdb), so if you are passing that to a pod, the user should not be passing it to any other pod then16:13
kata-dev-irc-bot<eric.ernst> OK.  But shared volumes would *need* to be done via 9p then, is what you're saying?16:16
kata-dev-irc-bot<eric.ernst> Are we planning to differentiate / disallow the use case then?16:16
*** mylinux_ has quit IRC16:21
kata-dev-irc-bot<bergwolf> @archana.m.shinde if we attach a device file twice, it is viewed as two different devices in the guest. That might explain the sync issue. But I think we should just just share the same device across different volumes if they all refer to the same device on the host.16:27
kata-dev-irc-bot<archana.m.shinde> @bergwolf agree16:28
kata-dev-irc-bot<archana.m.shinde> I think that would apply to devices passed with --device as well16:29
kata-dev-irc-bot<bergwolf> yes, for the volume case, that's shared `Storage` resource in the agent protocol16:31
kata-dev-irc-bot<bergwolf> new volumes just reference existing `Storage` if there is duplication.16:31
kata-dev-irc-bot<bergwolf> For devices, it's shared `Device` resource16:33
kata-dev-irc-bot<archana.m.shinde> @bergwolf How about having Storage that simply bind mount16:34
kata-dev-irc-bot<archana.m.shinde> existing devices16:34
kata-dev-irc-bot<archana.m.shinde> it keeps things simple in the agent16:34
kata-dev-irc-bot<bergwolf> OCI.Mount is supposed to just bind mount the `Storage` mountmount16:34
kata-dev-irc-bot<bergwolf> that's the design of the agent API. `Storage` and `Device` are referenced by containers16:35
kata-dev-irc-bot<archana.m.shinde> for block devices , Storage also bind-mounts, since it mounting the block device file and not the actual device in the container16:36
kata-dev-irc-bot<bergwolf> Not sure I get you. `Storage` is to mount the block device to the specified mountpoint. What `bind-mounts` are you referring to?16:37
kata-dev-irc-bot<bergwolf> For one device, there is only one `Device` structure. And the same applies to `Storage`.16:38
kata-dev-irc-bot<archana.m.shinde> https://github.com/kata-containers/runtime/pull/138/commits/7d4ee200579de18d8d27501520a95c7205988f57#diff-7ba6ce1174401126aaba6a1cff25434dR83116:39
kata-dev-irc-bot<archana.m.shinde> when say a volume "/dev/sda" is  passed to container, it may appear as "/dev/vdb", at that point we need to bind mount "/dev/vdb" to "/dev/sda" within the container16:40
kata-dev-irc-bot<bergwolf> `/dev/sda` is a device. when we say volume, it is always a directory in the container.16:41
kata-dev-irc-bot<bergwolf> sorry had to sleep now. too late for me. ttyl16:42
kata-dev-irc-bot<archana.m.shinde> this is the case --volume={blk-device-file}16:42
kata-dev-irc-bot<archana.m.shinde> sure, I'll send out implementation for sharing a single device16:42
kata-dev-irc-bot<archana.m.shinde> you can comment on the PR itself :slightly_smiling_face:16:43
kata-dev-irc-bot<archana.m.shinde> see you @bergwolf16:43
kata-dev-irc-bot<sebastien.boeuf> @archana.m.shinde this problem is not that easy to solve. You have to keep track of the devices/volumes already shared through a pod to make sure that a new container needing this same thing will not pass it through the VM again. And the detach case is more complex since the first container might terminate first (the second one still running), which means that you cannot rely on the list of volumes/devices related to the16:54
kata-dev-irc-botfirst container to do all the unplug.16:54
kata-dev-irc-bot<sebastien.boeuf> Feasible but complex IMO16:54
*** kgz has quit IRC17:06
*** zerocoolback has quit IRC17:07
*** zerocoolback has joined #kata-dev17:08
*** gwhaley has quit IRC17:09
*** diga has quit IRC17:10
*** zerocoolback has quit IRC17:12
*** annabelleB has quit IRC17:19
*** annabelleB has joined #kata-dev17:24
kata-dev-irc-bot<eric.ernst> @archana.m.shinde; @julio.montes - related topic - can either of you do some I/O measurements of NFS/VSOCK, relative to 9p?17:25
kata-dev-irc-bot<eric.ernst> (or open to others doing this)17:26
kata-dev-irc-bot<archana.m.shinde> @eric.ernst I have a full plate for today, looking into a PR and SCSI performance today17:29
kata-dev-irc-bot<archana.m.shinde> might get to it tomorrow17:30
kata-dev-irc-bot<archana.m.shinde> @sebastien.boeuf we might need to keep some sort of reference count for devices at the pod level17:31
kata-dev-irc-bot<archana.m.shinde> detach a device only if no longer used by any other container17:31
*** mylinux has joined #kata-dev17:32
kata-dev-irc-bot<archana.m.shinde> its not going to be straightforward17:32
kata-dev-irc-bot<sebastien.boeuf> @archana.m.shinde +1 for ref counter17:32
kata-dev-irc-bot<archana.m.shinde> @sebastien.boeuf I do want to tackle that in a separate PR on its own17:32
kata-dev-irc-bot<archana.m.shinde> what do you think17:32
kata-dev-irc-bot<sebastien.boeuf> @eric.ernst any details about those measurements ?17:32
kata-dev-irc-bot<eric.ernst> That's fine - i"m not asking you to do it per se.  Just putting it out there this is a task we need to do.17:33
kata-dev-irc-bot<eric.ernst> very soon.17:33
kata-dev-irc-bot<sebastien.boeuf> @archana.m.shinde oh yeah definitely. We know this limitation and I want to merge your PR first17:33
kata-dev-irc-bot<sebastien.boeuf> @archana.m.shinde this would be a too big PR if you were doing the shared device handling into the same17:34
kata-dev-irc-bot<archana.m.shinde> yeah17:34
kata-dev-irc-bot<sebastien.boeuf> @eric.ernst np! just shout when you need it, but please provide the details (maybe already written into an issue ?)17:35
kata-dev-irc-bot<archana.m.shinde> we should agree with the limitation and agree to handle in a separate one17:35
kata-dev-irc-bot<sebastien.boeuf> @archana.m.shinde yes. That's why I have asked @bergwolf what was missing on your PR to get it merged. But I guess we could write this down more formally on the issue17:35
kata-dev-irc-bot<sebastien.boeuf> we open an issue, we reference this issue from your current PR, we merge your PR saying that shared devices are going to be supported later17:36
*** mylinux has quit IRC17:36
kata-dev-irc-bot<archana.m.shinde> @sebastien.boeuf sounds good17:36
kata-dev-irc-bot<archana.m.shinde> I'll open an issue and add my comments in the PR17:37
kata-dev-irc-bot<sebastien.boeuf> thx17:42
*** core has quit IRC18:03
*** annabelleB has quit IRC18:14
*** annabelleB has joined #kata-dev18:17
*** annabelleB has quit IRC18:39
*** annabelleB has joined #kata-dev18:45
*** mylinux has joined #kata-dev19:00
*** annabelleB has quit IRC19:29
*** annabelleB has joined #kata-dev19:36
*** annabelleB_ has joined #kata-dev19:40
*** annabelleB has quit IRC19:41
*** annabelleB_ is now known as annabelleB19:41
*** eernst has quit IRC19:44
*** eernst has joined #kata-dev19:44
*** eernst has quit IRC19:54
*** eernst has joined #kata-dev19:59
*** mrbobbytables_ has joined #kata-dev20:20
*** mordred has quit IRC20:28
*** mrbobbytables has quit IRC20:28
*** mrbobbytables_ is now known as mrbobbytables20:28
*** mordred has joined #kata-dev20:31
*** annabelleB has quit IRC20:40
*** annabelleB has joined #kata-dev20:45
*** devimc has quit IRC20:56
*** kragniz has joined #kata-dev21:24
*** cdent has quit IRC22:07
*** gabyc_ has left #kata-dev22:08
*** annabelleB has quit IRC22:31
*** kragniz is now known as kgz22:41
*** mylinux has quit IRC22:48
*** eocardon_ has quit IRC23:22
*** mylinux has joined #kata-dev23:34
*** mylinux has quit IRC23:38
*** eernst has quit IRC23:55

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