** Description changed: [Impact] * In environments where coud-init-generator detects no viable datasources, cloud-init systemd units are not included in the boot process and `cloud-init status --wait` blocks indefinitely reporting "not run" state instead of "disabled". Utilities which rely on the blocking statu will sit indefinitely as cloud-init will never run in these scenarios. This upload ensures that the expected artifact of cloud-init-generator emits a /run/cloud-init/disabled file (which cloud-init status --wait expects to see when coud-init is disabled at generator timeframe) which allows cloud-init status --wait to return expected "disabed" status. [Test Plan] * this is reproducible by disabling LXD nocloud metadata templates and security.devlxd=false configuration which will allow cloud-init- generator to find no viable datasources during systemd generator time frame. Cloud-init status --wait in this case should not block, but return 'disabled' status immediately after systemd generator is run. - Procedure: + Procedure * lxc launch ubuntu-daily:<series> test-series # To avoid LXD datasource detection don't allow /dev/lxd/sock in instance * lxc config set test-<series< security.devlxd=false # Remove nocloud-net cloud-init instance metadata to avoid NoCloud * lxc exec test-<series> -- rm -rf /var/lib/cloud/seed/nocloud-net # clean reboot of cloud-init to ensure generator detection * lxc exec test-<series> -- cloud-init clean --logs --reboot # make sure cloud-init status --wait doesn't block indefiinitely in this case * lxc exec tests-<series> -- cloud-init status --wait - This is captured by cloud-init integration test runner with the - following invocation + This is captured by cloud-init integration test + https://github.com/canonical/cloud-init/blob/main/tests/integration_tests/cmd/test_status.py + + It can be run with the following: for $SERIES in bionic focal impish; do - CLOUD_INIT_PLATFORM=lxd_container CLOUD_INIT_CLOUD_INIT_SOURCE=PROPOSED CLOUD_INIT_OS_IMAGE=$SERIES tox -e integration-tests tests/integration_tests/cmd/test_status.py + CLOUD_INIT_PLATFORM=lxd_container CLOUD_INIT_CLOUD_INIT_SOURCE=PROPOSED CLOUD_INIT_OS_IMAGE=$SERIES tox -e integration-tests tests/integration_tests/cmd/test_status.py done [Where problems could occur] * Problems can occur if cloud-init early exits from `cloud-init status --wait` without blocking if 3rd party apps/scripts which expect to block until cloud-init completes start running before cloud-init is "done" could could lead to unexpected system configuration or apt-lock issues if scripts attempt to install packages [Other Info] [Original Description] Calling "cloud-init status --wait" never returns if ds-identify cannot find a datasource. In https://github.com/canonical/cloud-init/pull/1162, we modified status checks to wait until we get an "enabled" or "disabled" file from ds- identiy. ds-identify never outputs a "disabled" file, so "status --wait" will wait indefinitely if no datasource is found. A simple reproduction is to change "ret=1" on this line: https://github.com/canonical/cloud-init/blob/main/tools/ds-identify#L1866
** Description changed: [Impact] * In environments where coud-init-generator detects no viable datasources, cloud-init systemd units are not included in the boot process and `cloud-init status --wait` blocks indefinitely reporting "not run" state instead of "disabled". Utilities which rely on the blocking statu will sit indefinitely as cloud-init will never run in these scenarios. This upload ensures that the expected artifact of cloud-init-generator emits a /run/cloud-init/disabled file (which cloud-init status --wait expects to see when coud-init is disabled at generator timeframe) which allows cloud-init status --wait to return expected "disabed" status. [Test Plan] * this is reproducible by disabling LXD nocloud metadata templates and security.devlxd=false configuration which will allow cloud-init- generator to find no viable datasources during systemd generator time frame. Cloud-init status --wait in this case should not block, but return 'disabled' status immediately after systemd generator is run. Procedure * lxc launch ubuntu-daily:<series> test-series # To avoid LXD datasource detection don't allow /dev/lxd/sock in instance * lxc config set test-<series< security.devlxd=false # Remove nocloud-net cloud-init instance metadata to avoid NoCloud * lxc exec test-<series> -- rm -rf /var/lib/cloud/seed/nocloud-net # clean reboot of cloud-init to ensure generator detection * lxc exec test-<series> -- cloud-init clean --logs --reboot # make sure cloud-init status --wait doesn't block indefiinitely in this case * lxc exec tests-<series> -- cloud-init status --wait - This is captured by cloud-init integration test + This test procedure is captured by cloud-init integration test https://github.com/canonical/cloud-init/blob/main/tests/integration_tests/cmd/test_status.py It can be run with the following: for $SERIES in bionic focal impish; do - CLOUD_INIT_PLATFORM=lxd_container CLOUD_INIT_CLOUD_INIT_SOURCE=PROPOSED CLOUD_INIT_OS_IMAGE=$SERIES tox -e integration-tests tests/integration_tests/cmd/test_status.py + CLOUD_INIT_PLATFORM=lxd_container CLOUD_INIT_CLOUD_INIT_SOURCE=PROPOSED CLOUD_INIT_OS_IMAGE=$SERIES tox -e integration-tests tests/integration_tests/cmd/test_status.py done [Where problems could occur] * Problems can occur if cloud-init early exits from `cloud-init status --wait` without blocking if 3rd party apps/scripts which expect to block until cloud-init completes start running before cloud-init is "done" could could lead to unexpected system configuration or apt-lock issues if scripts attempt to install packages [Other Info] [Original Description] Calling "cloud-init status --wait" never returns if ds-identify cannot find a datasource. In https://github.com/canonical/cloud-init/pull/1162, we modified status checks to wait until we get an "enabled" or "disabled" file from ds- identiy. ds-identify never outputs a "disabled" file, so "status --wait" will wait indefinitely if no datasource is found. A simple reproduction is to change "ret=1" on this line: https://github.com/canonical/cloud-init/blob/main/tools/ds-identify#L1866 ** Description changed: [Impact] - * In environments where coud-init-generator detects no viable + * In environments where cloud-init-generator detects no viable datasources, cloud-init systemd units are not included in the boot process and `cloud-init status --wait` blocks indefinitely reporting "not run" state instead of "disabled". Utilities which rely on the blocking statu will sit indefinitely as cloud-init will never run in these scenarios. This upload ensures that the expected artifact of cloud-init-generator emits a /run/cloud-init/disabled file (which cloud-init status --wait expects to see when coud-init is disabled at generator timeframe) which allows cloud-init status --wait to return expected "disabed" status. [Test Plan] * this is reproducible by disabling LXD nocloud metadata templates and security.devlxd=false configuration which will allow cloud-init- generator to find no viable datasources during systemd generator time frame. Cloud-init status --wait in this case should not block, but return 'disabled' status immediately after systemd generator is run. Procedure * lxc launch ubuntu-daily:<series> test-series # To avoid LXD datasource detection don't allow /dev/lxd/sock in instance * lxc config set test-<series< security.devlxd=false # Remove nocloud-net cloud-init instance metadata to avoid NoCloud * lxc exec test-<series> -- rm -rf /var/lib/cloud/seed/nocloud-net # clean reboot of cloud-init to ensure generator detection * lxc exec test-<series> -- cloud-init clean --logs --reboot # make sure cloud-init status --wait doesn't block indefiinitely in this case * lxc exec tests-<series> -- cloud-init status --wait This test procedure is captured by cloud-init integration test https://github.com/canonical/cloud-init/blob/main/tests/integration_tests/cmd/test_status.py It can be run with the following: for $SERIES in bionic focal impish; do CLOUD_INIT_PLATFORM=lxd_container CLOUD_INIT_CLOUD_INIT_SOURCE=PROPOSED CLOUD_INIT_OS_IMAGE=$SERIES tox -e integration-tests tests/integration_tests/cmd/test_status.py done [Where problems could occur] * Problems can occur if cloud-init early exits from `cloud-init status --wait` without blocking if 3rd party apps/scripts which expect to block until cloud-init completes start running before cloud-init is "done" could could lead to unexpected system configuration or apt-lock issues if scripts attempt to install packages [Other Info] [Original Description] Calling "cloud-init status --wait" never returns if ds-identify cannot find a datasource. In https://github.com/canonical/cloud-init/pull/1162, we modified status checks to wait until we get an "enabled" or "disabled" file from ds- identiy. ds-identify never outputs a "disabled" file, so "status --wait" will wait indefinitely if no datasource is found. A simple reproduction is to change "ret=1" on this line: https://github.com/canonical/cloud-init/blob/main/tools/ds-identify#L1866 ** Description changed: [Impact] * In environments where cloud-init-generator detects no viable datasources, cloud-init systemd units are not included in the boot process and `cloud-init status --wait` blocks indefinitely reporting "not run" state instead of "disabled". Utilities which rely on the - blocking statu will sit indefinitely as cloud-init will never run in + blocking status will sit indefinitely as cloud-init will never run in these scenarios. This upload ensures that the expected artifact of cloud-init-generator emits a /run/cloud-init/disabled file (which cloud-init status --wait expects to see when coud-init is disabled at generator timeframe) which allows cloud-init status --wait to return expected "disabed" status. [Test Plan] * this is reproducible by disabling LXD nocloud metadata templates and security.devlxd=false configuration which will allow cloud-init- generator to find no viable datasources during systemd generator time frame. Cloud-init status --wait in this case should not block, but return 'disabled' status immediately after systemd generator is run. Procedure * lxc launch ubuntu-daily:<series> test-series # To avoid LXD datasource detection don't allow /dev/lxd/sock in instance * lxc config set test-<series< security.devlxd=false # Remove nocloud-net cloud-init instance metadata to avoid NoCloud * lxc exec test-<series> -- rm -rf /var/lib/cloud/seed/nocloud-net # clean reboot of cloud-init to ensure generator detection * lxc exec test-<series> -- cloud-init clean --logs --reboot # make sure cloud-init status --wait doesn't block indefiinitely in this case * lxc exec tests-<series> -- cloud-init status --wait This test procedure is captured by cloud-init integration test https://github.com/canonical/cloud-init/blob/main/tests/integration_tests/cmd/test_status.py It can be run with the following: for $SERIES in bionic focal impish; do CLOUD_INIT_PLATFORM=lxd_container CLOUD_INIT_CLOUD_INIT_SOURCE=PROPOSED CLOUD_INIT_OS_IMAGE=$SERIES tox -e integration-tests tests/integration_tests/cmd/test_status.py done [Where problems could occur] * Problems can occur if cloud-init early exits from `cloud-init status --wait` without blocking if 3rd party apps/scripts which expect to block until cloud-init completes start running before cloud-init is "done" could could lead to unexpected system configuration or apt-lock issues if scripts attempt to install packages [Other Info] [Original Description] Calling "cloud-init status --wait" never returns if ds-identify cannot find a datasource. In https://github.com/canonical/cloud-init/pull/1162, we modified status checks to wait until we get an "enabled" or "disabled" file from ds- identiy. ds-identify never outputs a "disabled" file, so "status --wait" will wait indefinitely if no datasource is found. A simple reproduction is to change "ret=1" on this line: https://github.com/canonical/cloud-init/blob/main/tools/ds-identify#L1866 ** Description changed: [Impact] * In environments where cloud-init-generator detects no viable datasources, cloud-init systemd units are not included in the boot process and `cloud-init status --wait` blocks indefinitely reporting "not run" state instead of "disabled". Utilities which rely on the blocking status will sit indefinitely as cloud-init will never run in these scenarios. This upload ensures that the expected artifact of cloud-init-generator emits a /run/cloud-init/disabled file (which cloud-init status --wait expects to see when coud-init is disabled at generator timeframe) which - allows cloud-init status --wait to return expected "disabed" status. + allows cloud-init status --wait to return expected "disabled" status. [Test Plan] - * this is reproducible by disabling LXD nocloud metadata templates and - security.devlxd=false configuration which will allow cloud-init- - generator to find no viable datasources during systemd generator time - frame. Cloud-init status --wait in this case should not block, but - return 'disabled' status immediately after systemd generator is run. + * this scenario is reproducible by disabling LXD nocloud metadata + templates and security.devlxd=false configuration which will allow + cloud-init-generator to find no viable datasources during systemd + generator time frame. Cloud-init status --wait in this case should not + block, but return 'disabled' status immediately after systemd generator + is run. Procedure * lxc launch ubuntu-daily:<series> test-series # To avoid LXD datasource detection don't allow /dev/lxd/sock in instance * lxc config set test-<series< security.devlxd=false # Remove nocloud-net cloud-init instance metadata to avoid NoCloud * lxc exec test-<series> -- rm -rf /var/lib/cloud/seed/nocloud-net # clean reboot of cloud-init to ensure generator detection * lxc exec test-<series> -- cloud-init clean --logs --reboot # make sure cloud-init status --wait doesn't block indefiinitely in this case * lxc exec tests-<series> -- cloud-init status --wait This test procedure is captured by cloud-init integration test https://github.com/canonical/cloud-init/blob/main/tests/integration_tests/cmd/test_status.py It can be run with the following: for $SERIES in bionic focal impish; do CLOUD_INIT_PLATFORM=lxd_container CLOUD_INIT_CLOUD_INIT_SOURCE=PROPOSED CLOUD_INIT_OS_IMAGE=$SERIES tox -e integration-tests tests/integration_tests/cmd/test_status.py done [Where problems could occur] * Problems can occur if cloud-init early exits from `cloud-init status --wait` without blocking if 3rd party apps/scripts which expect to block until cloud-init completes start running before cloud-init is "done" could could lead to unexpected system configuration or apt-lock issues if scripts attempt to install packages [Other Info] [Original Description] Calling "cloud-init status --wait" never returns if ds-identify cannot find a datasource. In https://github.com/canonical/cloud-init/pull/1162, we modified status checks to wait until we get an "enabled" or "disabled" file from ds- identiy. ds-identify never outputs a "disabled" file, so "status --wait" will wait indefinitely if no datasource is found. A simple reproduction is to change "ret=1" on this line: https://github.com/canonical/cloud-init/blob/main/tools/ds-identify#L1866 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1966085 Title: cloud-init status --wait never returns if datasource not found To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1966085/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
