On 10/23/2016 06:55 PM, Dusty Mabe wrote:
On 10/21/2016 04:02 PM, Colin Walters wrote:
> On Fri, Oct 21, 2016, at 03:42 PM, Jason Brooks wrote:
>>> Oct 21 18:40:37 localhost.localdomain systemd:
docker-storage-setup.service: Job docker-storage-setup.service/start deleted to break
ordering cycle starting with multi-user.target/start
> I think this was the error Dusty was pointing out. The systemd one is harmless.
> I think this is due to:
> # grep After /usr/lib/systemd/system/docker-storage-setup.service
> # grep ^After /usr/lib/systemd/system/cloud-final.service
> After=network-online.target cloud-config.service rc-local.service multi-user.target
> But docker.service wants docker-storage-setup.service, and
> multi-user.target wants docker.service.
> Hence we're trying to run d-s-s both before and after multi-user.target.
> I think the fix here is going to be changing the After=cloud-final.service
> in d-s-s to After=cloud-init-local.service or so.
> The main requirement here from my perspective is that cloud node
> users are able to configure d-s-s (and docker). Specifically to do
> things like enable overlayfs by default.
> If changing it to cloud-init-local.service is sufficient to use `bootcmd`,
> that may work.
I opened a bug for this: https://bugzilla.redhat.com/show_bug.cgi?id=1387934
Can we document this bug for test day and also try to get a workaround
documented so that people can still test things?
Here is a user-data workaround that can be used to put in walters' suggested fix and
then get the docker service up and running:
- sed s/After=cloud-final.service/After=cloud-init-local.service/
- systemctl daemon-reload
- systemctl start --no-block docker.service