(mirror of https://github.com/vyos/vyos-cloud-init.git) https://git.amelek.net/vyos/vyos-cloud-init.git/atom?h=rolling 2021-09-29T23:32:53+00:00 2021-09-29T23:32:53+00:00 James Falcon james.falcon@canonical.com 2021-09-29T23:32:53+00:00 urn:sha1:ba083245537abd5bf5942fbe851e21eb8f245000 Cloud tests have been replaced with integration tests 2020-07-15T14:26:12+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-07-15T14:26:12+00:00 urn:sha1:4fe576516d65feda17ba78e9265a8e494a195e7b * cloudinit: remove global disable of pylint W0107 and fix errors This includes removing a test class which contained no tests but wasn't detected as empty because of an errant pass statement. * .pylintrc: update disable comment to match arguments 2020-06-10T14:39:29+00:00 Joshua Powers josh.powers@canonical.com 2020-06-10T14:39:29+00:00 urn:sha1:f3bd42659efeed4b092ffcdfd5df7f24813f2d3e 2020-06-01T21:20:39+00:00 Joshua Powers josh.powers@canonical.com 2020-06-01T21:20:39+00:00 urn:sha1:4ab3303ec4bb49f029b7821d6dba53a6b02b6dc1 This removes the use of variables named ‘l’, ‘O’, or ‘I’. Generally these are used in list comprehension to read the line of lines. 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-03-18T17:47:33+00:00 Paride Legovini paride.legovini@canonical.com 2020-03-18T17:47:33+00:00 urn:sha1:024bf27b5a3880dac916431296cb871707923562 The 'merged_cfg' key introduced in 71af48d was incorrectly referenced to as 'ci_cfg' in the json validation test for ec2. 2020-03-10T14:22:22+00:00 Chad Smith chad.smith@canonical.com 2020-03-10T14:22:22+00:00 urn:sha1:71af48df3514ca831c90b77dc71ba0a121dec401 Cloud-config userdata provided as jinja templates are now distro, platform and merged cloud config aware. The cloud-init query command will also surface this config data. Now users can selectively render portions of cloud-config based on: * distro name, version, release * python version * merged cloud config values * machine platform * kernel To support template handling of this config, add new top-level keys to /run/cloud-init/instance-data.json. The new 'merged_cfg' key represents merged cloud config from /etc/cloud/cloud.cfg and /etc/cloud/cloud.cfg.d/*. The new 'sys_info' key which captures distro and platform info from cloudinit.util.system_info. Cloud config userdata templates can render conditional content based on these additional environmental checks such as the following simple example: ``` ## template: jinja #cloud-config runcmd: {% if distro == 'opensuse' %} - sh /custom-setup-sles {% elif distro == 'centos' %} - sh /custom-setup-centos {% elif distro == 'debian' %} - sh /custom-setup-debian {% endif %} ``` To see all values: sudo cloud-init query --all Any keys added to the standardized v1 keys are guaranteed to not change or drop on future released of cloud-init. 'v1' keys will be retained for backward-compatibility even if a new standardized 'v2' set of keys are introduced The following standardized v1 keys are added: * distro, distro_release, distro_version, kernel_version, machine, python_version, system_platform, variant LP: #1865969 2018-10-10T21:04:43+00:00 Chad Smith chad.smith@canonical.com 2018-10-10T21:04:43+00:00 urn:sha1:4652b196e04b68d7c335e64766e3a0140157417c LP: #1797231 2018-10-10T19:29:55+00:00 Chad Smith chad.smith@canonical.com 2018-10-10T19:29:55+00:00 urn:sha1:9f88125a25338b70b53a2f5b0af59499f334f261 Make integration test for flexible using regexp in case disk changes. LP: #1797199 2018-10-09T21:46:35+00:00 Chad Smith chad.smith@canonical.com 2018-10-09T21:46:35+00:00 urn:sha1:f0bc02d7e221c9aa5982b267739481420c761ead Add the following instance-data.json standardized keys: * v1._beta_keys: List any v1 keys in beta development, e.g. ['subplatform']. * v1.public_ssh_keys: List of any cloud-provided ssh keys for the instance. * v1.platform: String representing the cloud platform api supporting the datasource. For example: 'ec2' for aws, aliyun and brightbox cloud names. * v1.subplatform: String with more details about the source of the metadata consumed. For example, metadata uri, config drive device path or seed directory. To support the new platform and subplatform standardized instance-data, DataSource and its subclasses grew platform and subplatform attributes. The platform attribute defaults to the lowercase string datasource name at self.dsname. This method is overridden in NoCloud, Ec2 and ConfigDrive datasources. The subplatform attribute calls a _get_subplatform method which will return a string containing a simple slug for subplatform type such as metadata, seed-dir or config-drive followed by a detailed uri, device or directory path where the datasource consumed its configuration. As part of this work, DatasourceEC2 methods _get_data and _crawl_metadata have been refactored for a few reasons: - crawl_metadata is now a read-only operation, persisting no attributes on the datasource instance and returns a dictionary of consumed metadata. - crawl_metadata now closely represents the raw stucture of the ec2 metadata consumed, so that end-users can leverage public ec2 metadata documentation where possible. - crawl_metadata adds a '_metadata_api_version' key to the crawled ds.metadata to advertise what version of EC2's api was consumed by cloud-init. - _get_data now does all the processing of crawl_metadata and saves datasource instance attributes userdata_raw, metadata etc. Additional drive-bys: * unit test rework for test_altcloud and test_azure to simplify mocks and make use of existing util and test_helpers functions.