Thursday, 2019-01-24

*** eernst_ has joined #kata-dev00:09
*** eernst_ has quit IRC00:10
*** eernst_ has joined #kata-dev00:13
*** eernst_ has quit IRC00:17
*** dklyle has quit IRC00:42
kata-irc-bot<xwlpt> I am now trying kata at k8s.  Inside the container, the empty-dir volume will be mounted as tmpfs.  I write the data to the dir inside the container, and I can not see the data inside the empty dir at the host.  From this behavior, empty dir data will lost after container restart. This is not aligned with K8S + docker behavior.  Is this an issue, or may I miss something?01:51
kata-irc-bot<xwlpt> @graham.whaley @eric.ernst01:53
kata-irc-bot<xu> just found the `kata-containers/documentatio`n team doesn’t have write permission of the `kata-containers/documentation` repo, should we add the permission to the team?02:30
kata-irc-bot<xu> :point_up:02:31
kata-irc-bot<xu> @xwlpt is this an expected behavior of kubernetes in documents or specifications? When you say “after container restart”, do you mean restart the pod or restart a container inside a running pod?02:51
kata-irc-bot<xwlpt> I mean restart the container inside a running pod.02:52
kata-irc-bot<xwlpt> https://kubernetes.io/docs/concepts/storage/volumes/#emptydir02:54
kata-irc-bot<xwlpt> Note: A Container crashing does NOT remove a Pod from a node, so the data in an emptyDir volume is safe across Container crashes.02:54
kata-irc-bot<xu> Sorry, I mean the behavior “access the empty dir from the host”02:57
kata-irc-bot<xwlpt> It the behavior for testing. But this is not impact the test result.  User will write data to emptyDir inside container, if this data is not persisted at the host, then the data will lost after container crash.02:59
kata-irc-bot<xu> When we create the tmpfs inside a kata sandbox, the host won’t have access to it but it can persist till the sandbox is destroyed even the container is stopped. (If not this may be a fixable bug)03:00
kata-irc-bot<xu> However, if the accessibility from host is essential, we have to move the emptydir outside and access with filesystem sharing (9p for now). This would be a hard decision….03:02
kata-irc-bot<xwlpt> I see. So the data will still lost after sandbox destroyed.03:06
kata-irc-bot<xu> but that’s mean the pod is killed03:06
*** dklyle has joined #kata-dev03:07
kata-irc-bot<xwlpt> For sandbox destroyed, do you mean we kill the qemu process?03:07
kata-irc-bot<xwlpt> Or qemu process crash ?03:08
kata-irc-bot<xwlpt> So I think this is not the same with pod deleted/03:08
kata-irc-bot<xu> I just describe a situation the sandbox is stopped, it may be - CRI client issue the request to kill the sandbox (same thing happens for docker case) - Something unexpected happens to kill the sandbox such as someone killing the process, host or guest crashing. (same thing happens for docker case as well)  normal or abnormal, same for docker case. if pod is deleted from kube client, the CRI will kill the sandbox as well.03:13
*** devananda has quit IRC03:17
kata-irc-bot<xwlpt> For host crash, like restart the node, pod will recreated, since pod id is not changed, the empty dir data will not lost too.03:17
kata-irc-bot<xwlpt> @xu03:18
kata-irc-bot<xwlpt> But for kata case, as you mentioned, the data will lost.03:20
kata-irc-bot<xwlpt> It is different03:20
*** dklyle has quit IRC03:21
kata-irc-bot<xu> IIRC, kubernetes won’t guarantee the pod will be recreated03:21
kata-irc-bot<xu> And if the backend is tmpfs, a restart of host will lead to lose it03:21
kata-irc-bot<xwlpt> No,  k8s will make sure containers for pod recreated unless it is evicted or deleted.   @xu I just mention the empty dir case that not use tmpfs (without emptyDir.medium field set to tmpfs).03:25
kata-irc-bot<xwlpt> Is it not a case kata should consider?03:26
kata-irc-bot<xu> Yes, this is what I wonder. what’s the expected behavior in kubernetes.  From my assumption, the lost of empdir is tolerable in kubernetes because that’s not a persistent volume, and the tmpdir based implementation will bring better isolation and performance. However, if the assumption is wrong, we had to modify our behavior.03:33
kata-irc-bot<xwlpt> Another issue use tmpfs is user need to request more memory if it use emptyDir. This will make not the deploy spec not consistent. And for k8s, there will less pod can be scheduled to the same node. It is better to make it not default to be tmpfs via configuration.03:43
kata-irc-bot<xwlpt> @xu thanks for the classifcation.03:43
kata-irc-bot<xu> Agree, the memory consumption has still been a pain for me to make the decision.03:45
*** dklyle has joined #kata-dev04:20
kata-irc-bot<raravena80> @xwlpt `emptyDir` is generally used more as a temp cache, if you want to preserve the data on the host you should probably use `hostPath`04:35
*** stackedsax has quit IRC04:49
kata-irc-bot<xwlpt> @raravena80 The issue for hostpath is that it will not be cleaned after pod deleted.05:26
kata-irc-bot<raravena80> @xwlpt you can probably use a `PreStop` container lifetime hook for that: https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/06:02
kata-irc-bot<xwlpt> @raravena80 Good idea. Thanks06:02
*** stackedsax has joined #kata-dev07:58
*** sameo_ has joined #kata-dev08:09
*** jodh has joined #kata-dev08:42
*** jodh has quit IRC08:53
*** jodh_ has joined #kata-dev08:54
*** davidgiluk has joined #kata-dev09:03
*** gwhaley has joined #kata-dev09:33
kata-irc-bot<graham.whaley> @xu - I think the documentation team not having write (and thus commit/merge?) perms to the docs repo is a hangover from long ago, when we probably had a couple of 'real' documentation folks who did docs review, but the merges were still done by the kata devs.  I will go and enable write perms for the docs team on the docs repo, as that really does 'feel like the right thing'. I don't think we are in any danger of 'accidental11:14
kata-irc-botmerges'...11:14
*** gwhaley has quit IRC11:53
*** Bhujay has joined #kata-dev11:55
*** gwhaley has joined #kata-dev12:57
*** dklyle has quit IRC15:41
*** jodh_ has quit IRC15:46
*** dklyle has joined #kata-dev16:04
*** LinuxMe has joined #kata-dev16:29
*** LinuxMe has quit IRC16:33
*** LinuxMe has joined #kata-dev16:34
*** eernst has joined #kata-dev16:40
*** Bhujay has quit IRC16:44
*** LinuxMe has quit IRC16:44
*** eernst has quit IRC16:47
*** LinuxMe has joined #kata-dev16:54
*** sameo_ has quit IRC16:55
*** LinuxMe has quit IRC16:59
*** dklyle has quit IRC17:40
*** dims has quit IRC17:43
*** dims has joined #kata-dev17:48
*** dklyle has joined #kata-dev17:50
*** dims has quit IRC17:54
*** dims has joined #kata-dev17:55
*** sameo_ has joined #kata-dev17:57
*** jugs has quit IRC17:58
*** jugs has joined #kata-dev17:58
*** gwhaley has quit IRC18:02
*** dklyle has quit IRC19:37
*** sameo__ has joined #kata-dev19:42
*** sameo_ has quit IRC19:42
*** dklyle has joined #kata-dev20:15
*** davidgiluk has quit IRC20:17
*** LinuxMe has joined #kata-dev22:05
*** sameo__ has quit IRC22:06
*** dklyle has quit IRC22:52
*** dklyle has joined #kata-dev23:11
*** dklyle has quit IRC23:19
*** dklyle has joined #kata-dev23:51

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