cli behavior changed for commands passing optional --file argument to cloud-init init, modules or single subcommand
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Released
|
Undecided
|
Unassigned | ||
Mantic |
Fix Released
|
Undecided
|
Unassigned | ||
Noble |
Invalid
|
Undecided
|
Unassigned | ||
Oracular |
Invalid
|
Undecided
|
Unassigned |
Bug 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://
echo deb \$mirror \$(lsb_release -sc)-proposed main | tee /etc/apt/
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:/
[2] https:/
description: | updated |
summary: |
- cli behavior changed + cli behavior changed for commands passing optional --file argument to + cloud-init init, modules or single subcommand |
description: | updated |
I'm told that for noble and later, the change in behavior that this SRU is reverting will not be applied, as there it's intended. I'll thus make this clear by adding noble and Oracular tasks and marking them as invalid.