(mirror of https://github.com/vyos/vyos-cloud-init.git) https://git.amelek.net/vyos/vyos-cloud-init.git/atom?h=circinus-public-unmaintained 2021-12-16T02:16:38+00:00 2021-12-16T02:16:38+00:00 James Falcon james.falcon@canonical.com 2021-12-16T02:16:38+00:00 urn:sha1:bae9b11da9ed7dd0b16fe5adeaf4774b7cc628cf Applied Black and isort, fixed any linting issues, updated tox.ini and CI. 2021-07-19T19:13:21+00:00 James Falcon therealfalcon@gmail.com 2021-07-19T19:13:21+00:00 urn:sha1:184c836a16e9954a2cba11ae21f07923077ec904 Adds a udev script which will invoke a hotplug hook script on all net add events. The script will write some udev arguments to a systemd FIFO socket (to ensure we have only instance of cloud-init running at a time), which is then read by a new service that calls a new 'cloud-init devel hotplug-hook' command to handle the new event. This hotplug-hook command will: - Fetch the pickled datsource - Verify that the hotplug event is supported/enabled - Update the metadata for the datasource - Ensure the hotplugged device exists within the datasource - Apply the config change on the datasource metadata - Bring up the new interface (or apply global network configuration) - Save the updated metadata back to the pickle cache Also scattered in some unrelated typing where helpful 2021-05-13T17:55:41+00:00 James Falcon TheRealFalcon@users.noreply.github.com 2021-05-13T17:55:41+00:00 urn:sha1:864346999702e6b2b8bf7e6244a6608bcead72a5 Control is currently limited to boot events, though this should allow us to more easily incorporate HOTPLUG support. Disabling 'instance-first-boot' is not supported as we apply networking config too early in boot to have processed userdata (along with the fact that this would be a pretty big foot-gun). The concept of update events on datasource has been split into supported update events and default update events. Defaults will be used if there is no user-defined update events, but user-defined events won't be supplied if they aren't supported. When applying the networking config, we now check to see if the event is supported by the datasource as well as if it is enabled. Configuration looks like: updates: network: when: ['boot'] 2021-03-08T20:09:47+00:00 James Falcon TheRealFalcon@users.noreply.github.com 2021-03-08T20:09:47+00:00 urn:sha1:9bd19645a61586b82e86db6f518dd05c3363b17f #342 (70dbccbb) introduced the ability to determine route-metrics based on the `device-number` provided by the EC2 IMDS. Not all datasources that subclass EC2 will have this attribute, so allow the old behavior if `device-number` is not present. LP: #1917875 2020-11-02T20:41:11+00:00 Scott Moser smoser@brickies.net 2020-11-02T20:41:11+00:00 urn:sha1:0af1ff1eaf593c325b4f53181a572110eb016c50 This just separates the reading of dmi values into its own file. Some things of note: * left import of util in dmi.py only for 'is_container' It'd be good if is_container was not in util. * just the use of 'util.is_x86' to dmi.py * open() is used directly rather than load_file. 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-05-01T20:56:56+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-05-01T20:56:56+00:00 urn:sha1:70dbccbbb27f7cc3f2decd692d41403f0d745c62 We want to set route-metrics such that NICs are configured with the priority that they are given in the network metadata that we receive from the IMDS. (This switches away from using MAC ordering.) This also required the following test changes: * reverse the sort order of the MACs in test data (so that they would trigger the bug being fixed) * fix up the key names in `NIC2_MD` (which were under_scored instead of dash-separated) * use a full interface dict (rather than a minimal one) for `TestConvertEc2MetadataNetworkConfig` LP: #1876312 2020-03-18T19:33:37+00:00 Chad Smith chad.smith@canonical.com 2020-03-18T19:33:37+00:00 urn:sha1:6600c642af3817fe5e0170cb7b4eeac4be3c60eb Add support for rendering secondary static IPv4/IPv6 addresses on any NIC attached to the machine. In order to see secondary IP addresses in Ec2 IMDS network config, cloud-init now reads metadata version 2018-09-24. Metadata services which do not support the Ec2 API version will not get secondary IP addresses configured. In order to discover secondary IP address config, cloud-init now relies on metadata API Parse local-ipv4s, ipv6s, subnet-ipv4-cidr-block and subnet-ipv6-cidr-block metadata keys to determine additional IPs and appropriate subnet prefix to set for a nic. Also add the datasource config option apply_full_imds_netork_config which defaults to true to allow cloud-init to automatically configure secondary IP addresses. Setting this option to false will tell cloud-init to avoid setting up secondary IP addresses. Also in this branch: - Shift Ec2 datasource to emit network config v2 instead of v1. LP: #1866930 2020-03-06T00:38:28+00:00 Chad Smith chad.smith@canonical.com 2020-03-06T00:38:28+00:00 urn:sha1:1f860e5ac7ebb5b809c72d8703a0b7cb3e84ccd0 The EC2 Data Source needs to handle 3 states of the Instance Metadata Service configured for a given instance: 1. HttpTokens : optional & HttpEndpoint : enabled Either IMDSv2 or IMDSv1 can be used. 2. HttpTokens : required & HttpEndpoint : enabled Calls to IMDS without a valid token (IMDSv1 or IMDSv2 with expired token) will return a 401 error. 3. HttpEndpoint : disabled The IMDS http endpoint will return a 403 error. Previous work to support IMDSv2 in cloud-init handled case 1 and case 2. This commit handles case 3 by bypassing the retry block when IMDS returns HTTP status code >= 400 on official AWS cloud platform. It shaves 2 minutes when rebooting an instance that has its IMDS http token endpoint disabled but creates some inconsistencies. An instance that doesn't set "manual_cache_clean" to "True" will have its /var/lib/cloud/instance symlink removed altogether after it has failed to find a datasource. 2020-02-19T21:01:09+00:00 Ryan Harper ryan.harper@canonical.com 2020-02-19T21:01:09+00:00 urn:sha1:87cd040ed8fe7195cbb357ed3bbf53cd2a81436c Instead of logging the token values used log the headers and replace the actual values with the string 'REDACTED'. This allows users to examine cloud-init.log and see that the IMDSv2 token header is being used but avoids leaving the value used in the log file itself. LP: #1863943