Incremental step for https://pagure.io/atomic-wg/issue/360
Metadata Update from @walters: - Issue assigned to walters
It could be an incremental step for #360 if we decided to remove docker from the baked image eventually. I think this has merits on it's own without considering #360, though.
The biggest reason I see to do this is for cloud images and having container storage setup run when people actually wanted to change the defaults. You either have to run some cloud-init bootcmd: to change the container-storage-setup.conf file or you have to tear down the storage after the fact and then re-run container-storage-setup. Since our setup now defaults to overlay2 I don't see it as that big of a deal to just have docker socket activated and then the user doesn't even have to systemctl start docker. Only downside I see is that the root partition won't get growpart on boot. So if you don't use docker then you would have to manually do that yourself.
bootcmd:
growpart
Oh man yes you're right, the "no growpart on boot" would be a huge regression here. Which actually gets us into a big mess...maybe we could split out lvm-rootfs-growpart from container-storage-setup?
lvm-rootfs-growpart
container-storage-setup
@vgoyal ↑
There are several ways to handle this. cloud-init has growpart functionality (which I think we disable) and so does docker container-storage-setup. We could disable the docker-storage-setup growpart and enable the cloud-init one (and then the user can disable that one if he/she pleases).
Multiple ways to do it, let's find the way that makes the most sense and is straightforward for the user.
I agree that "growpart" functionality should be outside container-storage-setup. It does not belong there. I have been asking for that for a very long time now.
Login to comment on this ticket.