-
Notifications
You must be signed in to change notification settings - Fork 908
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ubuntu/jammy 23.4 #4663
Ubuntu/jammy 23.4 #4663
Conversation
…nical#4604) Drop the limit for connection errors if a route to IMDS is detected. Since we know we've brought up the primary NIC and connectivity should work, continue to retry until retry_deadline is up. If there is no route to IMDS detected, such as Azure Stack, keep the current limit of 11. Fetching reprovision data behavior is unchanged. Signed-off-by: Chris Patterson <cpatterson@microsoft.com>
This is normal behavior, don't warn. Signed-off-by: Chris Patterson <cpatterson@microsoft.com>
As part of 29ed5f5, we also need to revert the integration test changes
After reprovisioning, IMDS should return None value for PPS data type. Introduce a check to verify it IMDS is returning stale-PPS data. In case of stale data, report the error to the host and allow the VM to continue with provisioning. This is part of a larger effort to improve error handling and error reporting during VM provisioning.
Some snap tests were missing the top-level "snap" key. Because additional properties are allowed at the top-level, this is passing when it shouldn't.
Add mising schema definitions that are viable cloud-config.
Some misc test changes and docs move to ensure restricting top-level properties in the cloud-config schema doesn't fail
New top-level properties key is necessary to restrict additional top-level keys. Simpler schemes won't work because our documentation inspects the module defintions in the schema.
) Do not perform schema validation on merged system config as it contains base config from /tec/cloud/cloud.cfg* which is not strictly honored as cloud-config user-data. Only perform schema validation on the processed user-data provided to the instance. This avoids schema errors for base config keys such as datasource_list, def_log_file, _logs present in /etc/cloud/cloud.cfg*.
Previously users that didn't have the python jsonschema dependency installed would "succeed" to validate a user configuration. Fix it.
The version has been the same for 3 releases now, so use it as a default. It is used by test_versioned_packages_are_installed test.
These two tests won't be fixed anytime soon, so there's no reason to continue the jenkins noise.
Previously two subcommands used different format than the rest of them. Unify behavior and code.
Add a test for this behavior.
…ical#4617) Assertions about the host's kernel in a container are useless anyways.
A deprecate log was called before logging was set up.
) EphemeralIPv{4,6} failure is not always an error, therefore do not log this event as an error in the context manager. Allow call sites to determine log level. Fixes canonical#4540
…han the new mode (canonical#4250)" This reverts commit a0e4ec1. This commit introduced a broken `compare_permissions()` function. With this implementation, a log file with a mode of 0o407 would remain readable to other users on the system. If the unit tests included in this commit expected the correct output values, the tests would have caught this error.
Previous implementations loosened permissions in non-default scenarios. Fixes canonicalGH-4243
When non-root user calls cloud-init schema to validate cfg files, they will get a permissions error on /var/lib/cloud/instance dir trying to source the cached datasource. Fallback to default read_cfg_paths in this case and log debug level msg about this case. Since cloud-init schema CLI is used in the context of validating config files and not really searching for cfg path overrides, using default paths to find instance-data.json isn't critical or even a warning condition. Additionally avoid print() and use LOG.warning when no datasource currently detected as this should indicate that scripts or user may be trying to read instance-data.json which does not exist yet. Fixes canonicalGH-4620
It's magic that makes it hard to follow call hierachies without saving much code.
- Add Python netifaces dependency - Double quote to prevent globbing and word splitting - Add CodeBleu as a contributor
Since adding the top-level properties key to the schema, the fuzz test will only generate empty tests. Update the test to remove/ignore the top-level keys along with ensuring fuzzed additionalProperties are removed from the test.
…4635) Only write /var/lib/cloud/instance/network-config.json once datasource is detected. The /var/lib/clound/instance symlink is created by Init.instancify after datasource detection is complete. Move creation of /var/lib/cloud/instance/network-config.json into a separate method _write_network_config_json. It will be called by any call to apply_network_config. apply_network_config is called in both Local and Network stages. In Local stage, apply_network_config is used to either: - render the final network config of datasource detected in Local - in absence of Local datasource, render basic fallback DHCP on primary NIC to allow network to come up before detecting a Network datasource For Network datasources, they will not have been discovered or instancify'd in Local boot stage, so apply_network_config cannot yet persist network-config.json. Defer creation of network-config.json for Network datasources until the link /var/lib/cloud/instance exists and apply_network_config is called in Network stage to render final network config. Fixes canonicalGH-4630
Restart time after reboot is slower than 30 seconds on some platforms. Give the DatasourceNone detection a total of 90 seconds.
…al#4635) Earlier iterations of this test exposed failure cases where DataSourceNone and cloud-init status --wait would block indefinitely in some failure modes. The primary failure mode was DataSourceNone config on LXD containers due to invalid network config on virtual NICs due to LP:#2022947 and newer netplan resulting in tracebacks preventing init local and network boot stages from persisting completion status to /run/cloud-init/status.json. This is resolved already within the test by copying working network config prior to DataSourceNone detection on lxd_containers. The test can now rely on client.restart default blocking and retries to avoid expiring all retries on platforms with slower reboots.
Bump the version in cloudinit/version.py to 23.4 and update ChangeLog.
This patch was inadvertently dropped in 5d4a3cf.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few changelog issues, but otherwise looks good
debian/changelog
Outdated
* d/p/status-do-not-remove-duplicated-data.patch: | ||
- Revert behavior downstream, leave duplicate data | ||
* d/control: Add python3-passlib as needed for testing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This along with the Akamai and po/templates lines were in 23.3.1 so should be dropped here
debian/changelog
Outdated
@@ -1,24 +1,54 @@ | |||
cloud-init (23.3-0ubuntu0~22.04.1) UNRELEASED; urgency=medium | |||
cloud-init (23.4-0ubuntu0~22.04.1) jammy; urgency=medium |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as lunar about version number
Force-push to fix the version and d/changelog. |
do not squash
retain-old-groups.patch
c1f6916 brings back the patch
retain-old-groups.patch
, which was inadvertently dropped as part of #4530 .Steps to reproduce
Tests