(mirror of https://github.com/vyos/vyos-cloud-init.git) https://git.amelek.net/vyos/vyos-cloud-init.git/atom?h=20.1 2017-07-19T21:52:32+00:00 2017-07-19T21:52:32+00:00 Ryan Harper ryan.harper@canonical.com 2017-06-13T14:06:41+00:00 urn:sha1:dcbe479575fac9f293c5c4089f4bcb46ab887206 Under el7, cloud-init systemd files need some unit tweaks to ensure they run at the right time. Pull in current el7 downstream systemd unit changes. 2016-11-15T22:20:41+00:00 Scott Moser smoser@brickies.net 2016-11-15T22:14:00+00:00 urn:sha1:9d826b8855797bd37e477b6da43153c49529afe8 While cloud-init writes its data to /var/lib/cloud, we previously lazily added RequiresMountsFor=/var/lib . It is more correct to list the more complete path. LP: #1642062 2016-11-15T19:40:56+00:00 Scott Moser smoser@brickies.net 2016-11-15T19:40:56+00:00 urn:sha1:d0e293e4d4a2d6b41c5e6e2ee312bb1aae6031a9 sysinit.target happens earlier in boot than basic.target. cloud-init-local.service had: Before=basic.target but cloud-init.service had: After=cloud-init-local.service Before=sysinit.target The result was that cloud-init-local.service was indirectly Before sysinit.target anyway, so this change is just to more specifically state that. 2016-11-10T22:09:29+00:00 Scott Moser smoser@brickies.net 2016-11-10T15:49:17+00:00 urn:sha1:bf4010a9c379e2109b030af558033014f9137f47 Drop mention of local-fs.target from both cloud-init-local.service and cloud-init.service. This could actually could cause a loop in ordering due to cc_mounts writing mount points with: x-systemd.requires=cloud-init.service Rather, we specifically list /var/lib/ and systemd-remount-fs.service in cloud-init-local.service. cloud-init.service will run after cloud-init-local and thus will have these satisfied. 2016-09-21T21:03:17+00:00 Joshua Harlow jxharlow@godaddy.com 2016-09-20T21:13:25+00:00 urn:sha1:1b71b474c0fc06e67aab8676268fd83d99091910 2016-09-20T17:42:29+00:00 Scott Moser smoser@brickies.net 2016-09-19T15:48:54+00:00 urn:sha1:80f5ec4be0f781b26eca51d90d51abfab396b3f6 The end result of all of these changes is to get mounts managed by cloud-init to occur only after cloud-init.service is done. We need to do that so that filesystems that are set up by cloud-init (in disk_setup) do not get mounted by stale entries in /etc/fstab before the setup occurs. This can occur in 2 ways: a.) new instance with old /etc/fstab b.) same instance where disk needs adjusting (Azure resize will re-format the ephemeral disk). The list of changes here is: - move mounts and disk_setup module to cloud-init.service rather than config. cloud-init.service runs earlier in boot so it can get those mount points done earlier. - on systemd add 'x-systemd.requires=cloud-init.service' to fstab options - cloud-init-local.service: add Before=basic.target - cloud-init.service: - extend After, Before, and Wants to multiple lines rather than one long line. - sort consistently with cloud-init-local.service - add DefaultDependencies=no - add Before=default.target - add Conflicts=shutdown.target LP: #1611074 2016-03-21T12:59:55+00:00 Scott Moser smoser@ubuntu.com 2016-03-21T12:59:55+00:00 urn:sha1:7a22e352b2f87636554d9787f60cd3168f3d77bc 2016-03-21T02:31:21+00:00 Scott Moser smoser@ubuntu.com 2016-03-21T02:31:21+00:00 urn:sha1:16751f75a51814e4873199eddec15040dd221561 2016-03-19T00:47:06+00:00 Scott Moser smoser@ubuntu.com 2016-03-19T00:47:06+00:00 urn:sha1:1c8e0d93bb48338777e689e6303702bf84fed0d1 this might work. And if it does means we could generally test this as the file that the cloud-init-wait will wait for will actually get created. 2016-03-10T15:32:08+00:00 Scott Moser smoser@ubuntu.com 2016-03-10T15:32:08+00:00 urn:sha1:2eb86ca13cb658b51440bb28cab47205b641d0ee This should mean that cloud-init-local is running earlier now (DefaultDependencies=no). And also blocking networking coming up (Before=network-pre.target) cloud-init.service should now actually block network-online.target from being made (meaning it will run before anything that expects that) but after networking.service, which is what actually does the bringup on ifupdown / ubuntu.