*** annabelleB has quit IRC | 00:08 | |
*** annabelleB has joined #kata-dev | 00:27 | |
*** mylinux_ has joined #kata-dev | 00:50 | |
*** annabelleB has quit IRC | 00:50 | |
*** justJanne has quit IRC | 01:53 | |
*** justJanne has joined #kata-dev | 01:53 | |
*** justJanne has quit IRC | 01:54 | |
*** justJanne has joined #kata-dev | 02:14 | |
*** justJanne has quit IRC | 02:17 | |
*** justJanne has joined #kata-dev | 02:17 | |
*** zerocoolback has joined #kata-dev | 02:33 | |
*** zerocoolback has quit IRC | 02:34 | |
*** zerocoolback has joined #kata-dev | 02:34 | |
*** mylinux_ has quit IRC | 02:36 | |
*** mylinux has joined #kata-dev | 03:05 | |
*** zerocoolback has quit IRC | 04:01 | |
*** zerocoolback has joined #kata-dev | 04:13 | |
*** mylinux has quit IRC | 04:22 | |
*** sjas_ has joined #kata-dev | 04:32 | |
*** sjas has quit IRC | 04:35 | |
*** mylinux has joined #kata-dev | 05:00 | |
*** mylinux has quit IRC | 05:05 | |
*** gwhaley has joined #kata-dev | 08:01 | |
*** mylinux has joined #kata-dev | 08:04 | |
*** mylinux has quit IRC | 08:09 | |
*** zerocoolback has quit IRC | 08:40 | |
*** zerocool_ has joined #kata-dev | 08:40 | |
*** cdent has joined #kata-dev | 09:40 | |
*** mylinux has joined #kata-dev | 10:04 | |
*** mylinux has quit IRC | 10:08 | |
*** sameo has joined #kata-dev | 11:02 | |
*** gwhaley has quit IRC | 11:06 | |
*** sjas_ is now known as sjas | 11:29 | |
*** devimc has joined #kata-dev | 12:10 | |
*** gwhaley has joined #kata-dev | 12:14 | |
*** fuentess has joined #kata-dev | 12:29 | |
*** mylinux has joined #kata-dev | 12:35 | |
kata-dev-irc-bot | <julio.montes> @bergwolf Hi | 13: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 correctly | 13:41 |
kata-dev-irc-bot | <julio.montes> https://github.com/kata-containers/agent/issues/212 | 13:41 |
kata-dev-irc-bot | <julio.montes> IMO we should just send the OCI json as string and unmarshall it in the agent | 13:43 |
kata-dev-irc-bot | <julio.montes> WDYT? | 13:43 |
*** ttx has left #kata-dev | 13: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 grpc | 14:00 |
kata-dev-irc-bot | <julio.montes> @bergwolf thanks for the info, I thought OCI to GPRC / GRPC to OCI is slower | 14:05 |
kata-dev-irc-bot | <julio.montes> because unmarsgalling occurs once in the agent, marchall is not needed | 14:06 |
kata-dev-irc-bot | <julio.montes> *marshall | 14:06 |
*** diga has joined #kata-dev | 14:08 | |
*** eernst has joined #kata-dev | 14: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 annotations | 14:31 |
kata-dev-irc-bot | <julio.montes> @bergwolf https://github.com/kata-containers/runtime/blob/master/virtcontainers/kata_agent.go#L626 | 14:32 |
kata-dev-irc-bot | <julio.montes> instead of using buggy functions to convert OCI to GRPC, we should just send the string | 14: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 time | 14:33 |
kata-dev-irc-bot | <julio.montes> and unmarshall it in the agent | 14: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 grpc | 14:36 |
kata-dev-irc-bot | <julio.montes> x_x | 14:37 |
kata-dev-irc-bot | <bergwolf> If there is not a deadly blocker, most likely we'd stick with grpc | 14: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 discussions | 14:40 |
*** gabyc_ has joined #kata-dev | 14: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 agent | 14:43 |
kata-dev-irc-bot | <julio.montes> and structs are not copied correctly | 14:43 |
*** annabelleB has joined #kata-dev | 14:45 | |
kata-dev-irc-bot | <bergwolf> The bug needs to be fixed for sure | 14: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 spec | 14:51 |
kata-dev-irc-bot | <julio.montes> @bergwolf yees, but conversion occurs before OCItoGRPC https://github.com/kata-containers/runtime/pull/138/files#diff-7ba6ce1174401126aaba6a1cff25434dR766 | 14:54 |
kata-dev-irc-bot | <julio.montes> isn't it ? | 14:54 |
kata-dev-irc-bot | <julio.montes> *modification | 14: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 point | 14: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 containers | 15:26 |
kata-dev-irc-bot | <archana.m.shinde> in a single pod | 15:26 |
*** zerocool_ has quit IRC | 15:41 | |
*** annabelleB has quit IRC | 15:45 | |
*** zerocoolback has joined #kata-dev | 15:58 | |
*** mcastelino has joined #kata-dev | 16:02 | |
*** annabelleB has joined #kata-dev | 16:02 | |
*** mylinux has quit IRC | 16:04 | |
kata-dev-irc-bot | <eric.ernst> @archana.m.shinde ouch. | 16:06 |
gwhaley | a 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.shinde | 16: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-dev | 16:10 | |
kata-dev-irc-bot | <archana.m.shinde> @graham.whaley I'll add more details | 16:10 |
kata-dev-irc-bot | <archana.m.shinde> this was attaching the same device file twice | 16: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 twice | 16:11 |
kata-dev-irc-bot | <archana.m.shinde> I think we need to track that and make sure that it is not attached again | 16: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 then | 16: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 IRC | 16: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 agree | 16:28 |
kata-dev-irc-bot | <archana.m.shinde> I think that would apply to devices passed with --device as well | 16:29 |
kata-dev-irc-bot | <bergwolf> yes, for the volume case, that's shared `Storage` resource in the agent protocol | 16: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` resource | 16:33 |
kata-dev-irc-bot | <archana.m.shinde> @bergwolf How about having Storage that simply bind mount | 16:34 |
kata-dev-irc-bot | <archana.m.shinde> existing devices | 16:34 |
kata-dev-irc-bot | <archana.m.shinde> it keeps things simple in the agent | 16:34 |
kata-dev-irc-bot | <bergwolf> OCI.Mount is supposed to just bind mount the `Storage` mountmount | 16:34 |
kata-dev-irc-bot | <bergwolf> that's the design of the agent API. `Storage` and `Device` are referenced by containers | 16: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 container | 16: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-7ba6ce1174401126aaba6a1cff25434dR831 | 16: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 container | 16: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. ttyl | 16: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 device | 16: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 @bergwolf | 16: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 the | 16:54 |
kata-dev-irc-bot | first container to do all the unplug. | 16:54 |
kata-dev-irc-bot | <sebastien.boeuf> Feasible but complex IMO | 16:54 |
*** kgz has quit IRC | 17:06 | |
*** zerocoolback has quit IRC | 17:07 | |
*** zerocoolback has joined #kata-dev | 17:08 | |
*** gwhaley has quit IRC | 17:09 | |
*** diga has quit IRC | 17:10 | |
*** zerocoolback has quit IRC | 17:12 | |
*** annabelleB has quit IRC | 17:19 | |
*** annabelleB has joined #kata-dev | 17: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 today | 17:29 |
kata-dev-irc-bot | <archana.m.shinde> might get to it tomorrow | 17: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 level | 17:31 |
kata-dev-irc-bot | <archana.m.shinde> detach a device only if no longer used by any other container | 17:31 |
*** mylinux has joined #kata-dev | 17:32 | |
kata-dev-irc-bot | <archana.m.shinde> its not going to be straightforward | 17:32 |
kata-dev-irc-bot | <sebastien.boeuf> @archana.m.shinde +1 for ref counter | 17:32 |
kata-dev-irc-bot | <archana.m.shinde> @sebastien.boeuf I do want to tackle that in a separate PR on its own | 17:32 |
kata-dev-irc-bot | <archana.m.shinde> what do you think | 17: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 first | 17: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 same | 17:34 |
kata-dev-irc-bot | <archana.m.shinde> yeah | 17: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 one | 17: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 issue | 17: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 later | 17:36 |
*** mylinux has quit IRC | 17:36 | |
kata-dev-irc-bot | <archana.m.shinde> @sebastien.boeuf sounds good | 17:36 |
kata-dev-irc-bot | <archana.m.shinde> I'll open an issue and add my comments in the PR | 17:37 |
kata-dev-irc-bot | <sebastien.boeuf> thx | 17:42 |
*** core has quit IRC | 18:03 | |
*** annabelleB has quit IRC | 18:14 | |
*** annabelleB has joined #kata-dev | 18:17 | |
*** annabelleB has quit IRC | 18:39 | |
*** annabelleB has joined #kata-dev | 18:45 | |
*** mylinux has joined #kata-dev | 19:00 | |
*** annabelleB has quit IRC | 19:29 | |
*** annabelleB has joined #kata-dev | 19:36 | |
*** annabelleB_ has joined #kata-dev | 19:40 | |
*** annabelleB has quit IRC | 19:41 | |
*** annabelleB_ is now known as annabelleB | 19:41 | |
*** eernst has quit IRC | 19:44 | |
*** eernst has joined #kata-dev | 19:44 | |
*** eernst has quit IRC | 19:54 | |
*** eernst has joined #kata-dev | 19:59 | |
*** mrbobbytables_ has joined #kata-dev | 20:20 | |
*** mordred has quit IRC | 20:28 | |
*** mrbobbytables has quit IRC | 20:28 | |
*** mrbobbytables_ is now known as mrbobbytables | 20:28 | |
*** mordred has joined #kata-dev | 20:31 | |
*** annabelleB has quit IRC | 20:40 | |
*** annabelleB has joined #kata-dev | 20:45 | |
*** devimc has quit IRC | 20:56 | |
*** kragniz has joined #kata-dev | 21:24 | |
*** cdent has quit IRC | 22:07 | |
*** gabyc_ has left #kata-dev | 22:08 | |
*** annabelleB has quit IRC | 22:31 | |
*** kragniz is now known as kgz | 22:41 | |
*** mylinux has quit IRC | 22:48 | |
*** eocardon_ has quit IRC | 23:22 | |
*** mylinux has joined #kata-dev | 23:34 | |
*** mylinux has quit IRC | 23:38 | |
*** eernst has quit IRC | 23:55 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!