On Thu, Oct 27, 2016 at 5:59 AM, Martin Pitt <martin.p...@ubuntu.com> wrote:
> So did I understand this right: > > * In current xenial, cloud-init runs in late boot, so there is no > principal ordering problem between cloud-init and networkd, other than > that cloud-init.service should declare After=systemd-networkd.service > similar to what it does for ifupdown (After=networking.service). > > * Thus this would not be a blocker for Ubuntu Core 16 right now, and > merely adding that After= should suffice for the moment. > > * This *is* an issue for 16.10/zesty as cloud-init.service runs in > early boot and dbus/networkd can't. > I suppose we could cherry pick the upstream snap create-user feature and other fixes but I expect the SRU of cloud-init to Xenial to include the change in ordering to enable running cloud-init earlier in boot; without resolved in 16.04 though the change isn't strictly needed but to keep the backported branch closer to trunk, I would expect those to come in. However, it does sound like it's reasonable to just add the After=systemd-networkd.service as you say; I can test this out now and confirm if that's sufficient to get a picture of what this should look like. > > * This *will become* an issue for 16.04 as these cloud-init changes are > meant to be backported soon. Will that happen for the Ubuntu Core 16 GA > in a few days already? I. e. is this something which we need to crowbar > in ASAP, or do we have some time to figure out a proper solution how to > start networkd first, and dbus later on? > The official Ubuntu Core 16 GA images won't have cloud-init enabled by default. I'm currently working on a separate build of UC16 *with* cloud-init enabled, focusing on primary public cloud support. In this build, I'll include at least snapshot of cloud-init trunk as of a few days ago to include the snap create-user support needed for function. I can add a task against cloud-init for this bug and get a MR with the change to the cloud-init.service file after testing that the changes achieves the goal. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1636912 > > Title: > systemd-networkd runs too late for cloud-init.service (net) > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/cloud-init/+ > bug/1636912/+subscriptions > -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1636912 Title: systemd-networkd runs too late for cloud-init.service (net) Status in systemd: Unknown Status in cloud-init package in Ubuntu: Triaged Status in systemd package in Ubuntu: Triaged Status in cloud-init source package in Xenial: New Status in systemd source package in Xenial: Triaged Bug description: Ubuntu Core 16 images using cloud-init fail to function when the DataSource is over the network (Like OpenStack) as networking is not yet available when cloud-init.service runs. cloud-init service unit deps look like this: [Unit] Description=Initial cloud-init job (metadata service crawler) DefaultDependencies=no Wants=cloud-init-local.service Wants=local-fs.target Wants=sshd-keygen.service Wants=sshd.service After=cloud-init-local.service After=networking.service Requires=networking.service Before=basic.target Before=dbus.socket Before=network-online.target Before=sshd-keygen.service Before=sshd.service Before=systemd-user-sessions.service Conflicts=shutdown.target Here's networkd unit deps: [Unit] Description=Network Service Documentation=man:systemd-networkd.service(8) ConditionCapability=CAP_NET_ADMIN DefaultDependencies=no # dbus.service can be dropped once on kdbus, and systemd-udevd.service can be # dropped once tuntap is moved to netlink After=systemd-udevd.service dbus.service network-pre.target systemd-sysusers.service systemd-sysctl.service Before=network.target multi-user.target shutdown.target Conflicts=shutdown.target Wants=network.target # On kdbus systems we pull in the busname explicitly, because it # carries policy that allows the daemon to acquire its name. Wants=org.freedesktop.network1.busname After=org.freedesktop.network1.busname And a critical-chain output: root@snap-test7:~# systemd-analyze critical-chain systemd-networkd Failed to get ID: Unit name systemd-networkd is not valid. The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. root@snap-test7:~# systemd-analyze critical-chain systemd-networkd.service The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. systemd-networkd.service +440ms └─dbus.service @11.461s └─basic.target @11.403s └─sockets.target @11.401s └─dbus.socket @11.398s └─cloud-init.service @10.127s +1.266s └─networking.service @9.305s +799ms └─network-pre.target @9.295s └─cloud-init-local.service @3.822s +5.469s └─local-fs.target @3.813s └─run-cgmanager-fs.mount @12.687s └─local-fs-pre.target @1.393s └─systemd-tmpfiles-setup-dev.service @1.116s +195ms └─kmod-static-nodes.service @887ms +193ms └─system.slice @783ms └─-.slice @721ms cloud-init would need networkd to run at or before 'networking.service' so it can raise networking to then find and use network-based datasources. # grep systemd /usr/share/snappy/dpkg.list ii libnss-resolve:amd64 229-4ubuntu11 amd64 nss module to resolve names via systemd-resolved ii libpam-systemd:amd64 229-4ubuntu11 amd64 system and service manager - PAM module ii libsystemd0:amd64 229-4ubuntu11 amd64 systemd utility library ii systemd 229-4ubuntu11 amd64 system and service manager ii systemd-sysv 229-4ubuntu11 amd64 system and service manager - SysV links # grep cloud-init /usr/share/snappy/dpkg.list ii cloud-init 0.7.8-201610260005-gf7a5756-0ubuntu1~trunk~ubuntu16.04.1 all Init scripts for cloud instances To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1636912/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
