** Description changed: [ 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. + * 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. + 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. + * 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 + * 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 > 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 + $ 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 + $ 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 - # 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 + * 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 <subcmd> -f <myfile> - $ lxc exec test-f -- cloud-init -f /myfile.yaml init - $ lxc exec test-f -- hostname # expect 'worked' + # 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 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 + # 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. + * 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
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2064300 Title: cli behavior changed for commands passing optional --file argument to cloud-init init, modules or single subcommand To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2064300/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
