(mirror of https://github.com/vyos/vyos-cloud-init.git) https://git.amelek.net/vyos/vyos-cloud-init.git/atom?h=rolling 2017-06-08T16:59:48+00:00 2017-06-08T16:59:48+00:00 Scott Moser smoser@ubuntu.com 2016-09-28T20:20:55+00:00 urn:sha1:41d46bfb85929c79dabcec3cf21c8d71401fd2b8 Here we move the config/cloud.cfg to be rendered as a template. That allows us to maintain deltas between distros in one place. Currently we use 'variant' variable to make decisions. A tools/render-cloudcfg is provided to render the file. There were changes to setup.py, MANIFEST.in to allow us to put all files into a virtual env installation and to render the cloud-config file in 'install' or 'bdist' targets. We have also included some config changes that were found in the redhat distro spec. * include some config changes from the redhat distro spec. The rendered cloud.cfg has some differences. Ubuntu: white space and comment changes only. Freebsd: - whitespace changes and comment changes - datasource_list definition moved to be closer to 'datasource'. - enable modules: migrator, write_files - move package-update-upgrade-install to final. The initial work was done by Josh Harlow. 2016-10-20T19:40:36+00:00 Ryan Harper ryan.harper@canonical.com 2016-09-01T20:49:20+00:00 urn:sha1:d8534561ba76db25b6fc0044eb1bfda63686e859 Ubuntu Core images use the `snap create-user` to add users to an Ubuntu Core system. Add support for creating snap users by adding a key to the users dictionary. users: - name: bob snapuser: bob@bobcom.io Or via the 'snappy' dictionary: snappy: email: bob@bobcom.io Users may also create a snap user without contacting the SSO by providing a 'system-user' assertion by importing them into snapd. Additionally, Ubuntu Core systems have a read-only /etc/passwd such that the normal useradd/groupadd commands do not function without an additional flag, '--extrausers', which redirects the pwd to /var/lib/extrausers. Move the system_is_snappy() check from cc_snappy module to util for re-use and then update the Distro class to append '--extrausers' if the system is Ubuntu Core. 2016-09-28T16:07:26+00:00 Scott Moser smoser@brickies.net 2016-09-28T16:07:26+00:00 urn:sha1:6d1edc3f5a18b328bdd307426056539d5b9071fd since ntp module may try to install packages, it needs to run after apt is configured. LP: #1628337 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-09-09T19:58:30+00:00 Scott Moser smoser@brickies.net 2016-09-08T17:17:37+00:00 urn:sha1:34a26f7f59f2963691e36ca0476bec9fc9ccef63 In systemd, package installation before the system is fully booted (systemctl is-system-running == starting) may result in the package not being started. Upgrade (package_upgrade: true) can also cause failure if that is done during systemd boot. The solution here is: a.) move config modules that do or may do package installation to 'final_modules'. That list is: - snappy - package-update-upgrade-install - fan - landscape - lxd - puppet - chef - salt-minion - mcollective b.) move cloud-final.service to run as 'Type=idle' LP: #1576692, #1621336 2016-08-22T20:20:10+00:00 Scott Moser smoser@brickies.net 2016-08-18T16:25:29+00:00 urn:sha1:64522efe710faf6fa1615dbb60a2fc4cc8a7c278 This adds some function to the generator to maintain the presense of a flag file '/run/cloud-init/enabled' indicating that cloud-init is enabled. Then, only run the dhclient hooks if on Azure and cloud-init is enabled. The test for is_azure currently only checks to see that the board vendor is Microsoft, not actually that we are on azure. Running should not be harmful anywhere, other than slowing down dhclient. The value of this additional code is that then dhclient having run does not task the system with the load of cloud-init. Additionally, some changes to config are done here. * rename 'dhclient_leases' to 'dhclient_lease_file' * move that to the datasource config (datasource/Azure/dhclient_lease_file) Also, it removes the config in config/cloud.cfg that set agent_command to __builtin__. This means that by default cloud-init still needs the agent installed. The suggested follow-on improvement is to use __builtin__ if there is no walinux-agent installed. 2016-08-15T14:16:19+00:00 Brent Baude bbaude@redhat.com 2016-08-10T22:36:49+00:00 urn:sha1:648dbbf6b090c81e989f1ab70bf99f4de16a6a70 It is more efficient and cross-distribution safe to use the hooks function from dhclient to obtain the Azure endpoint server (DHCP option 245). This is done by providing shell scritps that are called by the hooks infrastructure of both dhclient and NetworkManager. The hooks then invoke 'cloud-init dhclient-hook' that maintains json data with the dhclient options in /run/cloud-init/dhclient.hooks/<interface>.json . The azure helper then pulls the value from /run/cloud-init/dhclient.hooks/<interface>.json file(s). If that file does not exist or the value is not present, it will then fall back to the original method of scraping the dhcp client lease file. 2016-08-10T20:56:14+00:00 Ryan Harper ryan.harper@canonical.com 2016-08-10T20:49:30+00:00 urn:sha1:b455902450e3f9ccb0cb876b460bdc7d5f6e24db Add support for installing and configuring ntp service, exposing the minimum config of servers or pools to be added. If none are defined then fallback on generating a list of pools by distro hosted at pool.ntp.org (which matches what's found in the default ntp.conf shipped in the respective distro). 2016-03-09T22:34:11+00:00 Robert Jennings robert.jennings@canonical.com 2016-03-09T22:34:11+00:00 urn:sha1:075fdbfcc567de07fcf54566872d812c8573efb9 LP: #1539317 2016-02-04T04:21:40+00:00 Wesley Wiedenmeier wesley.wiedenmeier@gmail.com 2016-02-04T04:21:40+00:00 urn:sha1:ee40614b0a34a110265493c176c64db823aa34b3 If lxd key is present in cfg, then run 'lxd init' with values from the 'init' entry in lxd configuration as flags.