On 12/13/2016 02:18 PM, Dusty Mabe wrote: > > On 12/13/2016 01:02 PM, Colin Walters wrote: >> 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) >> > So if we were to propose the "overlayfs as default" change for all of > Fedora, would you consider that to be problematic considering your > "you shouldn't use overlayfs for persistent data," stance. In the case > of a user running pet containers on their local desktop environment, > what is the sentiment? > > Dusty > _______________________________________________ > cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx Yes I might hesitate to run PET Containers in Overlay. I hope to get to the point where you can run different container workloads on different backends. It might be better to run a PET Container on OSTree using runc and not going through the client server operation of docker. _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
