<feed xmlns='http://www.w3.org/2005/Atom'>
<title>vyos-cloud-init.git/tests/unittests/test_datasource, branch crux</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=crux</id>
<link rel='self' href='https://git.amelek.net/vyos/vyos-cloud-init.git/atom?h=crux'/>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/'/>
<updated>2019-01-23T12:22:45+00:00</updated>
<entry>
<title>OVF: simplify expected return values of transport functions.</title>
<updated>2019-01-23T12:22:45+00:00</updated>
<author>
<name>Scott Moser</name>
<email>smoser@ubuntu.com</email>
</author>
<published>2018-12-20T20:52:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=65318379314278e19eb990d58000c5c66b08da24'/>
<id>urn:sha1:65318379314278e19eb990d58000c5c66b08da24</id>
<content type='text'>
Transport functions (transport_iso9660 and transport_vmware_guestinfo)
would return a tuple of 3 values, but only the first was ever used
outside of test.  The other values (device and filename) were just
ignored.

This just simplifies the transport functions to now return content
(in string format) or None indicating that the transport was not found.
</content>
</entry>
<entry>
<title>Vmware: Add support for the com.vmware.guestInfo OVF transport.</title>
<updated>2019-01-23T12:22:33+00:00</updated>
<author>
<name>Scott Moser</name>
<email>smoser@ubuntu.com</email>
</author>
<published>2018-12-20T17:22:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=d7952d075666122f480f0a5820ac01dfbaa7da1a'/>
<id>urn:sha1:d7952d075666122f480f0a5820ac01dfbaa7da1a</id>
<content type='text'>
This adds support for reading OVF information over the
'com.vmware.guestInfo' tranport.  The current implementation requires
vmware-rpctool be installed in the system.

LP: #1807466
</content>
</entry>
<entry>
<title>NoCloud: Allow top level 'network' key in network-config.</title>
<updated>2018-12-03T22:06:47+00:00</updated>
<author>
<name>Scott Moser</name>
<email>smoser@ubuntu.com</email>
</author>
<published>2018-12-03T22:06:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=adbd950af07a4b613a14bd83049915abdd6ca348'/>
<id>urn:sha1:adbd950af07a4b613a14bd83049915abdd6ca348</id>
<content type='text'>
NoCloud's 'network-config' file was originally expected to contain
network configuration without the top level 'network' key.  This was
because the file was named 'network-config' so specifying 'network'
seemed redundant.

