(mirror of https://github.com/vyos/vyos-cloud-init.git) https://git.amelek.net/vyos/vyos-cloud-init.git/atom?h=rolling 2022-01-19T03:46:14+00:00 2022-01-19T03:46:14+00:00 Chad Smith chad.smith@canonical.com 2022-01-19T03:46:14+00:00 urn:sha1:20bd192db661e519b860a0799de04c663ceae0c6 snapd currrently looks for 'not run' from cloud-init status[1]. Avoid changing this behavior and revert "not-run" value to "not run". This avoids having to get snapd to change implementation and release updates as far back as Bionic to handle a hyphenated not-run string. [1]: https://github.com/snapcore/snapd/blob/master/sysconfig/\ cloudinit.go#L802 2022-01-13T17:12:23+00:00 Chad Smith chad.smith@canonical.com 2022-01-13T17:12:23+00:00 urn:sha1:0de7acb194dc15650eee1d5332efed82ef162f84 This fix has two elements: - cloud-init status will not correctly report 'not-run' prior to systemd generator running. Only report "disabled" when generator has run and /run/cloud-init/disabled exists. - Expose not-run and disabled state in cloud-id responses - Add unique error codes from cloud-id for error, disabled and not-run. The new cloud-id exit codes: 0: success 1: error 2: cloud-init is in disabled state 3: cloud-init generator has not run yet 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. 2018-02-09T03:57:23+00:00 Chad Smith chad.smith@canonical.com 2018-02-09T03:57:23+00:00 urn:sha1:86d2fc7f515f70a5117f00baf701a0bed6310b3e Fix various corner cases for cloud-init status subcommand. Report 'runnning' under the following conditions: - No /run/cloud-init/result.json file exists - Any stage in status.json is unfinished - status.json reports a non-null stage it is in progress on LP: #1747965 2018-01-26T20:36:30+00:00 Chad Smith chad.smith@canonical.com 2018-01-26T20:36:30+00:00 urn:sha1:1d8c327139a8c291eeb244ee1a6a8badd83e9e72 While addressing undeclared variable in 'cloud-init status', I also fixed the errors raised by automated code reviews against cloud-init master at https://lgtm.com/projects/g/cloud-init/cloud-init/alerts The following items are addressed:  * Fix 'cloud-init status':     * Only report 'running' state when any stage in /run/cloud-init/status.json has a start time but no finished time. Default start time to 0 if null.     * undeclared variable 'reason' now reports 'Cloud-init enabled by systemd cloud-init-generator' when systemd enables cloud-init  * cc_rh_subscription.py util.subp return values aren't set during if an exception is raised, use ProcessExecution as e instead.  * distros/freebsd.py:    * Drop repetitive looping over ipv4 and ipv6 nic lists.    * Initialize bsddev to 'NOTFOUND' in the event that no devs are discovered    * declare nics_with_addresses = set() in broader scope outside check_downable conditional  * cloudinit/util.py: Raise TypeError if mtype parameter isn't string, iterable or None. LP: #1744796 2017-12-05T23:25:11+00:00 Chad Smith chad.smith@canonical.com 2017-12-05T23:25:11+00:00 urn:sha1:30b4d15764a1a9644379cf95770e8b2480856882 The 'cloud-init clean' command allows a user or script to clear cloud-init artifacts from the system so that cloud-init sees the system as unconfigured upon reboot. Optional parameters can be provided to remove cloud-init logs and reboot after clean. The 'cloud-init status' command allows the user or script to check whether cloud-init has finished all configuration stages and whether errors occurred. An optional --wait argument will poll on a 0.25 second interval until cloud-init configuration is complete. The benefit here is scripts can block on cloud-init completion before performing post-config tasks.