Vivek Goyal

I think problem is with the upgrade. Upgrade should not have overwritten /etc/sysconfig/docker-storage-setup. It should write STORAGE_DRIVER=overlay2 only if this file is not present. @cgwalters Any thoughts on what's going...

Without going into specific details, so how %config(noreplace) equivalent is implemented, in atomic image upgrades. IOW, if a user decided to edit a file in /etc/sysconfig/ which now should not...

Ok, in fedora docker spec, /etc/sysconfig/docker-storage-setup is generated on the fly (only if file is not present already). And it is marked as %ghost file. That is package does not...

container-storage-setup fix is more of a workaround. We should not even be getting to that point if our assumptions w.r.t upgrades are correct. I am trying to understand that why...

Why did storage driver change to begin with over upgrade, that's the real problem which needs fixing. How container-storage-setup copes with the change, is a different issue altogether.

Documentation says following. "Now that we have a deployment directory, a 3-way merge is performed between the (by default) currently booted deployment's /etc, its default configuration, and the new deployment...

How does it matter if /etc/sysconfig/docker-storage-setup was touched by %posttrans. It could have very well be done by cloud-init. I really can't see anything wrong with what's being done in...

I think real issue is that atomic upgrade will not deal with any file being dropped by %posttrans section in /etc. We drop this file to setup default for the...

We had gone towards that path with the option of STORAGE_DRIVER=auto and ran into various issues. Also, that means we will need to carry additional patches to source code to...

@cgwalters looks like exiting early is not enough. It exposes a race where we wait for thin pool to come up and now that wait does not happen and docker...