However, JuJu is currently providing a top level 'network' config when
it tries to disable networking ({"network": {"config": "disabled"}).
Other users have also been surprised/confused by the fact that
a network config in /etc/cloud/cloud.cfg.d/network.cfg differed from
what was expected in 'network-config'.

LP: #1798117
</content>
</entry>
<entry>
<title>azure: detect vnet migration via netlink media change event</title>
<updated>2018-11-29T21:53:18+00:00</updated>
<author>
<name>Tamilmani Manoharan</name>
<email>tamanoha@microsoft.com</email>
</author>
<published>2018-11-29T21:53:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=bf7917159dbb292c9fcdef82b004e0f5ecb32c16'/>
<id>urn:sha1:bf7917159dbb292c9fcdef82b004e0f5ecb32c16</id>
<content type='text'>
Replace Azure pre-provision polling on IMDS with a blocking call
which watches for netlink link state change messages.  The media
change event happens when a pre-provisioned VM has been activated
and is connected to the users virtual network and cloud-init can
then resume operation to complete image instantiation.
</content>
</entry>
<entry>
<title>azure: _poll_imds only retry on 404. Fail on Timeout</title>
<updated>2018-11-15T22:55:42+00:00</updated>
<author>
<name>Chad Smith</name>
<email>chad.smith@canonical.com</email>
</author>
<published>2018-11-15T22:55:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=8f812a15fde01173c0dd5b7e1a77b61031fd93e4'/>
<id>urn:sha1:8f812a15fde01173c0dd5b7e1a77b61031fd93e4</id>
<content type='text'>
Upon URL timeout, _poll_imds is expected to re-dhcp to get updated
IP configuration. We don't want to indefinitely retry because the
instance likely has invalid IP configuration.

LP: #1803598
</content>
</entry>
<entry>
<title>azure: retry imds polling on requests.Timeout</title>
<updated>2018-11-13T03:14:58+00:00</updated>
<author>
<name>Chad Smith</name>
<email>chad.smith@canonical.com</email>
</author>
<published>2018-11-13T03:14:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=6062595b83e08e0f12e1fe6d8e367d8db9d91ef8'/>
<id>urn:sha1:6062595b83e08e0f12e1fe6d8e367d8db9d91ef8</id>
<content type='text'>
There is an infrequent race when the booting instance can hit the IMDS
service before it is fully available. This results in a
requests.ConnectTimeout being raised.
Azure's retry_callback logic now retries on either 404s or Timeouts.

LP:1800223
</content>
</entry>
<entry>
<title>azure: Accept variation in error msg from mount for ntfs volumes</title>
<updated>2018-11-12T18:43:42+00:00</updated>
<author>
<name>Jason Zions</name>
<email>jasonzio@microsoft.com</email>
</author>
<published>2018-11-12T18:43:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=6f9512049bbb594c3f01ffcd2ab25ae4e016f01e'/>
<id>urn:sha1:6f9512049bbb594c3f01ffcd2ab25ae4e016f01e</id>
<content type='text'>
If Azure detects an ntfs filesystem type during mount attempt, it should
still report the resource device as reformattable. There are slight
differences in error message format on RedHat and SuSE. This patch
simplifies the expected error match to work on both distributions.

LP: #1799338
</content>
</entry>
<entry>
<title>azure: fix regression introduced when persisting ephemeral dhcp lease</title>
<updated>2018-11-12T17:16:09+00:00</updated>
<author>
<name>asakkurr</name>
<email>asakkurr@microsoft.com</email>
</author>
<published>2018-11-12T17:16:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=d910ecd15de642d73a36e935704e54370f93c45b'/>
<id>urn:sha1:d910ecd15de642d73a36e935704e54370f93c45b</id>
<content type='text'>
In commitish 9073951 azure datasource tried to leverage stale DHCP
information obtained from EphemeralDHCPv4 context manager to report
updated provisioning status to the fabric earlier in the boot process.

Unfortunately the stale ephemeral network configuration had already been
torn down in preparation to bring up IMDS network config so the report
attempt failed on timeout.

This branch introduces obtain_lease and clean_network public methods on
EphemeralDHCPv4 to allow for setup and teardown of ephemeral network
configuration without using a context manager. Azure datasource now uses
this to persist ephemeral network configuration across multiple contexts
during provisioning to avoid multiple DHCP roundtrips.
</content>
</entry>
<entry>
<title>tests: ec2 mock missing httpretty user-data and instance-identity routes</title>
<updated>2018-11-08T04:19:09+00:00</updated>
<author>
<name>Chad Smith</name>
<email>chad.smith@canonical.com</email>
</author>
<published>2018-11-08T04:19:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=093f968013f418d591d9e778a57b2f050ac30db3'/>
<id>urn:sha1:093f968013f418d591d9e778a57b2f050ac30db3</id>
<content type='text'>
</content>
</entry>
<entry>
<title>azure: report ready to fabric after reprovision and reduce logging</title>
<updated>2018-10-31T20:19:15+00:00</updated>
<author>
<name>asakkurr</name>
<email>asakkurr@microsoft.com</email>
</author>
<published>2018-10-31T20:19:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-cloud-init.git/commit/?id=907395104bb5850d221924365102cc5ab0eca2f1'/>
<id>urn:sha1:907395104bb5850d221924365102cc5ab0eca2f1</id>
<content type='text'>
When reusing a preprovisioned VM, report ready to Azure fabric as soon as
we get the reprovision data and the goal state so that we are not delayed
by the cloud-init stage switch, saving 2-3 seconds. Also reduce logging
when polling IMDS for reprovision data.

LP: #1799594
</content>
</entry>
</feed>
