(mirror of https://github.com/marekm72/vyos-cloud-init.git) https://git.amelek.net/marekm72/vyos-cloud-init.git/atom?h=20.4 2020-08-25T15:21:18+00:00 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-09T15:21:34+00:00 Paride Legovini paride.legovini@canonical.com 2020-07-09T15:21:34+00:00 urn:sha1:e753141fc7844e68b1f380d26fb3d250eb464ff7 Update lxd_export method to detect and handle different image formats cloud_tests will only support the "split" type images which exports a compressed (xz) tarball of metadata and a rootfs (of different formats). For non-split image formats (single tarball with metadata + rootfs) we now raise an exception indicating that the requested image is not supported at this time. 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-10-11T16:52:13+00:00 Ryan Harper ryan.harper@canonical.com 2019-10-11T16:52:13+00:00 urn:sha1:823708ea031290c864e3aef67f60f6eb495f281d LXD integration tests fail sometimes due to failure to delete the container, usually related to ZFS backend. This is a transient issue unrelated to the test itself. Teach LXD platform to retry this a few times before returning an error. 2018-07-27T16:04:08+00:00 Scott Moser smoser@ubuntu.com 2018-07-27T16:04:08+00:00 urn:sha1:361ae34d3fd2f5784ddac23c6650ac5a8f2e14cd Described in bug 1783198 we have seen some transient failures when using pylxd -> lxd api. This does: * adds a str() representation of LXDInstance * checks the value of the pylxd_container object on instantion * sets pylxd_container object to None on deletion. * adds retry logic to shutdown() 2018-05-17T15:57:37+00:00 Ryan Harper ryan.harper@canonical.com 2018-05-17T15:57:37+00:00 urn:sha1:2dab7046f88e540836498b363c90ad46302a7cc4 pylint missed finding a typo in the lxd platform because it could not determine that the variable was being used was a string. The variable was set by loading a yaml file which pylint couldn't know that it would be a string. In these cases, we can be more explicit. 2018-04-20T03:30:08+00:00 Scott Moser smoser@ubuntu.com 2018-04-20T03:30:08+00:00 urn:sha1:1081962eacf2814fea6f4fa3255c530de14e4a24 This enables warnings produced by pylint for unused variables (W0612), and fixes the existing errors. 2018-04-03T22:52:13+00:00 Chad Smith chad.smith@canonical.com 2018-04-03T22:52:13+00:00 urn:sha1:05926e48eae0fa70a26da6449617e04e87c4e704 Integration tests previously had a logic path that was unexercised on jenkins because we were on an older version of lxc. With an upgrade to lxd version 3.0 we need to bump pylxd dependency pin and fix a typo in integration tests which checked the lxd version. 2018-03-15T15:45:12+00:00 Scott Moser smoser@ubuntu.com 2018-03-15T15:45:12+00:00 urn:sha1:bef2f2c945fdee4a1141c3177b3e48b1537027e4 When running 'tox -e pylint' on a bionic system (python 3.6.4) I started seeing errors today like: tests/cloud_tests/platforms/__init__.py:5: [E0401(import-error), ] Unable to import 'tests.cloud_tests.platforms.ec2' The fix for those first errors was simply to create the __init__.py. The second set of changes fixes fallout found from actually now having pylint properly run on more of the cloud_tests. 2018-02-12T15:53:49+00:00 Scott Moser smoser@ubuntu.com 2018-01-26T21:00:10+00:00 urn:sha1:f576b2a24b8014e91087933d19a7a0d396787c30 This puts in place detection for if 'show-log' will work with lxc client, and uses that if present. The 'lxc console --show-log' is not expected to work until lxd/liblxc3.0. That should come in a few months. The hope is that when that function arrives, this code will move over to using it. For other scenarios (all current lxd installs) this will now support getting logs from a snap installed lxd or a package installed lxd via the old 'lxc.console.logfile'. If installed from snap, a platform error will be raised until the user does: sudo mkdir --mode=1777 -p /var/snap/lxd/common/consoles LP: #1745663