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 |
|