Activity log for bug #2040291

Date Who What changed Old value New value Message
2023-10-24 15:34:42 Chad Smith bug added bug
2023-10-24 15:34:49 Chad Smith cloud-init (Ubuntu): importance Undecided High
2023-10-24 15:34:52 Chad Smith cloud-init (Ubuntu): status New Triaged
2023-10-24 15:35:54 Chad Smith description === Begin SRU Template === [Impact] In cloud-init 23.3.1, when cloud-config directives specify that ansible is istalled via `install_method: pip` cloud-init cloud-init leave ansible uninstalled/configured due to a traceback from pip because cloud-init incorrectly provides the unsupported pip parameter `--break-system-packages` on Focal and Jammy. This issue was already addressed in upstream commit [1] by only providing the `--break-system-packages` parameter to pip in environments/distributions that have configured python with the marker file EXTERNALLY_MANAGED. [1] upstream fix https://github.com/canonical/cloud-init/commit/13938f749f7393eaa47a9d5ddd286e675ff2944d [Test Case] * Run current integration tests are expected to fail path against daily images CLOUD_INIT_OS_IMAGE=jammy tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip * Run current integration tests with this proposed SRU upload from ppa:cloud-init-dev/proposed which will succeed CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=ppa:cloud-init-dev/proposed tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip [Regression Potential] This is resolving a bug that broke/regressed for environment which pip-install ansible using specific cloud-config. It is a very specific fix for a targeted use-case and will not regress typical deployments using cloud-init [Other info] -Original comment filed against upstream PR indicating this problem https://github.com/canonical/cloud-init/commit/b417b21816827f0b1324cf0df633487c43b15dad#commitcomment-130714494 === Begin SRU Template === [Impact] In cloud-init 23.3.1, when cloud-config directives specify that ansible is installed via `install_method: pip` cloud-init leaves ansible uninstalled/configured due to a traceback from pip because cloud-init incorrectly provides the unsupported pip parameter `--break-system-packages` on Focal and Jammy. This issue was already addressed in upstream commit [1] by only providing the `--break-system-packages` parameter to pip in environments/distributions that have configured python with the marker file EXTERNALLY_MANAGED. [1] upstream fix https://github.com/canonical/cloud-init/commit/13938f749f7393eaa47a9d5ddd286e675ff2944d [Test Case] * Run current integration tests are expected to fail path against daily images CLOUD_INIT_OS_IMAGE=jammy tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip * Run current integration tests with this proposed SRU upload from ppa:cloud-init-dev/proposed which will succeed CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=ppa:cloud-init-dev/proposed tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip [Regression Potential] This is resolving a bug that broke/regressed for environment which pip-install ansible using specific cloud-config. It is a very specific fix for a targeted use-case and will not regress typical deployments using cloud-init [Other info] -Original comment filed against upstream PR indicating this problem https://github.com/canonical/cloud-init/commit/b417b21816827f0b1324cf0df633487c43b15dad#commitcomment-130714494
2023-10-24 15:37:12 Chad Smith description === Begin SRU Template === [Impact] In cloud-init 23.3.1, when cloud-config directives specify that ansible is installed via `install_method: pip` cloud-init leaves ansible uninstalled/configured due to a traceback from pip because cloud-init incorrectly provides the unsupported pip parameter `--break-system-packages` on Focal and Jammy. This issue was already addressed in upstream commit [1] by only providing the `--break-system-packages` parameter to pip in environments/distributions that have configured python with the marker file EXTERNALLY_MANAGED. [1] upstream fix https://github.com/canonical/cloud-init/commit/13938f749f7393eaa47a9d5ddd286e675ff2944d [Test Case] * Run current integration tests are expected to fail path against daily images CLOUD_INIT_OS_IMAGE=jammy tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip * Run current integration tests with this proposed SRU upload from ppa:cloud-init-dev/proposed which will succeed CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=ppa:cloud-init-dev/proposed tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip [Regression Potential] This is resolving a bug that broke/regressed for environment which pip-install ansible using specific cloud-config. It is a very specific fix for a targeted use-case and will not regress typical deployments using cloud-init [Other info] -Original comment filed against upstream PR indicating this problem https://github.com/canonical/cloud-init/commit/b417b21816827f0b1324cf0df633487c43b15dad#commitcomment-130714494 === Begin SRU Template === [Impact] In cloud-init 23.3.1, when cloud-config directives specify that ansible is installed via `install_method: pip` cloud-init leaves ansible uninstalled/configured due to a traceback from pip because cloud-init incorrectly provides the unsupported pip parameter `--break-system-packages` on Focal and Jammy. This issue was already addressed in upstream commit [1] by only providing the `--break-system-packages` parameter to pip in environments/distributions that have configured python with the marker file EXTERNALLY_MANAGED. [1] upstream fix https://github.com/canonical/cloud-init/commit/13938f749f7393eaa47a9d5ddd286e675ff2944d [Test Case] * Run current integration tests are expected to fail path against daily images CLOUD_INIT_OS_IMAGE=jammy tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip * Run current integration tests with this proposed SRU upload from ppa:cloud-init-dev/proposed which will succeed CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=ppa:cloud-init-dev/proposed tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip [Regression Potential] This is resolving a bug that broke/regressed only environments which specifically launch vms use user-datwa specifying ansible: install_method: pip ... It is a very specific fix for a targeted use-case and will not regress typical deployments using cloud-init [Other info] -Original comment filed against upstream PR indicating this problem https://github.com/canonical/cloud-init/commit/b417b21816827f0b1324cf0df633487c43b15dad#commitcomment-130714494
2023-10-24 15:38:18 Chad Smith description === Begin SRU Template === [Impact] In cloud-init 23.3.1, when cloud-config directives specify that ansible is installed via `install_method: pip` cloud-init leaves ansible uninstalled/configured due to a traceback from pip because cloud-init incorrectly provides the unsupported pip parameter `--break-system-packages` on Focal and Jammy. This issue was already addressed in upstream commit [1] by only providing the `--break-system-packages` parameter to pip in environments/distributions that have configured python with the marker file EXTERNALLY_MANAGED. [1] upstream fix https://github.com/canonical/cloud-init/commit/13938f749f7393eaa47a9d5ddd286e675ff2944d [Test Case] * Run current integration tests are expected to fail path against daily images CLOUD_INIT_OS_IMAGE=jammy tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip * Run current integration tests with this proposed SRU upload from ppa:cloud-init-dev/proposed which will succeed CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=ppa:cloud-init-dev/proposed tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip [Regression Potential] This is resolving a bug that broke/regressed only environments which specifically launch vms use user-datwa specifying ansible: install_method: pip ... It is a very specific fix for a targeted use-case and will not regress typical deployments using cloud-init [Other info] -Original comment filed against upstream PR indicating this problem https://github.com/canonical/cloud-init/commit/b417b21816827f0b1324cf0df633487c43b15dad#commitcomment-130714494 === Begin SRU Template === [Impact] In cloud-init 23.3.1, when cloud-config directives specify that ansible is installed via `install_method: pip` cloud-init leaves ansible uninstalled/configured due to a traceback from pip because cloud-init incorrectly provides the unsupported pip parameter `--break-system-packages` on Focal and Jammy. This issue was already addressed in upstream commit [1] by only providing the `--break-system-packages` parameter to pip in environments/distributions that have configured python with the marker file EXTERNALLY_MANAGED. [1] upstream fix https://github.com/canonical/cloud-init/commit/13938f749f7393eaa47a9d5ddd286e675ff2944d [Test Case] * Run current integration tests are expected to fail path against daily images CLOUD_INIT_OS_IMAGE=jammy tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip * Run current integration tests with this proposed SRU upload from ppa:cloud-init-dev/proposed which will succeed CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=ppa:cloud-init-dev/proposed tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip [Regression Potential] This is resolving a bug that broke/regressed only environments with have pip version < 23.0.1 and provide the following custom user-data during VM launch: ansible:   install_method: pip    ... It is a very specific fix for a targeted use-case and will not regress typical deployments using cloud-init [Other info] -Original comment filed against upstream PR indicating this problem https://github.com/canonical/cloud-init/commit/b417b21816827f0b1324cf0df633487c43b15dad#commitcomment-130714494
2023-10-24 15:40:23 Chad Smith description === Begin SRU Template === [Impact] In cloud-init 23.3.1, when cloud-config directives specify that ansible is installed via `install_method: pip` cloud-init leaves ansible uninstalled/configured due to a traceback from pip because cloud-init incorrectly provides the unsupported pip parameter `--break-system-packages` on Focal and Jammy. This issue was already addressed in upstream commit [1] by only providing the `--break-system-packages` parameter to pip in environments/distributions that have configured python with the marker file EXTERNALLY_MANAGED. [1] upstream fix https://github.com/canonical/cloud-init/commit/13938f749f7393eaa47a9d5ddd286e675ff2944d [Test Case] * Run current integration tests are expected to fail path against daily images CLOUD_INIT_OS_IMAGE=jammy tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip * Run current integration tests with this proposed SRU upload from ppa:cloud-init-dev/proposed which will succeed CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=ppa:cloud-init-dev/proposed tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip [Regression Potential] This is resolving a bug that broke/regressed only environments with have pip version < 23.0.1 and provide the following custom user-data during VM launch: ansible:   install_method: pip    ... It is a very specific fix for a targeted use-case and will not regress typical deployments using cloud-init [Other info] -Original comment filed against upstream PR indicating this problem https://github.com/canonical/cloud-init/commit/b417b21816827f0b1324cf0df633487c43b15dad#commitcomment-130714494 === Begin SRU Template === [Impact] In cloud-init 23.3.1, when cloud-config directives specify that ansible is installed via `install_method: pip` cloud-init leaves ansible uninstalled/configured due to a traceback from pip because cloud-init incorrectly provides the unsupported pip parameter `--break-system-packages` on Focal and Jammy. This issue was already addressed in upstream commit [1] by only providing the `--break-system-packages` parameter to pip in environments/distributions that have configured python with the marker file EXTERNALLY_MANAGED. [1] upstream fix https://github.com/canonical/cloud-init/commit/13938f749f7393eaa47a9d5ddd286e675ff2944d [Test Case] * Run current integration tests are expected to fail path against daily images CLOUD_INIT_OS_IMAGE=jammy tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip * Run current integration tests with this proposed SRU upload from ppa:cloud-init-dev/proposed which will succeed CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=ppa:cloud-init-dev/proposed tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip [Regression Potential] This is resolving a bug that broke/regressed only environments with have pip version < 23.0.1 and provide the following custom user-data during VM launch: ansible:   install_method: pip    ... It is a very specific fix for a targeted use-case and will not regress typical deployments using cloud-init [Other info] - Community comment filed against upstream PR indicating this problem https://github.com/canonical/cloud-init/commit/b417b21816827f0b1324cf0df633487c43b15dad#commitcomment-130714494 - Original issue filed against integration test failures https://github.com/canonical/cloud-init/issues/4244
2023-10-24 15:40:57 Chad Smith description === Begin SRU Template === [Impact] In cloud-init 23.3.1, when cloud-config directives specify that ansible is installed via `install_method: pip` cloud-init leaves ansible uninstalled/configured due to a traceback from pip because cloud-init incorrectly provides the unsupported pip parameter `--break-system-packages` on Focal and Jammy. This issue was already addressed in upstream commit [1] by only providing the `--break-system-packages` parameter to pip in environments/distributions that have configured python with the marker file EXTERNALLY_MANAGED. [1] upstream fix https://github.com/canonical/cloud-init/commit/13938f749f7393eaa47a9d5ddd286e675ff2944d [Test Case] * Run current integration tests are expected to fail path against daily images CLOUD_INIT_OS_IMAGE=jammy tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip * Run current integration tests with this proposed SRU upload from ppa:cloud-init-dev/proposed which will succeed CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=ppa:cloud-init-dev/proposed tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip [Regression Potential] This is resolving a bug that broke/regressed only environments with have pip version < 23.0.1 and provide the following custom user-data during VM launch: ansible:   install_method: pip    ... It is a very specific fix for a targeted use-case and will not regress typical deployments using cloud-init [Other info] - Community comment filed against upstream PR indicating this problem https://github.com/canonical/cloud-init/commit/b417b21816827f0b1324cf0df633487c43b15dad#commitcomment-130714494 - Original issue filed against integration test failures https://github.com/canonical/cloud-init/issues/4244 [Impact] In cloud-init 23.3.1, when cloud-config directives specify that ansible is installed via `install_method: pip` cloud-init leaves ansible uninstalled/configured due to a traceback from pip because cloud-init incorrectly provides the unsupported pip parameter `--break-system-packages` on Focal and Jammy. This issue was already addressed in upstream commit [1] by only providing the `--break-system-packages` parameter to pip in environments/distributions that have configured python with the marker file EXTERNALLY_MANAGED. [1] upstream fix https://github.com/canonical/cloud-init/commit/13938f749f7393eaa47a9d5ddd286e675ff2944d [Test Case] * Run current integration tests are expected to fail path against daily images CLOUD_INIT_OS_IMAGE=jammy tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip * Run current integration tests with this proposed SRU upload from ppa:cloud-init-dev/proposed which will succeed CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=ppa:cloud-init-dev/proposed tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip [Regression Potential] This is resolving a bug that broke/regressed only environments with have pip version < 23.0.1 and provide the following custom user-data during VM launch: ansible:   install_method: pip    ... It is a very specific fix for a targeted use-case and will not regress typical deployments using cloud-init [Other info] - Community comment filed against upstream PR indicating this problem https://github.com/canonical/cloud-init/commit/b417b21816827f0b1324cf0df633487c43b15dad#commitcomment-130714494 - Original issue filed against integration test failures https://github.com/canonical/cloud-init/issues/4244
2023-10-24 15:46:38 Chad Smith description [Impact] In cloud-init 23.3.1, when cloud-config directives specify that ansible is installed via `install_method: pip` cloud-init leaves ansible uninstalled/configured due to a traceback from pip because cloud-init incorrectly provides the unsupported pip parameter `--break-system-packages` on Focal and Jammy. This issue was already addressed in upstream commit [1] by only providing the `--break-system-packages` parameter to pip in environments/distributions that have configured python with the marker file EXTERNALLY_MANAGED. [1] upstream fix https://github.com/canonical/cloud-init/commit/13938f749f7393eaa47a9d5ddd286e675ff2944d [Test Case] * Run current integration tests are expected to fail path against daily images CLOUD_INIT_OS_IMAGE=jammy tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip * Run current integration tests with this proposed SRU upload from ppa:cloud-init-dev/proposed which will succeed CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=ppa:cloud-init-dev/proposed tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip [Regression Potential] This is resolving a bug that broke/regressed only environments with have pip version < 23.0.1 and provide the following custom user-data during VM launch: ansible:   install_method: pip    ... It is a very specific fix for a targeted use-case and will not regress typical deployments using cloud-init [Other info] - Community comment filed against upstream PR indicating this problem https://github.com/canonical/cloud-init/commit/b417b21816827f0b1324cf0df633487c43b15dad#commitcomment-130714494 - Original issue filed against integration test failures https://github.com/canonical/cloud-init/issues/4244 [Impact] In cloud-init 23.3.1, when cloud-config directives specify that ansible is installed via `install_method: pip` cloud-init leaves ansible uninstalled/configured due to a traceback from pip because cloud-init incorrectly provides the unsupported pip parameter `--break-system-packages` on Focal and Jammy. This issue was already addressed in upstream commit [1] by only providing the `--break-system-packages` parameter to pip in environments/distributions that have configured python with the marker file EXTERNALLY_MANAGED. [1] upstream fix https://github.com/canonical/cloud-init/commit/13938f749f7393eaa47a9d5ddd286e675ff2944d [Test Case] for RELEASE in focal jammy lunar mantic; do if [ "$RELEASE" = "focal" -o "$RELEASE" = "jammy"]; then echo "Expect integration test FAILURE on $RELEASE with daily images" # Run current integration tests are expected to fail path against daily images CLOUD_INIT_OS_IMAGE=jammy tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip else echo "Expect integration test SUCCESS on $RELEASE with daily images" # Run current integration tests are expected to fail path against daily images CLOUD_INIT_OS_IMAGE=jammy tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip fi echo "Expect integration test SUCCESS on $RELEASE with SRU version cloud-init 23.3.3" # Run current integration tests with this proposed SRU upload from ppa:cloud-init-dev/proposed which will succeed CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=ppa:cloud-init-dev/proposed tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip [Regression Potential] This is resolving a bug that broke/regressed only environments with have pip version < 23.0.1 and provide the following custom user-data during VM launch: ansible:   install_method: pip    ... It is a very specific fix for a targeted use-case and will not regress typical deployments using cloud-init [Other info] - Community comment filed against upstream PR indicating this problem https://github.com/canonical/cloud-init/commit/b417b21816827f0b1324cf0df633487c43b15dad#commitcomment-130714494 - Original issue filed against integration test failures https://github.com/canonical/cloud-init/issues/4244
2023-10-24 16:20:06 Chad Smith nominated for series Ubuntu Lunar
2023-10-24 16:20:06 Chad Smith bug task added cloud-init (Ubuntu Lunar)
2023-10-24 16:20:06 Chad Smith nominated for series Ubuntu Focal
2023-10-24 16:20:06 Chad Smith bug task added cloud-init (Ubuntu Focal)
2023-10-24 16:20:06 Chad Smith nominated for series Ubuntu Jammy
2023-10-24 16:20:06 Chad Smith bug task added cloud-init (Ubuntu Jammy)
2023-10-24 16:20:06 Chad Smith nominated for series Ubuntu Mantic
2023-10-24 16:20:06 Chad Smith bug task added cloud-init (Ubuntu Mantic)
2023-10-24 16:26:46 Chad Smith cloud-init (Ubuntu): status Triaged Fix Committed
2023-10-24 16:26:52 Chad Smith cloud-init (Ubuntu Focal): status New In Progress
2023-10-24 16:26:55 Chad Smith cloud-init (Ubuntu Jammy): status New In Progress
2023-10-24 16:26:58 Chad Smith cloud-init (Ubuntu Lunar): status New In Progress
2023-10-24 16:27:01 Chad Smith cloud-init (Ubuntu Mantic): status New Fix Committed
2023-10-24 16:27:04 Chad Smith cloud-init (Ubuntu Focal): status In Progress Fix Committed
2023-10-24 16:27:06 Chad Smith cloud-init (Ubuntu Jammy): status In Progress Fix Committed
2023-10-24 16:27:08 Chad Smith cloud-init (Ubuntu Lunar): status In Progress Fix Committed
2023-10-24 21:44:28 Ubuntu Archive Robot bug added subscriber James Falcon
2023-11-14 20:13:57 Chad Smith cloud-init (Ubuntu): status Fix Committed Fix Released
2023-11-16 20:02:58 Andreas Hasenack bug added subscriber Ubuntu Stable Release Updates Team
2023-11-16 20:03:23 Andreas Hasenack bug added subscriber SRU Verification
2023-11-16 20:03:28 Andreas Hasenack tags verification-needed verification-needed-mantic
2023-11-16 20:04:39 Andreas Hasenack tags verification-needed verification-needed-mantic verification-needed verification-needed-lunar verification-needed-mantic
2023-11-16 20:07:19 Andreas Hasenack tags verification-needed verification-needed-lunar verification-needed-mantic verification-needed verification-needed-jammy verification-needed-lunar verification-needed-mantic
2023-11-16 20:08:10 Andreas Hasenack tags verification-needed verification-needed-jammy verification-needed-lunar verification-needed-mantic verification-needed verification-needed-focal verification-needed-jammy verification-needed-lunar verification-needed-mantic
2023-11-17 20:41:40 James Falcon description [Impact] In cloud-init 23.3.1, when cloud-config directives specify that ansible is installed via `install_method: pip` cloud-init leaves ansible uninstalled/configured due to a traceback from pip because cloud-init incorrectly provides the unsupported pip parameter `--break-system-packages` on Focal and Jammy. This issue was already addressed in upstream commit [1] by only providing the `--break-system-packages` parameter to pip in environments/distributions that have configured python with the marker file EXTERNALLY_MANAGED. [1] upstream fix https://github.com/canonical/cloud-init/commit/13938f749f7393eaa47a9d5ddd286e675ff2944d [Test Case] for RELEASE in focal jammy lunar mantic; do if [ "$RELEASE" = "focal" -o "$RELEASE" = "jammy"]; then echo "Expect integration test FAILURE on $RELEASE with daily images" # Run current integration tests are expected to fail path against daily images CLOUD_INIT_OS_IMAGE=jammy tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip else echo "Expect integration test SUCCESS on $RELEASE with daily images" # Run current integration tests are expected to fail path against daily images CLOUD_INIT_OS_IMAGE=jammy tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip fi echo "Expect integration test SUCCESS on $RELEASE with SRU version cloud-init 23.3.3" # Run current integration tests with this proposed SRU upload from ppa:cloud-init-dev/proposed which will succeed CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=ppa:cloud-init-dev/proposed tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip [Regression Potential] This is resolving a bug that broke/regressed only environments with have pip version < 23.0.1 and provide the following custom user-data during VM launch: ansible:   install_method: pip    ... It is a very specific fix for a targeted use-case and will not regress typical deployments using cloud-init [Other info] - Community comment filed against upstream PR indicating this problem https://github.com/canonical/cloud-init/commit/b417b21816827f0b1324cf0df633487c43b15dad#commitcomment-130714494 - Original issue filed against integration test failures https://github.com/canonical/cloud-init/issues/4244 [Impact] In cloud-init 23.3.1, when cloud-config directives specify that ansible is installed via `install_method: pip` cloud-init leaves ansible uninstalled/configured due to a traceback from pip because cloud-init incorrectly provides the unsupported pip parameter `--break-system-packages` on Focal and Jammy. This issue was already addressed in upstream commit [1] by only providing the `--break-system-packages` parameter to pip in environments/distributions that have configured python with the marker file EXTERNALLY_MANAGED. [1] upstream fix https://github.com/canonical/cloud-init/commit/13938f749f7393eaa47a9d5ddd286e675ff2944d [Test Case] Use the following script: #!/bin/bash for RELEASE in focal jammy lunar mantic; do if [ "$RELEASE" = "focal" -o "$RELEASE" = "jammy" ]; then echo "Expect integration test FAILURE on $RELEASE with daily images" # Run current integration tests are expected to fail path against daily images CLOUD_INIT_CLOUD_INIT_SOURCE=NONE CLOUD_INIT_OS_IMAGE=$RELEASE tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip else echo "Expect integration test SUCCESS on $RELEASE with daily images" # Run current integration tests are expected to fail path against daily images CLOUD_INIT_CLOUD_INIT_SOURCE=NONE CLOUD_INIT_OS_IMAGE=$RELEASE tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip fi echo "Expect integration test SUCCESS on $RELEASE with SRU version cloud-init 23.3.3" # Run current integration tests with this proposed SRU upload from ppa:cloud-init-dev/proposed which will succeed CLOUD_INIT_OS_IMAGE=$RELEASE CLOUD_INIT_CLOUD_INIT_SOURCE=ppa:cloud-init-dev/proposed tox -e integration-tests tests/integration_tests/modules/test_ansible.py::test_ansible_pull_pip done [Regression Potential] This is resolving a bug that broke/regressed only environments with have pip version < 23.0.1 and provide the following custom user-data during VM launch: ansible:   install_method: pip    ... It is a very specific fix for a targeted use-case and will not regress typical deployments using cloud-init [Other info] - Community comment filed against upstream PR indicating this problem https://github.com/canonical/cloud-init/commit/b417b21816827f0b1324cf0df633487c43b15dad#commitcomment-130714494 - Original issue filed against integration test failures https://github.com/canonical/cloud-init/issues/4244
2023-11-17 20:42:52 James Falcon attachment added test_output.txt https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2040291/+attachment/5720594/+files/test_output.txt
2023-11-17 20:44:47 James Falcon tags verification-needed verification-needed-focal verification-needed-jammy verification-needed-lunar verification-needed-mantic verification-done verification-done-focal verification-done-jammy verification-done-lunar verification-done-mantic
2023-11-27 18:36:42 Launchpad Janitor cloud-init (Ubuntu Mantic): status Fix Committed Fix Released
2023-11-27 18:36:54 Timo Aaltonen removed subscriber Ubuntu Stable Release Updates Team
2023-11-27 18:37:08 Launchpad Janitor cloud-init (Ubuntu Lunar): status Fix Committed Fix Released
2023-11-27 18:37:21 Launchpad Janitor cloud-init (Ubuntu Jammy): status Fix Committed Fix Released
2023-11-27 18:37:29 Launchpad Janitor cloud-init (Ubuntu Focal): status Fix Committed Fix Released