On Tue, Dec 13, 2016, at 12:45 PM, Clayton Coleman wrote: > Are the POSIX issues in applications running on overlay mostly > resolved now? I.e. if we flipped the default would be reasonably able > to support a diverse range of Linux workloads without the risk that > previously existed?
overlayfs will never be fully POSIX compatible, but I think that's OK, because remember - you shouldn't use overlayfs for persistent data, or really anything that's not code/config files (and we want to get to where that's overlayfs-type semantics for builds, and read-only for deployment). Data should be in Kube persistent volumes etc. I think the thing to focus on is tools that are run during builds - the yum-in-overlayfs bug is a good example, because the RPM database *is* a database which is the type of workload that's going to be sensitive to the overlayfs semantics. How many of those are there? Probably not many, I suspect most of the compat issues with userspace have been shaken out by now. (But long term we may end up in a situation where people who want to run e.g. rhel5's yum in a container need to somehow fall back to devmapper)