<feed xmlns='http://www.w3.org/2005/Atom'>
<title>vyos-cloud-init.git/tests/unittests/test_datasource, branch 20.3</title>
<subtitle> (mirror of https://github.com/vyos/vyos-cloud-init.git)
</subtitle>
<id>https://git.amelek.net/vyos/vyos-cloud-init.git/atom?h=20.3</id>
<link rel='self' href='https://git.amelek.net/vyos/vyos-cloud-init.git/atom?h=20.3'/>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/'/>
<updated>2020-08-25T03:48:21+00:00</updated>
<entry>
<title>Azure: Add netplan driver filter when using hv_netvsc driver (#539)</title>
<updated>2020-08-25T03:48:21+00:00</updated>
<author>
<name>James Falcon</name>
<email>TheRealFalcon@users.noreply.github.com</email>
</author>
<published>2020-08-25T03:48:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=4068137e3ef048d3e2da56a8190f682eb19d501e'/>
<id>urn:sha1:4068137e3ef048d3e2da56a8190f682eb19d501e</id>
<content type='text'>
This fixes a long delay during boot of some instances. For Azure instance types using SR-IOV via the Hyper-V netvsc network driver, two network interfaces are created that share the same MAC, but only the virtual device should be configured and used. Updating the netplan configuration to filter on the hv_netvsc driver prevents netplan from trying to figure both devices.

LP: #1830740</content>
</entry>
<entry>
<title>Refactor Azure report ready code (#468)</title>
<updated>2020-08-13T20:50:07+00:00</updated>
<author>
<name>Johnson Shi</name>
<email>Johnson.Shi@microsoft.com</email>
</author>
<published>2020-08-13T20:50:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=c3556ae82dfb47d635344fcd78908f003648d6d2'/>
<id>urn:sha1:c3556ae82dfb47d635344fcd78908f003648d6d2</id>
<content type='text'>
This PR refactors Azure report ready code to include more robust tests and telemetry.</content>
</entry>
<entry>
<title>azure: disable bouncing hostname when setting hostname fails (#494)</title>
<updated>2020-07-22T16:51:01+00:00</updated>
<author>
<name>Anh Vo</name>
<email>anhvo@microsoft.com</email>
</author>
<published>2020-07-22T16:51:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=d600f47e91b904243263358324c413c4f7e5cf50'/>
<id>urn:sha1:d600f47e91b904243263358324c413c4f7e5cf50</id>
<content type='text'>
DataSourceAzure: Gracefully handle the case of set hostname failure during provisioning</content>
</entry>
<entry>
<title>VMware: Support parsing DEFAULT-RUN-POST-CUST-SCRIPT (#441)</title>
<updated>2020-07-21T15:52:29+00:00</updated>
<author>
<name>xiaofengw-vmware</name>
<email>42736879+xiaofengw-vmware@users.noreply.github.com</email>
</author>
<published>2020-07-21T15:52:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=995f8adf00509e5d2aefc9f0680c3c4894ae6666'/>
<id>urn:sha1:995f8adf00509e5d2aefc9f0680c3c4894ae6666</id>
<content type='text'>
Add support for VMware's vCD configuration setting DEFAULT-RUN-POST-CUST-SCRIPT.
When set True, it will default vms to run post customization scripts if the VM has not been configured in VMTools with "enable-custom-scripts" set False.

Add datasource documentation with a bit more context about this interaction on VMware products.

With this fix, the behavior will be:
 * If VM administrator doesn't want others to execute a script on this VM,  VMtools can set "enable-custom-scripts" to false from the utility "vmware-toolbox-cmd".
 * If VM administrator doesn't set value to "enable-custom-scripts", then by default this script is disabled for security purpose.
 * For VMware's vCD product , the preference is to enable the script if "enable-custom-scripts" is not set. vCD will generate a configuration file with "DEFAULT-RUN-POST-CUST-SCRIPT" set to true. This flag works for both VMware customization engine and cloud-init.</content>
</entry>
<entry>
<title>cloudinit: remove global disable of pylint W0107 and fix errors (#489)</title>
<updated>2020-07-15T14:26:12+00:00</updated>
<author>
<name>Daniel Watkins</name>
<email>oddbloke@ubuntu.com</email>
</author>
<published>2020-07-15T14:26:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=4fe576516d65feda17ba78e9265a8e494a195e7b'/>
<id>urn:sha1:4fe576516d65feda17ba78e9265a8e494a195e7b</id>
<content type='text'>
* 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</content>
</entry>
<entry>
<title>cloudinit: remove global disable of pylint W0105 and fix errors (#480)</title>
<updated>2020-07-13T16:00:32+00:00</updated>
<author>
<name>Daniel Watkins</name>
<email>oddbloke@ubuntu.com</email>
</author>
<published>2020-07-13T16:00:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=3cec3881062490727c5fff1b16b53f0176f976f0'/>
<id>urn:sha1:3cec3881062490727c5fff1b16b53f0176f976f0</id>
<content type='text'>
This includes a fix to a test that had a string concatenation issue, and
so was only testing a prefix of what was intended.</content>
</entry>
<entry>
<title>Fix two minor warnings (#475)</title>
<updated>2020-07-13T15:37:37+00:00</updated>
<author>
<name>Daniel Watkins</name>
<email>oddbloke@ubuntu.com</email>
</author>
<published>2020-07-13T15:37:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=fecbd81889011e8a75badd18935297f3494fe485'/>
<id>urn:sha1:fecbd81889011e8a75badd18935297f3494fe485</id>
<content type='text'>
</content>
</entry>
<entry>
<title>tests: use markers to configure disable_subp_usage (#473)</title>
<updated>2020-07-02T17:51:28+00:00</updated>
<author>
<name>Daniel Watkins</name>
<email>oddbloke@ubuntu.com</email>
</author>
<published>2020-07-02T17:51:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=2b727914e8cbee6810b1bb9a1cfdb90ad521ceb6'/>
<id>urn:sha1:2b727914e8cbee6810b1bb9a1cfdb90ad521ceb6</id>
<content type='text'>
This is an improvement over indirect parameterisation for a few reasons:

* The test code is much easier to read, the mark names are much more
  intuitive than the indirect parameterisation invocation, and there's
  less boilerplate to boot
* The fixture no longer has to overload the single parameter that
  fixtures can take with multiple meanings</content>
</entry>
<entry>
<title>networking: refactor is_physical from cloudinit.net (#457)</title>
<updated>2020-06-30T18:19:38+00:00</updated>
<author>
<name>Daniel Watkins</name>
<email>oddbloke@ubuntu.com</email>
</author>
<published>2020-06-30T18:19:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=882f1a5f2d5bafd08e6900a2782c3affa67c9d86'/>
<id>urn:sha1:882f1a5f2d5bafd08e6900a2782c3affa67c9d86</id>
<content type='text'>
As the first refactor PR, this also includes the initial structure for tests.

LP: #1884619</content>
</entry>
<entry>
<title>Hetzner: support reading user-data that is base64 encoded. (#448)</title>
<updated>2020-06-22T18:44:37+00:00</updated>
<author>
<name>Scott Moser</name>
<email>smoser@brickies.net</email>
</author>
<published>2020-06-22T18:44:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=76652f3e07b6f659b2fd166a6619cb427dc6bc7e'/>
<id>urn:sha1:76652f3e07b6f659b2fd166a6619cb427dc6bc7e</id>
<content type='text'>
Hetzner cloud only supports user-data as a string (presumably utf-8).

In order to allow users on Hetzner to provide binary data to cloud-init,
we will attempt to base64decode the userdata.

The change here adds a 'maybe_b64decode' function that will decode data
if and only if is base64 encoded.

The reason for not using util.b64d is that we do not want the return value
decoded to a string, and util.b64d will do that if it can.  Additionally
we call decode with validate=True which oddly is not the default.

LP: #1884071</content>
</entry>
</feed>
