| *** igordc has quit IRC | 01:02 | |
| *** auk has joined #kata-dev | 01:06 | |
| *** eernst has joined #kata-dev | 01:10 | |
| *** eernst has quit IRC | 01:14 | |
| *** eernst has joined #kata-dev | 01:50 | |
| *** eernst has quit IRC | 01:53 | |
| *** zhenyuw has quit IRC | 03:10 | |
| *** zhenyuw has joined #kata-dev | 03:11 | |
| *** sameo has joined #kata-dev | 04:51 | |
| kata-irc-bot | <bergwolf> ^^ related issue: https://github.com/kata-containers/runtime/issues/753 | 06:02 |
|---|---|---|
| kata-irc-bot | <bergwolf> My initial reaction was to just send a set of options via a single annotation, then I remembered the above issue and if we have a structured way to do so, it looks better. | 06:04 |
| kata-irc-bot | <bergwolf> Yes, I agree, There is already sysctl fields in the `RunSandbox` CRI request. We should make sure it is passed to kata and use it to set the pod level sysctl w/o giving any containers extra privilege. https://github.com/kubernetes/cri-api/blob/master/pkg/apis/runtime/v1alpha2/api.proto#L290 | 06:13 |
| kata-irc-bot | <bergwolf> @zhangwei555 yes, runtime handler effectively allows the similar functionality, -- we just need to create a handler for each config combination we want. Then the only benefit of having an annotation is not having to pre-define things. I guess the need for dynamic config is not strong at all. | 06:21 |
| kata-irc-bot | <zhangwei555> I‘m not sure how many configurations are suitable to be defined as POD level. Things like "sysctl" params are already included in OCI config. Some Kernel Params may need to be dynamic but I'm not sure if there's strong requirements...What's the specific kernel params we are talking about in the thread? | 06:26 |
| kata-irc-bot | <zhangwei555> I just finished the thread reading... for things like `/proc/sys/vm/max_map_count`, how about let container application write to it directly if we allow it to have such privilege? | 06:30 |
| *** auk has quit IRC | 06:40 | |
| kata-irc-bot | <bergwolf> @zhangwei555 There are actually two discussion threads (kata config vs. sysctl handling ;) sorry for making it confusing as I was late for the discussion (which happened at midnight for me) | 06:44 |
| kata-irc-bot | <bergwolf> Let's put the kata config discussion in-thread and keep the board for sysctl handling. | 06:45 |
| kata-irc-bot | <bergwolf> bergwolf [2:21 PM] @zhangwei555 yes, runtime handler effectively allows the similar functionality, -- we just need to create a handler for each config combination we want. Then the only benefit of having an annotation is not having to pre-define things. I guess the need for dynamic config is not strong at all. | 06:45 |
| *** sameo has quit IRC | 06:46 | |
| kata-irc-bot | <bergwolf> @zhangwei555 Thinking a bit more about it, I think there are real needs for dynamic per pod kata config. E.g., if we want to support @eric.ernst’s sandbox overhead proposal, we need to be able to set sandbox's extra resource (CPU/memory) on a per pod basis, which is only done at node level in the config. It is still possible to define many kata runtime-handlers to support each of the overhead metrics. Then how many do we want to add a | 06:50 |
| kata-irc-bot | how do we know they are enough? I think dynamical config is better than pre-defined static config in this case. | 06:50 |
| kata-irc-bot | <bergwolf> > for things like `/proc/sys/vm/max_map_count`, how about let container application write to it directly if we allow it to have such privilege? I think we should separate pod level sysctl and container level sysctl. For the former ones, we do not give containers any privilege, and just set it in the vm. For the latter ones, containers are required to declare proper privilege in its config. | 06:55 |
| *** sgarzare has joined #kata-dev | 07:12 | |
| *** tmhoang has joined #kata-dev | 07:14 | |
| *** zhenyuw has quit IRC | 07:21 | |
| *** zhenyuw has joined #kata-dev | 07:22 | |
| *** sameo has joined #kata-dev | 07:43 | |
| *** tmhoang has quit IRC | 07:47 | |
| *** zhenyuw has quit IRC | 08:46 | |
| kata-irc-bot | <zhangwei555> Yes, this is a good example. I think dynamic config via "label/annotation" makes sense. My point is we don't need to handle *any* configuration from configuration.toml, we can provide only a small subset of "configs" at pod/container granularity. | 08:47 |
| *** tmhoang has joined #kata-dev | 09:17 | |
| *** davidgiluk has joined #kata-dev | 09:25 | |
| *** sameo has quit IRC | 10:01 | |
| *** sameo has joined #kata-dev | 10:57 | |
| *** brtknr has joined #kata-dev | 12:03 | |
| *** devimc has joined #kata-dev | 13:08 | |
| *** lpetrut has joined #kata-dev | 13:26 | |
| *** fuentess has joined #kata-dev | 13:37 | |
| *** jodh has joined #kata-dev | 13:40 | |
| *** lpetrut has quit IRC | 14:00 | |
| kata-irc-bot | <sebastien.boeuf> davidgiluk: hi, around? | 14:05 |
| *** devimc_ has joined #kata-dev | 14:57 | |
| *** devimc_ has quit IRC | 14:57 | |
| *** lpetrut has joined #kata-dev | 14:59 | |
| *** lpetrut has quit IRC | 15:14 | |
| *** tmhoang has quit IRC | 15:46 | |
| *** sameo has quit IRC | 15:53 | |
| *** sgarzare has quit IRC | 16:02 | |
| davidgiluk | sebastien: Yep | 16:10 |
| *** jodh has quit IRC | 17:01 | |
| *** davidgiluk has quit IRC | 18:59 | |
| *** igordc has joined #kata-dev | 20:15 | |
| *** devimc has quit IRC | 22:00 | |
| *** fuentess has quit IRC | 22:24 | |
| *** eernst has joined #kata-dev | 22:50 | |
| *** eernst has quit IRC | 22:53 | |
| kata-irc-bot | <eric.ernst> @archana.m.shinde the initrd failure CI for https://github.com/kata-containers/runtime/pull/1458 seems like noise | 23:13 |
| kata-irc-bot | <eric.ernst> Wdyt? | 23:13 |
| kata-irc-bot | <archana.m.shinde> yeah just commented about the same :slightly_smiling_face: | 23:13 |
| kata-irc-bot | <archana.m.shinde> @eric.ernst ^ | 23:14 |
| kata-irc-bot | <eric.ernst> Let’s merge... | 23:15 |
| kata-irc-bot | <eric.ernst> Same in agent? | 23:15 |
| kata-irc-bot | <eric.ernst> Ptal? | 23:15 |
| kata-irc-bot | <eric.ernst> Just a ppc failure for Initrd | 23:15 |
| kata-irc-bot | <archana.m.shinde> @eric.ernst yup, ppc has never passed for the agent | 23:16 |
| kata-irc-bot | <archana.m.shinde> we can merge | 23:16 |
| kata-irc-bot | <eric.ernst> Done. | 23:21 |
| kata-irc-bot | <eric.ernst> For both. | 23:21 |
| kata-irc-bot | <eric.ernst> Will start looking at stable release tonight. | 23:22 |
| kata-irc-bot | <archana.m.shinde> ok | 23:22 |
| kata-irc-bot | <archana.m.shinde> @eric.ernst Whats the flow these days, do we port the fixes to last two stable releases | 23:23 |
| kata-irc-bot | <archana.m.shinde> or you will be taking care of that | 23:23 |
| kata-irc-bot | <eric.ernst> I don’t want to do it. | 23:23 |
| kata-irc-bot | <eric.ernst> Can you send PR for the agent change back? | 23:23 |
| kata-irc-bot | <eric.ernst> To stable 1.5 and 1.6v | 23:24 |
| kata-irc-bot | <archana.m.shinde> yeah I'll backport in the agent and the runtime | 23:24 |
| kata-irc-bot | <eric.ernst> I’m not sure if we should in runtime or not? | 23:24 |
| kata-irc-bot | <eric.ernst> If we have the “backup” available? | 23:24 |
| kata-irc-bot | <xwlpt> Hi Does this lock really need to be for all of the operations of the container: https://github.com/kata-containers/runtime/blob/master/containerd-shim-v2/service.go#L355 I don’t see this lock is need for runc in all of the oeperations like Delete/State? | 23:24 |
| kata-irc-bot | <xwlpt> @eric.ernst | 23:24 |
| kata-irc-bot | <eric.ernst> @archana.m.shinde ^? | 23:25 |
| kata-irc-bot | <eric.ernst> @bergwolf ^? | 23:25 |
| kata-irc-bot | <archana.m.shinde> not sure, havent looked at shimv2 very closely | 23:28 |
| kata-irc-bot | <sebastien.boeuf> @fupan ^ | 23:53 |
| kata-irc-bot | <xwlpt> Another question: https://github.com/kata-containers/runtime/blob/master/virtcontainers/sandbox.go#L706 It says the VM will be shut down, but where is the logical that stop the VM? | 23:56 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!