(mirror of https://github.com/marekm72/vyos-cloud-init.git) https://git.amelek.net/marekm72/vyos-cloud-init.git/atom?h=20.3 2020-06-30T17:17:40+00:00 2020-06-30T17:17:40+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-06-30T17:17:40+00:00 urn:sha1:66e114a660c53400e389f119781f378311b65108 caplog is only available in pytest itself from 3.0 onwards. In xenial, we only have pytest 2.8.7. However, in xenial we do have pytest-catchlog available (as python3-pytest-catchlog), so we use that where appropriate. 2020-06-22T14:30:05+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-06-22T14:30:05+00:00 urn:sha1:0755cff078d5931e1d8e151bdcb84afb92bc0f02 If the instance symlink doesn't exist, then we shouldn't create a directory in its place, because that breaks future boots. LP: #1883903 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-06-01T21:55:40+00:00 Matthew Ruffell github@ruffell.nz 2020-06-01T21:55:40+00:00 urn:sha1:fc07d633f7cb694423349a2c4b10c91c4b4981a2 Replace the hardcoded list of devices with a more robust way of determining the device which grub is installed to. We use grub-probe to fetch the underlying disk the /boot directory is located on, and attempt to match the disk with its /dev/disk/by-id value. If no such /dev/disk/by-id/ value exists, we fallback to the plain disk name. The changes are robust to unstable kernel device names and ordering, and use /dev/disk/by-id values to populate grub-pc/install_devices where possible. LP: #1877491 2020-05-21T15:16:35+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-05-21T15:16:35+00:00 urn:sha1:98a6d9a0da82a764943c9495d7f21f3acc5ccd05 And add an example of providing a list of assertions. 2020-05-20T02:52:18+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-05-20T02:52:18+00:00 urn:sha1:fae90f14f0668a673e02bc7313bc84828e7cae71 2020-05-18T17:30:27+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-05-18T17:30:27+00:00 urn:sha1:8bcf1c069d8ddf28898342e541254bdeb54445df Specifically, ensure that given values are either strings, or arrays of strings. 2020-05-14T19:39:19+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-05-14T19:39:19+00:00 urn:sha1:09492b1d0f4b1826a7a98709c61d48bf14a1ec64 We recently discovered that pylint is failing to report some errors when invoked across our entire codebase (see https://github.com/PyCQA/pylint/issues/3611). I've run pylint across every Python file under cloudinit/[0], and this commit fixes the issues so-discovered. [0] find cloudinit/ -name "*.py" | xargs -n 1 -t .tox/pylint/bin/python -m pylint 2020-04-24T13:26:51+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-04-24T13:26:51+00:00 urn:sha1:38a7e6e9756fdab31264c0d6e93d20432ed111ac These libraries provide backports of Python 3's stdlib components to Python 2. As we only support Python 3, we can simply use the stdlib now. This pull request does the following: * removes some unneeded compatibility code for the old spelling of `assertRaisesRegex` * replaces invocations of the Python 2-only `assertItemsEqual` with its new name, `assertCountEqual` * replaces all usage of `unittest2` with `unittest` * replaces all usage of `contextlib2` with `contextlib` * drops `unittest2` and `contextlib2` from requirements files and tox.ini It also rewrites some `test_azure` helpers to use bare asserts. We were seeing a strange error in xenial builds of this branch which appear to be stemming from the AssertionError that pytest produces being _different_ from the standard AssertionError. This means that the modified helpers weren't behaving correctly, because they weren't catching AssertionErrors as one would expect. (I believe this is related, in some way, to https://github.com/pytest-dev/pytest/issues/645, but the only version of pytest where we're affected is so far in the past that it's not worth pursuing it any further as we have a workaround.) 2020-04-16T15:18:36+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-04-16T15:18:36+00:00 urn:sha1:0c5c736727d0f8e363678fe970d70bb889e3893c