opencontainers
cmd: expose overlayfs extraction support
Most of the support code already exists (especially once we merge #572) but there are some questions of how the API should work for this kind of extraction. For one thing, the current rootfs + mtree model doesn't really work so we would need to rework a lot of that logic as well as come up with a nice way for runc run to "just work" with an auto-setup overlayfs mount...
One of the things we would need to to do is store what directories each layer is extracted into and so on, but I just figured out that 9ab5eff081e262c268f3e419a7c19b55ab987661 actually added the WhiteoutMode to the umoci.json metadata -- however, the support is nowhere near complete and it looks like a mistake to me.
@tych0 You don't have to review #572 yet (though I would like your input in general since you wrote a lot of the overlayfs support and given the issues I found I am curious how much you use it in practice) but I wanted to ask about 9ab5eff081e262c268f3e419a7c19b55ab987661 (the commit that added WhiteoutMode to the umoci.json metadata). Probably should've ask this back when I reviewed it but better late than never...
As far as I can tell, this is a mistake because you cannot practically use Repack on a bundle with the overlayfs mode at the moment. Yeah, you'll get some result but if you wanted to use the overlayfs stuff you would want to extract to multiple layer directories (which umoci.Unpack doesn't support) and then you would want to only use the top layer (which the metadata doesn't contain enough information for). Using mtree diffs is not correct in general and would at best result in very confusing behaviour. I would be happy to add full support for this (though I had originally planned for this to be implemented via hooks, I now see that isn't practical) but it will have to wait until after 0.5 (I think @stgraber will kill me if it takes any longer for me to do the 0.5 release).
Unfortunately, because this was added to umoci.json we would probably need to either create a new format version (and because the current format has been in use since 2017 we would also need to add migration code, etc) -- or if we accept this is broken we can revert 9ab5eff081e262c268f3e419a7c19b55ab987661 for now (and make sure we never use that field name in v2) and work on full support in 0.6 (which will probably need a new version as well but we can also get feature flags with #575).
I'm asking because I would really like to unify the TranslateOverlayfsWhiteouts and WhiteoutMode because really the two are both two sides of the same coin and if we want to support adding a config options to support userxattr (as I originally wanted to in #572) then we will end up having shared configurations that should probably be represented with the same config type. But combining them while keeping the current umoci.json stuff is not really going to be pretty.
A question I've been mulling around is whether we should have umoci mount to mount the overlayfs, or just generate a generic mount.sh script for admins to use, or just leave it up to users?
It would be unfortunate for us to create a bundle where the rootfs is missing or has no data because the user didn't know they have to mount the overlayfs themselves...