(mirror of https://github.com/vyos/vyos-cloud-init.git) https://git.amelek.net/vyos/vyos-cloud-init.git/atom?h=rolling 2021-12-16T02:16:38+00:00 2021-12-16T02:16:38+00:00 James Falcon james.falcon@canonical.com 2021-12-16T02:16:38+00:00 urn:sha1:bae9b11da9ed7dd0b16fe5adeaf4774b7cc628cf Applied Black and isort, fixed any linting issues, updated tox.ini and CI. 2021-09-01T14:50:37+00:00 Andrew Bogott Andrewbogott@gmail.com 2021-09-01T14:50:37+00:00 urn:sha1:db72c841c2ec0d94d366df7fa623e82e91e2201c The current code starts the puppet agent and also sets autostart in all cases. This conflicts with a common pattern where puppet itself manages the agent and autostart state. For example, in my deploy puppet disables the puppet agent and replaces it with a cron. This causes various races both within this cloud-init unit and within puppet itself while cloud-init and puppet fight over whether or not to enable the service. 2021-08-10T15:14:23+00:00 Gabriel Nagy gabrielnagy@me.com 2021-08-10T15:14:23+00:00 urn:sha1:9893dfcd2f0be92197d707236cbd44cb7452364d - update the puppet module to support AIO installations by setting `install_type` to `aio` - make the install collection configurable through the `collection` parameter; by default the rolling `puppet` collection will be used, which installs the latest version) - when `install_type` is `aio`, puppetlabs repos will be purged after installation; set `cleanup` to `False` to prevent this - AIO installations are performed by downloading and executing a shell script; the URL for this script can be overridden using the `aio_install_url` parameter - make it possible to run puppet agent after installation/configuration via the `exec` key - by default, puppet agent will run with the `--test` argument; this can be overridden via the `exec_args` key 2020-07-13T15:37:37+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-07-13T15:37:37+00:00 urn:sha1:fecbd81889011e8a75badd18935297f3494fe485 2020-06-08T16:49:12+00:00 Scott Moser smoser@brickies.net 2020-06-08T16:49:12+00:00 urn:sha1:3c551f6ebc12f7729a2755c89b19b9000e27cc88 This was painful, but it finishes a TODO from cloudinit/subp.py. It moves the following from util to subp: ProcessExecutionError subp which target_path I moved subp_blob_in_tempfile into cc_chef, which is its only caller. That saved us from having to deal with it using write_file and temp_utils from subp (which does not import any cloudinit things now). It is arguable that 'target_path' could be moved to a 'path_utils' or something, but in order to use it from subp and also from utils, we had to get it out of utils. 2020-01-31T15:15:31+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-01-31T15:15:31+00:00 urn:sha1:1bb1896ec900622e02c1ffb59db4d3f2df4a964d 2019-10-31T15:01:10+00:00 Matthias Baur m.baur@syseleven.de 2019-10-31T15:01:10+00:00 urn:sha1:d3e71b5e843edf73eb7da511a032d987e314bd69 This change adds two new parameters: * csr_attributes * csr_attributes_path Those parameters allow to configure the content of the csr_attributes.yaml file. See https://puppet.com/docs/puppet/latest/config_file_csr_attributes.html 2019-10-17T14:36:40+00:00 Dominic Schlegel dominic.schlegel@hostpoint.ch 2019-10-17T14:36:40+00:00 urn:sha1:7e699256b319cdf41e747211763e593a6b5f3393 Commit 6797e822959b84c98cf73e02b2a6e3d6ab3fd4fe replaced the LOG.warn calls that linters were warning about; this also replaces calls that linters would not have recognised (as `log` is generally a parameter in these scenarios). LP: #1508442 2018-03-27T01:03:39+00:00 Chad Smith chad.smith@canonical.com 2018-03-27T01:03:39+00:00 urn:sha1:4fe40704bfb998588d6a96b4a2773ddc9bd692ac Replace regressed cc_puppet functionality from a1f678f8. The following content was inadvertently dropped: - chown /var/lib/puppet/ssl as puppet:root. - Automatic creation of /var/lib/puppet/ssl/certs 2018-03-16T19:43:31+00:00 Chad Smith chad.smith@canonical.com 2018-03-16T19:43:31+00:00 urn:sha1:a1f678f8ebc080d4737f32275f42947b84ae025a Support installing and configuring snaps on ubuntu systems. Now, cloud-config files can provide a list or dictionary of snap:assertions which will be allow configuration of snapd on a system via 'snap ack' calls. The snap:commands configuration option supports arbitrary system commands intended to interact with snappy's cli. This allows users to run arbitrary snappy commands to create users, download, install and configure snap packages and snapd. This branch also deprecates old snappy and snap_config modules leaving warnings in documentation and runtime for consumers of these modules. Deprecated snap* modules will be dropped in cloud-init v.18.2 release.