#384 Consider not starting docker.service by default
Opened 6 years ago by walters. Modified 6 years ago


Metadata Update from @walters:
- Issue assigned to walters

6 years ago

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.

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?

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.

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.

Metadata