(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. 2020-08-25T15:21:18+00:00 Paride Legovini paride.legovini@canonical.com 2020-08-25T15:21:18+00:00 urn:sha1:07104504ab5b30efd2d1f7a8c36effe18b8e5fe0 Changes: tox: bump the pylint version to 2.6.0 in the default run Fix pylint 2.6.0 W0707 warnings (raise-missing-from) 2020-07-13T16:00:32+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-07-13T16:00:32+00:00 urn:sha1:3cec3881062490727c5fff1b16b53f0176f976f0 This includes a fix to a test that had a string concatenation issue, and so was only testing a prefix of what was intended. 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. 2019-09-25T20:28:20+00:00 Daniel Watkins oddbloke@ubuntu.com 2019-09-25T20:28:20+00:00 urn:sha1:0cbcd228fb3ec0f22acefa1fc195dbcefa0c149d 2019-07-15T21:50:33+00:00 Sam Gilson t-sagils@microsoft.com 2019-07-15T21:50:33+00:00 urn:sha1:a24550aee4c7282cd3624bf63f9501444e517678 This branch introduces a new command line feature for cloud-init. Currently, the cloud-init module has the capability to analyze events in cloud-init.log in three ways: 'show', 'blame', 'dump'. These changes add a fourth capability, called 'boot'. Running the command 'cloud-init analyze boot' will provide the user three timestamps. 1) Timestamp for when the kernel starts initializing. 2) Timestamp for when the kernel finishes its initialization. 3) Timestamp for when systemd activates cloud-init. This feature enables cloud-init users to analyze different boot phases. This would aid in debugging performance issues related to cloud-init startup or tracking regression. 2017-08-25T23:24:53+00:00 Andrew Jorgensen ajorgens@amazon.com 2017-08-25T22:17:34+00:00 urn:sha1:0ab9859168eb0ba4fc348843e866751cfc67181f Some Python 3 exception names crept into the cloud-init analyze code. This patches those back out at a cost of catching less specific parents of the desired exceptions. 2017-08-21T19:46:23+00:00 Chad Smith chad.smith@canonical.com 2017-08-21T19:46:23+00:00 urn:sha1:e74d7752f1761c3a8d3c19877de4707d00c49d08 This branch adds cloudinit-analyze into cloud-init proper. It adds an "analyze" subcommand to the cloud-init command line utility for quick performance assessment of cloud-init stages and events. On a cloud-init configured instance, running "cloud-init analyze blame" will now report which cloud-init events cost the most wall time. This allows for quick assessment of the most costly stages of cloud-init. This functionality is pulled from Ryan Harper's analyze work. The cloudinit-analyze main script itself has been refactored a bit for inclusion as a subcommand of cloud-init CLI. There will be a followup branch at some point which will optionally instrument detailed strace profiling, but that approach needs a bit more discussion first. This branch also adds: * additional debugging topic to the sphinx-generated docs describing cloud-init analyze, dump and show as well as cloud-init single usage. * Updates the Makefile unittests target to include cloudinit directory because we now have unittests within that package. LP: #1709761