| 2024-04-30 15:15:16 |
Brett Holman |
bug |
|
|
added bug |
| 2024-04-30 15:15:37 |
Brett Holman |
nominated for series |
|
Ubuntu Jammy |
|
| 2024-04-30 15:15:37 |
Brett Holman |
bug task added |
|
cloud-init (Ubuntu Jammy) |
|
| 2024-04-30 15:15:37 |
Brett Holman |
nominated for series |
|
Ubuntu Mantic |
|
| 2024-04-30 15:15:37 |
Brett Holman |
bug task added |
|
cloud-init (Ubuntu Mantic) |
|
| 2024-04-30 15:15:37 |
Brett Holman |
nominated for series |
|
Ubuntu Focal |
|
| 2024-04-30 15:15:37 |
Brett Holman |
bug task added |
|
cloud-init (Ubuntu Focal) |
|
| 2024-05-01 02:31:17 |
Chad Smith |
description |
Originally reported on Github[1], cloud-init released a change in the cli[2] that broke former cloud-init cli commands.
Previously `cloud-init -f <file> init` was allowed, but after the 24.1 SRU release to Jammy, this broke and
now the following invocation is required to accomplish the same thing: `cloud-init init -f foo.cfg`. There is apparently no syntax that is compatible with both versions.
This is a change in behavior that was released under SRU back to stable releases.
[1] https://github.com/canonical/cloud-init/pull/4559#issuecomment-2084860007
[2] https://github.com/canonical/cloud-init/pull/4559 |
[ Impact ]
* Environments or scripts which directly call cloud-init subcommands and
provide an optional -f or --file argument to inject supplemental
configuration after first boot will receive usage errors on the command
line which will break any supplemental scripted setup of configuration.
This affects some platforms which may provide secondary configuration after
cloud-init's first boot.
Workaround:
Upstream cloud-init requires -f/--file arguments come after the
subcommand instead of before. Change the order of these parameters, placing
-f or --file after the subcommand as a workaround while awaiting an SRU fix.
* Direct calls to cloud-init init, modules or single are atypical for most
deployments because automated configuration generally relies on
cloud-init systemd units running the various boot stages invoking the
cloud-init CLI directly. But, to better support custom environments which
need to provide an additional layer of configuration after first boot, this
change in behavior is something we would like to resolve on stable releases.
[ Test Plan ]
* Launch daily images in LXC and confirm usage failure inf cloud-init 24.1.3
when providing supplemental file config before the init subcommand:
cloud-init -f myfile.yaml init
$ cat > myfile.yaml <<EOF
#cloud-config
hostname: worked
EOF
$ cat > setup_proposed.sh <<EOF
#/bin/bash
mirror=http://archive.ubuntu.com/ubuntu
echo deb \$mirror \$(lsb_release -sc)-proposed main | tee /etc/apt/sources.list.d/proposed.list
apt-get update -q
apt-get install -qy cloud-init
cloud-init --version
EOF
$ lxc launch ubuntu-daily:focal test-focal
$ lxc exec test-focal bash
$ hostname # confirm test-focal from standard meta-data
test-focal
$ cloud-init clean # allow running init stage again
$ lxc file push myfile.yaml test-focal/
$ lxc exec test-focal bash
$ apt update; apt install cloud-init -y; cloud-init --version
# confirm usage failure
$ cloud-init -f /myfile.yaml init
* Upgrade cloud-init to -proposed and confirm -f argument is supported before
or after the init subcommand
$ lxc file push setup_proposed.sh test-focal/
$ lxc exec test-f -- sh /setup_proposed.sh
# Assert cloud-init -f <myfile> <subcmd>
$ lxc exec test-f -- cloud-init -f /myfile.yaml init
$ lxc exec test-f -- hostname # expect 'worked'
$ lxc exec test-f -- hostname test-f # reset hostname
$ lxc exec test-f -- cloud-init clean # reset cloud-init
# Assert cloud-init <subcmd> -f <myfile>
$ lxc exec test-f -- cloud-init -f /myfile.yaml init
$ lxc exec test-f -- hostname # expect 'worked'
# Assert all default systemd unit behavior is unaffected by this changeset
$ lxc exec test-f -- cloud-init clean --logs ---reboot
$ sleep 4
# Assert no errors or warnings logged from default boot stages
$ lxc exec test-f -- cloud-init status --wait --format=yaml
[ Where problems could occur ]
* Problems introduced in argument parsing on the CLI could adversely effect
the default systemd units for cloud-init's 4 boot stages which call
cloud-init init and modules subcommands no the CLI inside each systemd unit.
Errors or warnings in any of these boot stages would show up in cloud-init
status --format=yaml output or cause cloud-init to exit non-zero leaving the
booted system in degraded state.
[ Other Info ]
==== original desciption ====
Originally reported on Github[1], cloud-init released a change in the cli[2] that broke former cloud-init cli commands.
Previously `cloud-init -f <file> init` was allowed, but after the 24.1 SRU release to Jammy, this broke and
now the following invocation is required to accomplish the same thing: `cloud-init init -f foo.cfg`. There is apparently no syntax that is compatible with both versions.
This is a change in behavior that was released under SRU back to stable releases.
[1] https://github.com/canonical/cloud-init/pull/4559#issuecomment-2084860007
[2] https://github.com/canonical/cloud-init/pull/4559 |
|
| 2024-05-01 17:05:01 |
Chad Smith |
summary |
cli behavior changed |
cli behavior changed for commands passing optional --file argument to cloud-init init, modules or single subcommand |
|
| 2024-05-02 20:06:22 |
James Falcon |
description |
[ Impact ]
* Environments or scripts which directly call cloud-init subcommands and
provide an optional -f or --file argument to inject supplemental
configuration after first boot will receive usage errors on the command
line which will break any supplemental scripted setup of configuration.
This affects some platforms which may provide secondary configuration after
cloud-init's first boot.
Workaround:
Upstream cloud-init requires -f/--file arguments come after the
subcommand instead of before. Change the order of these parameters, placing
-f or --file after the subcommand as a workaround while awaiting an SRU fix.
* Direct calls to cloud-init init, modules or single are atypical for most
deployments because automated configuration generally relies on
cloud-init systemd units running the various boot stages invoking the
cloud-init CLI directly. But, to better support custom environments which
need to provide an additional layer of configuration after first boot, this
change in behavior is something we would like to resolve on stable releases.
[ Test Plan ]
* Launch daily images in LXC and confirm usage failure inf cloud-init 24.1.3
when providing supplemental file config before the init subcommand:
cloud-init -f myfile.yaml init
$ cat > myfile.yaml <<EOF
#cloud-config
hostname: worked
EOF
$ cat > setup_proposed.sh <<EOF
#/bin/bash
mirror=http://archive.ubuntu.com/ubuntu
echo deb \$mirror \$(lsb_release -sc)-proposed main | tee /etc/apt/sources.list.d/proposed.list
apt-get update -q
apt-get install -qy cloud-init
cloud-init --version
EOF
$ lxc launch ubuntu-daily:focal test-focal
$ lxc exec test-focal bash
$ hostname # confirm test-focal from standard meta-data
test-focal
$ cloud-init clean # allow running init stage again
$ lxc file push myfile.yaml test-focal/
$ lxc exec test-focal bash
$ apt update; apt install cloud-init -y; cloud-init --version
# confirm usage failure
$ cloud-init -f /myfile.yaml init
* Upgrade cloud-init to -proposed and confirm -f argument is supported before
or after the init subcommand
$ lxc file push setup_proposed.sh test-focal/
$ lxc exec test-f -- sh /setup_proposed.sh
# Assert cloud-init -f <myfile> <subcmd>
$ lxc exec test-f -- cloud-init -f /myfile.yaml init
$ lxc exec test-f -- hostname # expect 'worked'
$ lxc exec test-f -- hostname test-f # reset hostname
$ lxc exec test-f -- cloud-init clean # reset cloud-init
# Assert cloud-init <subcmd> -f <myfile>
$ lxc exec test-f -- cloud-init -f /myfile.yaml init
$ lxc exec test-f -- hostname # expect 'worked'
# Assert all default systemd unit behavior is unaffected by this changeset
$ lxc exec test-f -- cloud-init clean --logs ---reboot
$ sleep 4
# Assert no errors or warnings logged from default boot stages
$ lxc exec test-f -- cloud-init status --wait --format=yaml
[ Where problems could occur ]
* Problems introduced in argument parsing on the CLI could adversely effect
the default systemd units for cloud-init's 4 boot stages which call
cloud-init init and modules subcommands no the CLI inside each systemd unit.
Errors or warnings in any of these boot stages would show up in cloud-init
status --format=yaml output or cause cloud-init to exit non-zero leaving the
booted system in degraded state.
[ Other Info ]
==== original desciption ====
Originally reported on Github[1], cloud-init released a change in the cli[2] that broke former cloud-init cli commands.
Previously `cloud-init -f <file> init` was allowed, but after the 24.1 SRU release to Jammy, this broke and
now the following invocation is required to accomplish the same thing: `cloud-init init -f foo.cfg`. There is apparently no syntax that is compatible with both versions.
This is a change in behavior that was released under SRU back to stable releases.
[1] https://github.com/canonical/cloud-init/pull/4559#issuecomment-2084860007
[2] https://github.com/canonical/cloud-init/pull/4559 |
[ Impact ]
* Environments or scripts which directly call cloud-init subcommands and
provide an optional -f or --file argument to inject supplemental
configuration after first boot will receive usage errors on the command
line which will break any supplemental scripted setup of configuration.
This affects some platforms which may provide secondary configuration after
cloud-init's first boot.
Workaround:
Upstream cloud-init requires -f/--file arguments come after the
subcommand instead of before. Change the order of these parameters, placing
-f or --file after the subcommand as a workaround while awaiting an SRU fix.
* Direct calls to cloud-init init, modules or single are atypical for most
deployments because automated configuration generally relies on
cloud-init systemd units running the various boot stages invoking the
cloud-init CLI directly. But, to better support custom environments which
need to provide an additional layer of configuration after first boot, this
change in behavior is something we would like to resolve on stable releases.
[ Test Plan ]
* Launch daily images in LXC and confirm usage failure inf cloud-init 24.1.3
when providing supplemental file config before the init subcommand:
cloud-init -f myfile.yaml init
$ cat > myfile.yaml <<EOF
#cloud-config
hostname: worked
EOF
$ cat > setup_proposed.sh <<EOF
#/bin/bash
mirror=http://archive.ubuntu.com/ubuntu
echo deb \$mirror \$(lsb_release -sc)-proposed main | tee /etc/apt/sources.list.d/proposed.list
apt-get update -q
apt-get install -qy cloud-init
cloud-init --version
EOF
$ lxc launch ubuntu-daily:focal test-focal
$ lxc exec test-focal bash
$ hostname # confirm test-focal from standard meta-data
test-focal
$ cloud-init clean # allow running init stage again
$ lxc file push myfile.yaml test-focal/
$ lxc exec test-focal bash
$ apt update; apt install cloud-init -y; cloud-init --version
# confirm usage failure
$ cloud-init -f /myfile.yaml init
* Upgrade cloud-init to -proposed and confirm -f argument is supported before
or after the init subcommand
$ lxc file push setup_proposed.sh test-focal/
$ lxc exec test-f -- sh /setup_proposed.sh
# Assert cloud-init -f <myfile> <subcmd>
$ lxc exec test-f -- cloud-init -f /myfile.yaml init
$ lxc exec test-f -- hostname # expect 'worked'
$ lxc exec test-f -- hostname test-f # reset hostname
$ lxc exec test-f -- cloud-init clean # reset cloud-init
# Assert cloud-init <subcmd> -f <myfile>
$ lxc exec test-f -- cloud-init init -f /myfile.yaml
$ lxc exec test-f -- hostname # expect 'worked'
# Assert all default systemd unit behavior is unaffected by this changeset
$ lxc exec test-f -- cloud-init clean --logs ---reboot
$ sleep 4
# Assert no errors or warnings logged from default boot stages
$ lxc exec test-f -- cloud-init status --wait --format=yaml
[ Where problems could occur ]
* Problems introduced in argument parsing on the CLI could adversely effect
the default systemd units for cloud-init's 4 boot stages which call
cloud-init init and modules subcommands no the CLI inside each systemd unit.
Errors or warnings in any of these boot stages would show up in cloud-init
status --format=yaml output or cause cloud-init to exit non-zero leaving the
booted system in degraded state.
[ Other Info ]
==== original desciption ====
Originally reported on Github[1], cloud-init released a change in the cli[2] that broke former cloud-init cli commands.
Previously `cloud-init -f <file> init` was allowed, but after the 24.1 SRU release to Jammy, this broke and
now the following invocation is required to accomplish the same thing: `cloud-init init -f foo.cfg`. There is apparently no syntax that is compatible with both versions.
This is a change in behavior that was released under SRU back to stable releases.
[1] https://github.com/canonical/cloud-init/pull/4559#issuecomment-2084860007
[2] https://github.com/canonical/cloud-init/pull/4559 |
|
| 2024-05-02 20:29:20 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Noble |
|
| 2024-05-02 20:29:20 |
Andreas Hasenack |
bug task added |
|
cloud-init (Ubuntu Noble) |
|
| 2024-05-02 20:29:20 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Oracular |
|
| 2024-05-02 20:29:20 |
Andreas Hasenack |
bug task added |
|
cloud-init (Ubuntu Oracular) |
|
| 2024-05-02 20:29:27 |
Andreas Hasenack |
cloud-init (Ubuntu Oracular): status |
New |
Invalid |
|
| 2024-05-02 20:29:30 |
Andreas Hasenack |
cloud-init (Ubuntu Noble): status |
New |
Invalid |
|
| 2024-05-02 20:33:49 |
Andreas Hasenack |
cloud-init (Ubuntu Mantic): status |
New |
Fix Committed |
|
| 2024-05-02 20:33:51 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2024-05-02 20:33:53 |
Andreas Hasenack |
bug |
|
|
added subscriber SRU Verification |
| 2024-05-02 20:34:08 |
Andreas Hasenack |
tags |
|
verification-needed verification-needed-mantic |
|
| 2024-05-02 20:34:49 |
Andreas Hasenack |
cloud-init (Ubuntu Jammy): status |
New |
Fix Committed |
|
| 2024-05-02 20:34:56 |
Andreas Hasenack |
tags |
verification-needed verification-needed-mantic |
verification-needed verification-needed-jammy verification-needed-mantic |
|
| 2024-05-02 20:35:45 |
Andreas Hasenack |
cloud-init (Ubuntu Focal): status |
New |
Fix Committed |
|
| 2024-05-02 20:35:51 |
Andreas Hasenack |
tags |
verification-needed verification-needed-jammy verification-needed-mantic |
verification-needed verification-needed-focal verification-needed-jammy verification-needed-mantic |
|
| 2024-05-04 02:34:03 |
Chad Smith |
tags |
verification-needed verification-needed-focal verification-needed-jammy verification-needed-mantic |
verification-done-focal verification-needed verification-needed-jammy verification-needed-mantic |
|
| 2024-05-04 02:55:10 |
Chad Smith |
tags |
verification-done-focal verification-needed verification-needed-jammy verification-needed-mantic |
verification-done-focal verification-done-jammy verification-needed verification-needed-mantic |
|
| 2024-05-04 04:45:58 |
Chad Smith |
tags |
verification-done-focal verification-done-jammy verification-needed verification-needed-mantic |
verification-done verification-done-focal verification-done-jammy verification-done-mantic |
|
| 2024-05-10 10:13:14 |
Timo Aaltonen |
tags |
verification-done verification-done-focal verification-done-jammy verification-done-mantic |
verification-done-focal verification-done-jammy verification-needed verification-needed-mantic |
|
| 2024-05-10 10:29:18 |
Timo Aaltonen |
tags |
verification-done-focal verification-done-jammy verification-needed verification-needed-mantic |
verification-done-focal verification-needed verification-needed-jammy verification-needed-mantic |
|
| 2024-05-10 10:29:58 |
Timo Aaltonen |
tags |
verification-done-focal verification-needed verification-needed-jammy verification-needed-mantic |
verification-needed verification-needed-focal verification-needed-jammy verification-needed-mantic |
|
| 2024-05-10 18:03:18 |
Chad Smith |
tags |
verification-needed verification-needed-focal verification-needed-jammy verification-needed-mantic |
verification-done-focal verification-needed verification-needed-jammy verification-needed-mantic |
|
| 2024-05-10 18:08:06 |
Chad Smith |
tags |
verification-done-focal verification-needed verification-needed-jammy verification-needed-mantic |
verification-done-focal verification-done-jammy verification-needed verification-needed-mantic |
|
| 2024-05-10 18:14:45 |
Chad Smith |
tags |
verification-done-focal verification-done-jammy verification-needed verification-needed-mantic |
verification-done verification-done-focal verification-done-jammy verification-done-mantic |
|
