walters reported a new issue against the project: `atomic-wg` that you are following: `` Incremental step for https://pagure.io/atomic-wg/issue/360 ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/384
The issue: `Consider not starting docker.service by default` of project: `atomic-wg` has been assigned to `walters` by walters.
dustymabe added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/384
walters added a new comment to an issue you are following: `` 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`? ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/384
walters added a new comment to an issue you are following: `` @vgoyal ↑ ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/384
dustymabe added a new comment to an issue you are following: ``
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?
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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/384
vgoyal added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/384
atomic@lists.fedoraproject.org
-
Colin Walters -
Dusty Mabe
-
Vivek Goyal