Wednesday, 2018-07-25

« Tuesday, 2018-07-24 Index Thursday, 2018-07-26 »
*** LinuxMe has quit IRC00:10
*** annabelleB has quit IRC00:35
*** dklyle_ has quit IRC00:36
*** dklyle has joined #kata-dev00:36
*** LinuxMe has joined #kata-dev00:41
*** LinuxMe has quit IRC00:46
*** zerocoolback has joined #kata-dev00:55
*** LinuxMe has joined #kata-dev01:42
*** LinuxMe has quit IRC01:46
*** dlw has joined #kata-dev01:53
*** JerryLiu has quit IRC01:53
*** changcheng has joined #kata-dev01:53
*** changcheng has quit IRC01:54
*** changcheng has joined #kata-dev01:54
*** changcheng has quit IRC01:55
*** changcheng has joined #kata-dev01:55
*** changcheng has quit IRC01:59
*** LinuxMe has joined #kata-dev02:08
*** lpetrut has joined #kata-dev03:52
kata-irc-bot1<niteshkonkar007> @eric.ernst: I can view it too.03:58
kata-irc-bot1<zhangwei555> I am also doing the review04:02
*** sjas_ has joined #kata-dev04:02
*** eernst has joined #kata-dev04:02
kata-irc-bot1<bergwolf> in the graph, what operation is supposed to set the guest route table? `updateRoutes`?04:04
kata-irc-bot1<eric.ernst> hey ya'll04:04
kata-irc-bot1<bergwolf> and do we want to allow to update an interface? that seems missing too04:04
kata-irc-bot1<zhangwei555> One thing I want to point out, I was hoping that `listInterfaces` and `listRoutes` can always be sent to kata-agent, and kata-agent return the result from a real query from kernel, but not only from it's stored list04:05
*** sjas has quit IRC04:05
kata-irc-bot1<bergwolf> +1 to that @zhangwei55504:06
kata-irc-bot1<eric.ernst> sure, I am fine with this.04:06
kata-irc-bot1<archana.m.shinde> @bergwolf We talked about updateInterface, but wanted to keep the initial PR minimal04:06
kata-irc-bot1<eric.ernst> Looking at what was implemented so far by Frank, it looks like the network would be updated in one call, ie update all the interfaces?04:06
kata-irc-bot1<archana.m.shinde> we can add it if there is a use case for it04:06
kata-irc-bot1<eric.ernst> to me it seems it makes sense to have a "update Routes" call which does all the routes at once (similar to what is done in the agent protocol today)04:07
kata-irc-bot1<archana.m.shinde> I am fine with @zhangwei555 suggestion as well04:07
kata-irc-bot1<eric.ernst> I think it probably makes sense to do one interface at a time?04:08
kata-irc-bot1<eric.ernst> not a major difference, but curious to hear what you think?04:08
kata-irc-bot1<zhangwei555> @eric.ernst That implementation is guided by the discussion of "declarative" and "imperative", at first I stand for "imperative" ways for kata-agent,  then I compromised, one call is also fine for me04:09
kata-irc-bot1<caoruidong> According to agent code, for update routes, it does all at once. for update interface, it sent request one by one.04:09
kata-irc-bot1<archana.m.shinde> I prefer one call for interface04:09
kata-irc-bot1<eric.ernst> correct Frank.  We can do same at API level?04:09
kata-irc-bot1<eric.ernst> It kind of depends on the expected usage to me.04:10
kata-irc-bot1<eric.ernst> if this is just done at one time and you don't expect to modify individual interfaces after the fact, a one shot will be fine.04:10
kata-irc-bot1<eric.ernst> I"m not completely sure the usage for huawei and zte here.04:10
kata-irc-bot1<eric.ernst> but to me i don't expect it to change and update /add / remove often.04:11
kata-irc-bot1<caoruidong> But what is the roll back policy?04:11
kata-irc-bot1<eric.ernst> Right - that's the more controversial part :)04:11
kata-irc-bot1<eric.ernst> its an error.04:11
kata-irc-bot1<bergwolf> For interface or for route table?04:11
kata-irc-bot1<eric.ernst> the workload won't work.04:11
kata-irc-bot1<eric.ernst> i think fail early and clearly is the way to go.04:11
kata-irc-bot1<archana.m.shinde> yeah, we talked about erroring out in that case04:11
kata-irc-bot1<eric.ernst> *but* - i haven't used this in production :slightly_smiling_face:04:11
kata-irc-bot1<zhangwei555> @eric.ernst Our scenario is also easy, actually we only need to set up the network once, so update isn't necessary04:12
kata-irc-bot1<archana.m.shinde> cause the application may depend on success of an operation04:12
kata-irc-bot1<caoruidong> For interface04:12
kata-irc-bot1<bergwolf> I think interface can be handled one by one04:12
kata-irc-bot1<bergwolf> at the API level04:13
kata-irc-bot1<archana.m.shinde> @zhangwei555 @bergwolf so we do not need updateInterface for now04:13
kata-irc-bot1<zhangwei555> I think updateInterface may be very necessary in future, though we don't use it at all now04:14
kata-irc-bot1<eric.ernst> ok cool, @zhangwei555 - do you expect to hit this error?04:14
kata-irc-bot1<eric.ernst> and do you see a reason to not fail at this poitn?04:14
kata-irc-bot1<bergwolf> I'm ok with no update interface for now04:14
kata-irc-bot1<eric.ernst> I think it's more clear to stop and error out.04:14
kata-irc-bot1<eric.ernst> rather than roll back in some form.04:14
kata-irc-bot1<zhangwei555> Yes.04:14
kata-irc-bot1<eric.ernst> the workload won't work.04:14
kata-irc-bot1<eric.ernst> if the network isn't configured, or configured as expected.04:14
kata-irc-bot1<zhangwei555> Rollback: after some consideration, I think we can remove the rollback part, as @eric.ernst said04:15
kata-irc-bot1<eric.ernst> (that also happens to make things much easier :D)04:15
kata-irc-bot1<zhangwei555> Instead, we just error out04:15
kata-irc-bot1<caoruidong> What API level? Sandbox API?04:16
kata-irc-bot1<bergwolf> yes, the APIs defined in virtcontainers/interface.go04:16
kata-irc-bot1<zhangwei555> UpdateInterface:   currently I'm fine without it, but in future, I think there's potential need that we want to scale out the pod, for example, adding a new container, add CPU or **add new interface**04:17
kata-irc-bot1<bergwolf> I think "add new interface" is supported by the `AddInterface` API not updateInterface04:17
kata-irc-bot1<eric.ernst> when it comes to agent, its all "update"04:18
kata-irc-bot1<zhangwei555> Oh, sorry, then it's my misunderstanding04:18
kata-irc-bot1<caoruidong> yes04:18
kata-irc-bot1<zhangwei555> I'm glad we have that04:18
kata-irc-bot1<eric.ernst> but from API level it can make sense to have both, I suppose.04:18
kata-irc-bot1<archana.m.shinde> it is till updateInterface in the agent for AddInterface04:18
kata-irc-bot1<eric.ernst> some of this we talke dthrough and tried to draw out, to hopefully add clarity (that silly UML i pasted)04:18
kata-irc-bot1<bergwolf> agent only needs "update" because it does not need to hotplug new nic devices when dealing with `AddInterface`04:19
kata-irc-bot1<archana.m.shinde> since we would coldplug/hotplug network interface in the the VM and then calll updateInterface in the agent to configure it04:19
kata-irc-bot1<eric.ernst> yep, @bergwolf -  and we'll need to augment the 'update' solution to add a timeout for waiting for the qmp to complete.04:19
kata-irc-bot1<eric.ernst> today we get update call, look for that mac address and if it doesn't exist we exit04:19
kata-irc-bot1<archana.m.shinde> yup, I have opened an issue in the agent to handle the above : https://github.com/kata-containers/agent/issues/30504:20
kata-irc-bot1<caoruidong> It happens rarely04:21
kata-irc-bot1<caoruidong> But I have met this04:21
kata-irc-bot1<zhangwei555> For hotplug, #305 is necessary04:21
kata-irc-bot1<bergwolf> @eric.ernst Just took a look. Agent actually has `AddInterface` and it is different than `UpdateInterface`. When runtime does hotplug, it needs to call `AddInterface` instead -- needs to be noted in the UML04:22
kata-irc-bot1<eric.ernst> yep.  So, that's going to be a pre-req.  as is the PR in govmm04:22
kata-irc-bot1<eric.ernst> yeah, but add interface isn't used in the runtime AFAIU, right?04:22
kata-irc-bot1<caoruidong> yes04:22
kata-irc-bot1<eric.ernst> it was added based on protocol definition.  but that one just creates a device inside the vm04:22
kata-irc-bot1<eric.ernst> ip link create04:22
kata-irc-bot1<eric.ernst> which isn't really tied to the host in anyway04:22
kata-irc-bot1<eric.ernst> I don't think that's the way we'd want to proceed.04:23
kata-irc-bot1<eric.ernst> We'd want to (1) do the qmp hotplug  and then (2) call updateInterface04:23
kata-irc-bot1<archana.m.shinde> @eric.ernst We should really be getting rid of AddInterface in the agent04:23
kata-irc-bot1<zhangwei555> I'm also thinking if we should merge `AddInterface` and `UpdateInterface` from agent protocol04:24
kata-irc-bot1<eric.ernst> no complaints from me.  I don't know who wrote that garbage code :$04:24
kata-irc-bot1<eric.ernst> yes, we should.  only one is needed.04:24
kata-irc-bot1<eric.ernst> update makes the most sense imo.04:24
kata-irc-bot1<eric.ernst> since the device exists  and we're updating it.04:24
kata-irc-bot1<eric.ernst> (to clarify, i wrote that code :))04:26
kata-irc-bot1<zhangwei555> Haha04:27
kata-irc-bot1<archana.m.shinde> @eric.ernst didnt want to mention it :grinning:04:27
kata-irc-bot1<caoruidong> And how about RemoveInterface? Do we need it?04:27
kata-irc-bot1<eric.ernst> I'm not sure, tbh.04:27
kata-irc-bot1<eric.ernst> It depends.04:27
kata-irc-bot1<eric.ernst> if we do a hot remove.04:27
kata-irc-bot1<eric.ernst> do we want to put the link down and delete it before removing the device?04:28
kata-irc-bot1<zhangwei555> I think so04:28
kata-irc-bot1<zhangwei555> Isn't is reasonable04:28
kata-irc-bot1<eric.ernst> if so, it is safe to keep the remove.04:28
kata-irc-bot1<bergwolf> that's a clean way04:28
kata-irc-bot1<eric.ernst> imo (i'm assuming this discussion is about agent protocol right now)04:28
kata-irc-bot1<archana.m.shinde> @eric.ernst Does it matter, I think hot unplug should just work04:29
kata-irc-bot1<bergwolf> yes, I think so04:29
kata-irc-bot1<archana.m.shinde> without bringing the interface down04:29
kata-irc-bot1<eric.ernst> feels a bit dirty, but I think this is a rare scenario.04:30
kata-irc-bot1<eric.ernst> I dno't know a real use case for hot unplug.04:30
kata-irc-bot1<zhangwei555> In most cases, I think we don't04:30
kata-irc-bot1<bergwolf> to support cni?04:31
kata-irc-bot1<bergwolf> I think cni has delete04:31
kata-irc-bot1<zhangwei555> @bergwolf I think that's a wonderful reason04:31
kata-irc-bot1<caoruidong> OK. Current PR sends QMP directly without RemoveInterface request. Need to add some code04:33
kata-irc-bot1<zhangwei555> I think @archana.m.shinde is suggesting that we don't need `RemoveInterface` request, we can only unplug with qmp04:34
kata-irc-bot1<zhangwei555> Am I right ? @archana.m.shinde @bergwolf04:34
kata-irc-bot1<archana.m.shinde> @zhangwei555 thats right04:34
kata-irc-bot1<bergwolf> does the kernel clean up the route rules of down nic as well?04:35
*** zerocoolback has quit IRC04:35
kata-irc-bot1<zhangwei555> I think so04:35
kata-irc-bot1<zhangwei555> but not sure04:35
kata-irc-bot1<eric.ernst> that gets to another discussion point -- in the flow - we really want to make sure that updateRoutes is called after interfaces are changed (added, removed)04:36
kata-irc-bot1<eric.ernst> at the very least after al lthe interfaces are added, or if any are changed.04:36
kata-irc-bot1<eric.ernst> since we write the routes all in a single shot.04:36
kata-irc-bot1<bergwolf> just tried locally -- it is cleaned up04:36
kata-irc-bot1<eric.ernst> (and would remove/readd)04:36
kata-irc-bot1<archana.m.shinde> If we have RemoveInterface, it should just call the qmp command to unplug device, I think that should be enough04:38
kata-irc-bot1<zhangwei555> So in current flow, we need to `UpdateInterface(1)`-->`UpdateInterface(2)`-->`UpdateInterface(3)`, then `UpdteRoute(1, 2, 3)`. Is that true?04:38
kata-irc-bot1<eric.ernst> yes.04:39
kata-irc-bot1<eric.ernst> that is definitely necessary04:39
kata-irc-bot1<archana.m.shinde> yes04:39
kata-irc-bot1<bergwolf> +104:39
kata-irc-bot1<eric.ernst> or you can do updateInterface(1) --> updateRoute(1) --> updateInterface(2) --> updateInterface(3) --> UpdateRoutes(1,2,3)04:40
kata-irc-bot1<zhangwei555> @archana.m.shinde Yes, it's true. We have a modified micro VM which removed the ACPI support(stupid change), in this case, unplug from qmp isn't enough. But that's so stupid "improvement", I'll ask them to change qemu back04:40
kata-irc-bot1<eric.ernst> the bottom line is nothing should be expected to workuntil you finish adding interfaces and then send the routes.04:40
kata-irc-bot1<eric.ernst> ip link delete isn't that expensive for the use case that will likely never happen?04:41
kata-irc-bot1<archana.m.shinde> @eric.ernst We dont have UpdateRoute, was that a typo?04:41
kata-irc-bot1<eric.ernst> yes.04:41
kata-irc-bot1<eric.ernst> s/route/routes04:41
kata-irc-bot1<caoruidong> So the CLI is still declarative and has just one command network update. In sandbox API, it splits to UpdateInterface, AddInterface RemoveInterface and UpdateRoutes ?04:41
kata-irc-bot1<eric.ernst> I saw that's the way it is today.  WDYT @bergwolf @zhangwei55504:42
*** lpetrut has quit IRC04:42
kata-irc-bot1<eric.ernst> When I talked with @sebastien.boeuf @archana.m.shinde we thought keeping seperate still made sense, but i'm amenable to this too.04:42
kata-irc-bot1<bergwolf> plus the two list APIs, yes04:42
kata-irc-bot1<zhangwei555> I think sandbox API should be "UpdateInterface" and `UpdateRoutes` ?04:42
kata-irc-bot1<eric.ernst> keep sandbox api same as what we have for agent?04:43
kata-irc-bot1<bergwolf> I agree. interface APIs are for one interface each, and routes are handled in a single shot04:44
kata-irc-bot1<zhangwei555> current Agent API: ``` 45     rpc AddInterface(AddInterfaceRequest) returns(Interface);                       46     rpc UpdateInterface(UpdateInterfaceRequest) returns (Interface);                47     rpc RemoveInterface(RemoveInterfaceRequest) returns (Interface);               48     rpc UpdateRoutes(UpdateRoutesRequest) returns (Routes);     ```  should be  ```                  46     rpc04:44
kata-irc-bot1UpdateInterface(UpdateInterfaceRequest) returns (Interface);                          48     rpc UpdateRoutes(UpdateRoutesRequest) returns (Routes);     ```04:44
kata-irc-bot1<zhangwei555> Am I wrong?04:44
kata-irc-bot1<eric.ernst> this is fine.  at the start of our chatting you mentioned wanting a list maybe?04:44
kata-irc-bot1<zhangwei555> Plus `list` of course04:44
kata-irc-bot1<eric.ernst> instead of relying what we have in store?04:44
kata-irc-bot1<bergwolf> plus list. I agree with @zhangwei55504:45
kata-irc-bot1<eric.ernst> ok.  so, what about at the kata CLI / API?04:45
kata-irc-bot1<eric.ernst> sandbox API - -same?04:45
kata-irc-bot1<bergwolf> AddInterface/UpdateInterface/RemoveInterface/ListInterfaces UpdateRoutes/ListRoutes ?04:46
kata-irc-bot1<zhangwei555> ```  rpc UpdateInterface(UpdateInterfaceRequest) returns (Interface);                         rpc UpdateRoutes(UpdateRoutesRequest) returns (Routes);     rpc ListInterfaces() returns ([]Interface);    rpc ListRoutes() returns (Routes);    ```04:46
kata-irc-bot1<zhangwei555> agent API04:46
kata-irc-bot1<eric.ernst> i think we'd want the add/remove too04:46
kata-irc-bot1<zhangwei555> Question: why AddInterface and RemoveInterface?04:47
kata-irc-bot1<eric.ernst> from CLI perspective, at the start there is no interface, right?04:47
kata-irc-bot1<bergwolf> @zhangwei555 I was suggesting the sandbox API04:47
kata-irc-bot1<eric.ernst> we're creating and QMPing it in.04:47
kata-irc-bot1<zhangwei555> I'm finding the issue04:47
kata-irc-bot1<archana.m.shinde> AddInterface/RemoveInterface/ListInterfaces UpdateRoutes/ListRoutes04:47
kata-irc-bot1<bergwolf> I think we all agreed on the agent APIs you listed above.04:47
kata-irc-bot1<eric.ernst> yes, agent we are good.  This is for sandbox API.04:48
kata-irc-bot1<eric.ernst> @zhangwei555 may be falling asleep already :P04:48
kata-irc-bot1<bergwolf> I'm fine to go w/o `UpdateInterface` for sandbox API btw.04:48
kata-irc-bot1<bergwolf> aha04:48
kata-irc-bot1<archana.m.shinde> So the sandbox API looks like : AddInterface/RemoveInterface/ListInterfaces UpdateRoutes/ListRoutes04:49
kata-irc-bot1<zhangwei555> That's fine :slightly_smiling_face:04:49
kata-irc-bot1<zhangwei555> https://github.com/kata-containers/runtime/issues/113#issuecomment-39385169304:49
kata-irc-bot1<zhangwei555> // "-" indicates input from stdio, "[filename]" means input from some file kata-runtime update-network <container> - | [filename] kata-runtime list-network <container> The input can contain enough information for setting up the network. a rough example:  { "interfaces": [   {     "name": "eth0",      "device": "tap0",     "ipv4":["192.168.0.2/24"， “192.168.1.2/24”],      "ipv6":["xxxx"],     "mac": "aa:bb:cc:dd:ee:aa",      "m04:49
kata-irc-bot11500,   },   {     "name": "eth1",      "device": "tap1",     "ipv4":["xxxx”],      "ipv6":["xxxx"],     "mac": "aa:bb:cc:dd:ee:bb",      "mtu": 1500,   } ], "route": [   {     "dest": "192.168.0.0/24",     "source": "192.168.0.2",     "gateway": "192.168.0.1",     "device": "eth0"   } ] }04:49
kata-irc-bot1<zhangwei555> For this CLI interface, I think `UpdateInterface` should be enough ? Meaning no `AddInterface` and `RemoveInterface`04:50
kata-irc-bot1<zhangwei555> the sandbox API looks like :UpdateInterface/ListInterfaces,  route API: UpdateRoutes/ListRoutes04:51
kata-irc-bot1<bergwolf> so the CLI network interface is declarative?04:52
kata-irc-bot1<zhangwei555> Yes04:52
kata-irc-bot1<bergwolf> ok, looks good to me then.04:52
kata-irc-bot1<bergwolf> UX feels better to be declarative04:52
kata-irc-bot1<eric.ernst> yes.  But, in this case....04:53
kata-irc-bot1<eric.ernst> how do you unplug?04:53
kata-irc-bot1<eric.ernst> updateInterface to remove a partiuluar interface with Mac address <>04:53
kata-irc-bot1<bergwolf> you call `update` with less interfaces, to unplug04:53
*** zerocoolback has joined #kata-dev04:53
kata-irc-bot1<eric.ernst> that means you are calling all the interfaecs.04:53
kata-irc-bot1<eric.ernst> and now we have to go through and compare what was added / removed?04:54
kata-irc-bot1<zhangwei555> Then you remove that one from the list, and send the new list to `UpdateInterface`, as @bergwolf said04:54
kata-irc-bot1<zhangwei555> Yes, with a compare04:54
kata-irc-bot1<zhangwei555> Actually, lots of compare when there's lots of interfaces04:54
kata-irc-bot1<eric.ernst> ok, so what's the CLI --> just "add network" and the json passed has all the info?04:54
kata-irc-bot1<zhangwei555> But I guess we won't give a container so many interfaces04:54
kata-irc-bot1<zhangwei555> Yes, that's right @bergwolf04:55
kata-irc-bot1<eric.ernst> That's the pain point (that compare), at least theoretically.  in practice I agree this is simple.04:55
kata-irc-bot1<caoruidong> CLI just "network update"04:55
kata-irc-bot1<archana.m.shinde> I prefer not to do any comparisons04:55
kata-irc-bot1<eric.ernst> network update and list netwrk?04:55
kata-irc-bot1<caoruidong> Yes @eric.ernst04:56
kata-irc-bot1<zhangwei555> @archana.m.shinde @eric.ernst I think someone from your side started the discussion of `declarative` and `imperative`. I think from UX, `declarative` is good for user interface04:56
kata-irc-bot1<archana.m.shinde> how about just doing network add and network delete ?04:56
kata-irc-bot1<eric.ernst> archana, but they are talking *whole* network here.04:57
kata-irc-bot1<eric.ernst> interfaces and routes04:57
kata-irc-bot1<eric.ernst> normally it'd get called once so the compare would fall through04:57
kata-irc-bot1<eric.ernst> i went through this thought exercise in the past for agent protocol.  I think from a user CLI perspective, dealing with the whole network rather than having to loop through is nicer.04:58
*** sjas has joined #kata-dev05:00
kata-irc-bot1<zhangwei555> Yes, following this rule, `network update` with a bunch of information(whole info) is nicer IMO05:00
kata-irc-bot1<bergwolf> either we do the comparison in kata CLI or we push the burden to CNI plugin coders ;)05:00
kata-irc-bot1<archana.m.shinde> so the CLI would deduce what needs to be added/deleted05:00
kata-irc-bot1<archana.m.shinde> ?05:00
*** LinuxMe has quit IRC05:00
kata-irc-bot1<eric.ernst> yeah... before I pushed it to the runtime from the agent.05:00
kata-irc-bot1<zhangwei555> Yes05:01
kata-irc-bot1<eric.ernst> i can't do that some push on the actual user.05:01
kata-irc-bot1<eric.ernst> I can abuse virtcontainers, not CNI coder.05:01
kata-irc-bot1<eric.ernst> the CLI would just receive the entire description.05:01
kata-irc-bot1<eric.ernst> and the runtime would then have to deduce to updateInterface, etc.05:01
kata-irc-bot1<bergwolf> one Q: how does k8s call cni? Does it call cni to setup/cleanup a single endpoint at a time?05:01
kata-irc-bot1<eric.ernst> or delete , etc.05:01
kata-irc-bot1<eric.ernst> generally, unless you use something like multus05:02
kata-irc-bot1<eric.ernst> where your cni plugin calls other cni plugins..05:02
kata-irc-bot1<eric.ernst> (right?)05:02
kata-irc-bot1<zhangwei555> Good question. I'm not sure .. @bergwolf05:02
*** sjas_ has quit IRC05:03
kata-irc-bot1<bergwolf> If that is the case, I think it would make sense to provide network add/delete CLI instead. otherwise CNI will need to do another comparison if we go declarative.05:03
kata-irc-bot1<zhangwei555> What would be the netowork add/delete CLI be ?05:04
kata-irc-bot1<zhangwei555> I don't have a full image in head05:04
kata-irc-bot1<archana.m.shinde> https://github.com/containernetworking/cni/blob/master/libcni/api.go05:04
kata-irc-bot1<eric.ernst> i think it'd just be updatenetwork.05:05
kata-irc-bot1<eric.ernst> no add or delete at CLI.05:06
kata-irc-bot1<eric.ernst> based on waht I tohught frank and tao were saying.05:06
kata-irc-bot1<eric.ernst> CLI: updateNetwork, listNetwork05:06
kata-irc-bot1<archana.m.shinde> I think CNI relies on Add, del and get commands for the plugin05:07
kata-irc-bot1<zhangwei555> if so, CLI command should be `network add/delete/list`05:07
*** LinuxMe has joined #kata-dev05:09
kata-irc-bot1<eric.ernst> some initial next steps that will gate merging this functionality: ```1) update govmm - PR: https://github.com/intel/govmm/pull/24 2) update Agents updateInterface function to include timeout (to facilitate qmp) - https://github.com/kata-containers/agent/issues/305 3) update complete UML to describe the flow based on what we (finally agree to) for the CLI down to the agent and QEMU 4) get this PR updated/cleaned-up to make third05:12
kata-irc-bot1item.```   #1,2,3 are parallel, and i'm hoping #3 can be done after we finalize this discussion now05:12
kata-irc-bot1<eric.ernst> @zhangwei555 this add/del/get is based on how yo'd call our CLI from a kata specific CNI plugin?05:14
*** LinuxMe has quit IRC05:14
kata-irc-bot1<eric.ernst> b/c in general AFAIU they aren't calling us directly today- they just drop whatever they want in a namespace.05:14
kata-irc-bot1<eric.ernst> #4 isn't that far off at all - just need clarity on #305:15
kata-irc-bot1<raravena80> I wonder what the use case for network hotplug on k8s is. Anybody has ideas?05:15
kata-irc-bot1<zhangwei555> @eric.ernst yes, but we understand kata better,  we can do the network management better, and I don't need to drop the interface in the namespace05:16
kata-irc-bot1<zhangwei555> @raravena80 I think traditional CNI plugin should works after `pause` container is up, at that time the VM is also up05:17
kata-irc-bot1<eric.ernst> So, in the huawei case, would your single CNI plugin request multiple networks?05:17
kata-irc-bot1<eric.ernst> or woudl you expect individual CNI plugins to be called ala something like multus?05:17
kata-irc-bot1<zhangwei555> we don't have multiple network now, so didn't hit this case yet05:17
kata-irc-bot1<eric.ernst> k.05:17
kata-irc-bot1<zhangwei555> But better leave some space for future extension, aka multus05:18
kata-irc-bot1<caoruidong> CLI: ? ```rpc UpdateInterface(UpdateInterfaceRequest) returns (Interface);                         rpc UpdateRoutes(UpdateRoutesRequest) returns (Routes);     rpc ListInterfaces() returns ([]Interface);    rpc ListRoutes() returns (Routes);```     agent API05:18
kata-irc-bot1<eric.ernst> if we do a single "updateNetowrk" CLI call, then we could actually be putting burden on caller to do a "listinterfaces" and "listroutes" call in order to add their single interface/simple route05:20
kata-irc-bot1<eric.ernst> unless they are adding all of the network items (i'm again thinking about calling multiple CNI plugins)05:21
kata-irc-bot1<eric.ernst> for CLI, @caoruidong -  can you clarify?05:22
kata-irc-bot1<eric.ernst> ie, addInterface, deleteInterface, listInterface?  or is it add/delete/list network?05:22
kata-irc-bot1<zhangwei555> @eric.ernst That can work, but leaves the burder to caller, and makes the CLI not that fancy05:22
kata-irc-bot1<eric.ernst> yeah, agreed @zhangwei55505:23
kata-irc-bot1<eric.ernst> sandbox and agent are clear.  just need that last top bit :slightly_smiling_face:05:23
kata-irc-bot1<zhangwei555> So, difficult decision  :,(05:23
kata-irc-bot1<eric.ernst> easiest thing is to make it same as sandbox api :slightly_smiling_face:05:24
kata-irc-bot1<eric.ernst> i'm just not sure what @caoruidong was suggesting05:24
kata-irc-bot1<archana.m.shinde> that would be the simpler approach :slightly_smiling_face:05:24
kata-irc-bot1<zhangwei555> `easiest thing is to make it same as sandbox api` Agree05:25
kata-irc-bot1<caoruidong> Since we are discussing . So I tag a "?"05:26
kata-irc-bot1<eric.ernst> kk05:26
kata-irc-bot1<eric.ernst> @bergwolf wdyt?05:26
kata-irc-bot1<bergwolf> +1 to making it the same as sandbox API. Assuming there are no kata-runtime CNIs yet. We can make the rules here ;)05:27
kata-irc-bot1<eric.ernst> i'm not 100% who will call the CLI, tbh, so its harder for me to decide.05:27
kata-irc-bot1<eric.ernst> :slightly_smiling_face:05:27
kata-irc-bot1<eric.ernst> they'll have to do some work to make the routes appropriate.05:27
kata-irc-bot1<zhangwei555> I think it's CNI plugin from advance users and "network-monitor" in developing05:27
kata-irc-bot1<eric.ernst> and we'll have to makesure that's clear05:27
kata-irc-bot1<archana.m.shinde> considering how CNI plugins are called, +1 for making same as sandbox api05:28
kata-irc-bot1<bergwolf> let's provide fundamental building blocks and CNI plugin coders can play with it05:28
kata-irc-bot1<eric.ernst> ok.  so, can someone put together the now simpler UML diagram for these scenarios?  And if ya'll can review the govmm PR so we can get that moving tomorrow, i hope05:28
kata-irc-bot1<eric.ernst> @archana.m.shinde were you planning to look at the timeout for agent?05:29
kata-irc-bot1<bergwolf> I'll take a look at the govmm PR05:29
kata-irc-bot1<eric.ernst> and we should open an issue to track removal of the unused agent proto functions05:29
kata-irc-bot1<archana.m.shinde> yeah, I can take a look at the agent change05:30
kata-irc-bot1<eric.ernst> k.05:30
kata-irc-bot1<eric.ernst> 1 and 2 shoudl be good.  need #3 from someone.05:30
kata-irc-bot1<zhangwei555> Double check: CLI: network add / delete /list ?  (e.g. input for add/delete: {interface1, interface2, route1, route2}) Sandbox API : AddNetwork/RemoveNetwork/ListNetwork ? agent API：UpdateInterface，UpdateRoutes，ListInterfaces，ListRoutes (agreed) (edited)05:30
kata-irc-bot1<archana.m.shinde> unless someone else wants to :slightly_smiling_face:05:30
kata-irc-bot1<eric.ernst> and then frank shoud have straight forward fun with finishing it up05:30
kata-irc-bot1<eric.ernst> oh05:31
kata-irc-bot1<eric.ernst> i thought it was CLI: add / delete /list ? Sandbox API : AddInterface/RemoveInterface/ListInterfaces, UpdateRoutes/ListRoutes ? agent API：UpdateInterface，UpdateRoutes，ListInterfaces，ListRoutes (agreed) (edited)05:31
kata-irc-bot1<zhangwei555> Ok, I see05:31
kata-irc-bot1<eric.ernst> hehe.  its good to dopubel check.  Can others weigh in?05:31
kata-irc-bot1<eric.ernst> i'm tired.  its nap time for both of us.05:32
kata-irc-bot1<eric.ernst> let's let others clarify.05:32
kata-irc-bot1<caoruidong> So drop the CLI and Sandbox UpdateInterface ?05:32
kata-irc-bot1<zhangwei555> Haha ,I  agree. Hungry now05:32
kata-irc-bot1<eric.ernst> if we don't have a usecase, yes.05:32
kata-irc-bot1<eric.ernst> easier to add later rather than remove05:32
kata-irc-bot1<bergwolf> I can take #3 @eric.ernst05:33
kata-irc-bot1<eric.ernst> thanks @bergwolf05:33
kata-irc-bot1<bergwolf> I can draw something in the afternoon.05:33
kata-irc-bot1<zhangwei555> Thanks. I just want to say I can take it but I also have some other things to handle, so it's good to have you05:33
kata-irc-bot1<zhangwei555> :)05:33
kata-irc-bot1<caoruidong> OK I'm clear. And I will update the govmm PR and hotplug PR05:34
kata-irc-bot1<eric.ernst> awesome.05:34
kata-irc-bot1<archana.m.shinde> cool05:34
kata-irc-bot1<bergwolf> nice. so are we all set?05:34
kata-irc-bot1<eric.ernst> if any of ya'll talk with @miao.yanqiang - i'd like to make sure he gets a look at the UML once its done.05:34
kata-irc-bot1<eric.ernst> I hope we are.05:34
kata-irc-bot1<eric.ernst> thanks ya'll.05:35
kata-irc-bot1<caoruidong> one nit: The CLI is add interface or add interfaces?05:35
kata-irc-bot1<eric.ernst> interface05:35
kata-irc-bot1<bergwolf> I'll ping @miao.yanqiang on wechat05:35
kata-irc-bot1<eric.ernst> ttyl05:36
*** eernst has quit IRC05:36
kata-irc-bot1<archana.m.shinde> alrite, thanks everyone :slightly_smiling_face:05:36
kata-irc-bot1<zhangwei555> ``` 1) update govmm - PR: https://github.com/intel/govmm/pull/24   --- @bergwolf review 2) update Agents updateInterface function to include timeout (to facilitate qmp) - https://github.com/kata-containers/agent/issues/305  -- @amshinde  3) update complete UML to describe the flow based on what we (finally agree to) for the CLI down to the agent and QEMU   @bergwolf  4) get this PR updated/cleaned-up to match third item. ```  and05:36
kata-irc-bot1API CLI: (same as sandbox) Sandbox API : AddInterface/RemoveInterface/ListInterfaces, UpdateRoutes/ListRoutes ? agent API：UpdateInterface，UpdateRoutes，ListInterfaces，ListRoutes (agreed) (edited) (edited)05:36
kata-irc-bot1<bergwolf> good night @eric.ernst @archana.m.shinde Thanks for your time~05:37
kata-irc-bot1<bergwolf> nice memo @zhangwei55505:37
kata-irc-bot1<zhangwei555> I'm tired too  x)05:37
kata-irc-bot1<caoruidong> Thank you all. Good night:grinning:05:37
kata-irc-bot1<bergwolf> ha, /me -> lunch05:38
kata-irc-bot1<bergwolf> ttyl05:38
*** zerocoolback has quit IRC05:38
*** zerocoolback has joined #kata-dev05:42
*** LinuxMe has joined #kata-dev05:42
*** LinuxMe has quit IRC05:47
*** EricAdamsZNC2 has quit IRC06:08
*** EricAdamsZNC has joined #kata-dev06:08
kata-irc-bot1<sebastien.boeuf> oh man that's a huge conversation, and I'm glad you went through all the bullet points that needed to be discussed!  That's really cool that you all agreed on the different API levels: CLI: `add-iface`, `del-iface`, `list-ifaces`, `update-routes`, `list-routes` Sandbox API: `AddInterface`, `RemoveInterface`, `ListInterfaces`, `UpdateRoutes`, `ListRoutes` Agent API: `UpdateInterface`, `UpdateRoutes`, `ListInterfaces`,06:25
kata-irc-bot1`ListRoutes`  Also, a few key points where everybody agreed: - Routes need to be updated after any `AddInterface()` or `RemoveInterface()`. This will be the caller responsibility to take care of this. - We need `ListInterfaces()` and `ListRoutes()` to both go all the way to the agent, and return what is really seen by the agent inside the VM - The agent API will be simply updated by removing not needed API `AddInterface()` and `RemoveInterface()`06:25
kata-irc-bot1- We need the agent to handle an interface being hotplugged, basically using uevents - The Sandbox API will simply error whenever something wrong happens, without trying to rollback anything  Now, there's one thing that is not clear from the conversation is the part about the parameters we will provide to and receive from  `AddInterface()` and `RemoveInterface()` from the Sandbox API: - Those functions will receive one single interface since it06:25
kata-irc-bot1will avoid virtcontainers from figuring out from a list of interfaces which one has to be added or removed. Is that correct? - Those functions will return the interface details, no matter the action ended up with error or success. Is that correct?06:25
kata-irc-bot1<sebastien.boeuf> @eric.ernst @archana.m.shinde @bergwolf @zhangwei555 @caoruidong ^06:26
*** lpetrut has joined #kata-dev06:26
kata-irc-bot1<sebastien.boeuf> Actually, let me copy/paste all of this into the proper github issue, this will help not loosing the thread of this conversation06:27
*** libregeekingkid has joined #kata-dev06:29
kata-irc-bot1<zhangwei555> I think that's correct @sebastien.boeuf, it's a very clear description :+1:06:38
*** jodh has joined #kata-dev06:39
*** jodh has quit IRC06:39
*** jodh has joined #kata-dev06:39
*** lpetrut_ has joined #kata-dev07:35
*** jugs has quit IRC07:37
*** lpetrut has quit IRC07:38
*** jugs has joined #kata-dev07:39
*** gwhaley has joined #kata-dev07:54
*** sameo has joined #kata-dev07:59
*** davidgiluk has joined #kata-dev08:04
*** gwhaley has quit IRC11:03
*** dlw1 has joined #kata-dev11:32
*** dlw has quit IRC11:34
*** dlw1 is now known as dlw11:34
*** dlw has quit IRC11:46
*** fuentess has joined #kata-dev11:56
*** devimc has joined #kata-dev11:58
*** dlw has joined #kata-dev12:11
*** gwhaley has joined #kata-dev12:16
*** lpetrut has joined #kata-dev12:18
*** lpetrut_ has quit IRC12:18
*** lamego has joined #kata-dev13:07
*** dlw has quit IRC13:09
*** LinuxMe has joined #kata-dev13:16
*** LinuxMe has quit IRC13:21
*** LinuxMe_ has joined #kata-dev13:35
*** sameo has quit IRC14:10
*** eernst has joined #kata-dev14:27
kata-irc-bot1<eric.ernst> Yes, singular, not prlural @sebastien.boeuf14:28
kata-irc-bot1<eric.ernst> And while they shoudl return the state of the interface, there won't be any 'roll back' logic inside kata containers14:28
*** annabelleB has joined #kata-dev14:49
*** lpetrut has quit IRC14:54
*** sameo has joined #kata-dev15:05
*** libregeekingkid has quit IRC15:07
*** libregeekingkid has joined #kata-dev15:07
*** LinuxMe_ has quit IRC15:25
*** eernst has quit IRC15:43
*** eernst has joined #kata-dev15:51
*** LinuxMe has joined #kata-dev16:01
*** LinuxMe has quit IRC16:05
*** LinuxMe has joined #kata-dev16:07
*** annabelleB has quit IRC16:12
*** annabelleB has joined #kata-dev16:18
kata-irc-bot1<sebastien.boeuf> @george.kennedy Hi!16:24
kata-irc-bot1<sebastien.boeuf> question about your PR16:25
kata-irc-bot1<sebastien.boeuf> are you working on your forked branch ?16:25
*** jodh has quit IRC16:46
kata-irc-bot1<eric.ernst> @caoruidong we ended up merging https://github.com/intel/govmm/pull/24.  One comment, though - can you verify and clarify the behavior when queue is not set?  Please verify and add a comment stating that if it isn't specificied a single queue is provided?17:05
*** sameo has quit IRC17:05
*** gwhaley has quit IRC17:15
*** annabelleB has quit IRC17:44
*** jugs has quit IRC17:46
*** jugs has joined #kata-dev17:53
*** annabelleB has joined #kata-dev17:54
*** zerocoolback has quit IRC18:06
*** zerocool_ has joined #kata-dev18:07
*** libregeekingkid has quit IRC18:08
kata-irc-bot1<eric.ernst> @sebastien.boeuf @archana.m.shinde anyone around to ack a very simple PR?  https://github.com/kata-containers/documentation/pull/19818:09
kata-irc-bot1<sebastien.boeuf> @eric.ernst done but you need docs approval18:09
kata-irc-bot1<eric.ernst> no i don't.18:09
kata-irc-bot1<eric.ernst> one word change in a command.18:10
kata-irc-bot1<eric.ernst> @james.o.hunt’s proposal should cover this one (simple one liners not needing?)18:10
kata-irc-bot1<sebastien.boeuf> lol ok18:10
kata-irc-bot1<sebastien.boeuf> I am fine with that too18:10
kata-irc-bot1<eric.ernst> well, in general.18:10
kata-irc-bot1<eric.ernst> I guess because you're french you're not part of documentation approvers g roup18:11
kata-irc-bot1<eric.ernst> hrmm18:11
kata-irc-bot1<eric.ernst> @gabriela.cervantes.te can you PTAL?  :slightly_smiling_face:18:11
kata-irc-bot1<sebastien.boeuf> @eric.ernst meee not spik guud enaf inglich18:12
*** fiddletwix has joined #kata-dev18:12
kata-irc-bot1<sebastien.boeuf> I might start a new language though ;)18:12
kata-irc-bot1<archana.m.shinde> @eric.ernst merged :slightly_smiling_face:18:12
*** zerocool_ has quit IRC18:17
*** LinuxMe has quit IRC18:19
*** LinuxMe has joined #kata-dev18:20
*** LinuxMe has quit IRC18:25
kata-irc-bot1<archana.m.shinde> @sebastien.boeuf Can you take a look at this : https://github.com/kata-containers/runtime/pull/50718:30
*** LinuxMe has joined #kata-dev18:31
*** dklyle has quit IRC19:03
*** LinuxMe has quit IRC19:08
*** LinuxMe has joined #kata-dev19:10
*** davidgiluk has quit IRC19:22
*** libregeekingkid has joined #kata-dev19:30
*** annabelleB has quit IRC19:36
*** annabelleB has joined #kata-dev19:43
*** annabelleB has quit IRC20:35
*** annabelleB has joined #kata-dev20:40
*** annabelleB has quit IRC20:40
*** annabelleB has joined #kata-dev20:53
*** devimc has quit IRC21:05
*** annabelleB has quit IRC21:07
*** LinuxMe has quit IRC21:08
*** annabelleB has joined #kata-dev21:08
*** LinuxMe has joined #kata-dev21:08
*** LinuxMe has quit IRC21:10
*** LinuxMe has joined #kata-dev21:10
*** LinuxMe has quit IRC21:28
*** LinuxMe_ has joined #kata-dev21:34
*** dklyle has joined #kata-dev21:38
*** LinuxMe_ has quit IRC21:48
*** annabelleB has quit IRC21:56
*** annabelleB has joined #kata-dev22:03
*** LinuxMe has joined #kata-dev22:08
*** annabelleB has quit IRC22:14
*** annabelleB has joined #kata-dev22:15
*** lamego has left #kata-dev22:58
*** eernst has quit IRC23:03
*** annabelleB has quit IRC23:09
*** LinuxMe has quit IRC23:18
*** kata-irc-bot1 has quit IRC23:50
*** kata-irc-bot has joined #kata-dev23:50
*** LinuxMe has joined #kata-dev23:52
*** LinuxMe has quit IRC23:56
« Tuesday, 2018-07-24 Index Thursday, 2018-07-26 »

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