[Yahoo-eng-team] [Bug 2088207] Re: cloud-init enables ssh password auth in an unexpected config file

[Brett Holman]

> the most technically advantageous and correct way to configure ssh

Agreed

> How is cloud-init making sure another file in sshd_config.d isn't
superseding its config?

It isn't. I just filed an upstream bug to track this as an issue - and
linked it above.

> sshd -T should be consulted, instead of trying to mimic what sshd -T
does

Agreed, however ssh -G is more robust since -T is more likely to have
failing tests.

> I'm adding the openssh package to this bug

Thanks! That approach sounds good to me.

Since the cloud-init (ubuntu) project exists to track issues in cloud-
init on Ubuntu, I'm going to mark it as invalid for now. Feel free to
change that back if you believe this to still be an issue with cloud-
init.

** Bug watch added: github.com/canonical/cloud-init/issues #5879
   https://github.com/canonical/cloud-init/issues/5879

** Also affects: cloud-init via
   https://github.com/canonical/cloud-init/issues/5879
   Importance: Unknown
   Status: Unknown

** Changed in: cloud-init (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/2088207

Title:
  cloud-init enables ssh password auth in an unexpected config file

Status in cloud-init:
  Unknown
Status in cloud-init package in Ubuntu:
  Invalid
Status in openssh package in Ubuntu:
  New

Bug description:
  Last night secur...@ubuntu.com received a security report about cloud-init:
  ```
  Hello

  Most server admins are familiar with disabling password auth in 
/etc/ssh/sshd_config.
  However Ubuntu Server 24.04 when installed from the ISO 
(https://ubuntu.com/download/server)
   includes a new file `/etc/ssh/sshd_config.d/50-cloud-init.conf`.

  This means that disabling password auth in `/etc/ssh/sshd_config` does
  nothing:

  # To disable tunneled clear text passwords, change to no here!
  PasswordAuthentication no
  ^ Setting it to "no" does nothing

  Server admins also need to delete `/etc/ssh/sshd_config.d/50-cloud-
  init.conf` which contains a single line:

  PasswordAuthentication yes

  There is no documentation for server admins that this is necessary in
  /etc/ssh/sshd_config nor is this expected and will cause massive
  security problems as upgrade in the future. People are just
  discovering this behaviour now:

  [0] https://www.mikeberggren.com/deb-ssh-auth
  [1] https://askubuntu.com/questions/1516262/why-is-50-cloud-init-conf-created
  [2] https://askubuntu.com/a/435620

  Recommendation:
  1. Don't include this file by default
  2. OR update sshd_config documentation so people know to check 
/etc/ssh/ssd_config.d/

  lllf
  ```

  @falcojr from cloud-init added that:
  > this happens due to the subiquity installer setting passwordauthentication 
yes by default
  > cloud-init writes any explicit configuration about ssh into sshd_config.d

  To summarize:
  Often `PasswordAuthentication` is disabled in `/etc/ssh/sshd_config`. When 
cloud-init is used, this value is set in 
`/etc/ssh/sshd_config.d/50-cloud-init.conf` and will override 
`/etc/ssh/sshd_config`. If an admin is not aware of this additional config file 
or how sshd loads configs, they may unintentionally allow 
PasswordAuthentication.

  My inclination is to opt for lllf's second recommendation and clearly 
document the additional config file. Possibly the header of 
/etc/ssh/sshd_config could include:
  ```
  # Note that cloud-init has generated /etc/ssh/sshd_config.d/50-cloud-init.conf
  # configurations in sshd_config.d may override settings in this file
  # such as overriding PasswordAuthentication to yes
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2088207/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1946088] Re: package module: all packages fail to install if just one has failed on http 503, no retries options are available

[Brett Holman]

Thanks for the feedback. Since it sounds like there is already a
workable solution in place, I'm going to close this. If you think
further action is required please reopen and communicate what that would
be.

** Changed in: cloud-init
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1946088

Title:
  package module: all packages fail to install if just one has failed on
  http 503, no retries options are available

Status in cloud-init:
  Invalid

Bug description:
  **Explanation**
  Seems like the teleport repo was unavailable temporarily for some reason, 
maybe just this request was 503d. But this renders big hassle to kick in - 
engineers should dig why the deployment failed. While most probably with 
retries it would've probably just installed a bit later. I've searched for 
retries options in the docs, but failed to find them. Just found one mention in 
the PRs on GitHub that retries are bad, since it'll just spam the logs. If it's 
the established policy - can we please have this declared in the docs? Though, 
it'd be a strange one. It's better to have more logs, than semideployed 
instance, IMHO. Thanks for reading through all the rumbling.

  **Observed behaviour:**
  Cloud-init fails to install all packages if any one of the packages is 
unavailable.

  **Desired/expected behaviour:**
  Install available packages, fail to install just the unavailable packages. 
Have an option to retry installation, for example: retries: 15, 
wait-before-retry: 1m

  **Cloud provider: selectel**

  **Related config part:**

  ```
  hostname: ${hostname}.${project_fqdn}
  fqdn: ${hostname}.${project_fqdn}

  system_info:
    default_user:
  name: ...
  ...
  groups: [adm, audio, cdrom, dialout, floppy, video, plugdev, dip, netdev]
  ...
  shell: /bin/bash
  ssh_authorized_keys:
    - ${ssh_key}

  users:
    - default

  apt:
    preserve_sources_list: true
    sources:
  teleport:
    source: deb https://deb.releases.teleport.dev/ stable main
    keyid: C87ED53A6282C411
  docker:
    source: deb [arch=amd64] https://download.docker.com/linux/ubuntu 
$RELEASE stable
    keyid: 9DC858229FC7DD38854AE2D88D81803C0EBFCD88

  debconf_selections: |
    iptables-persistent iptables-persistent/autosave_v4 boolean true

  package_update: true

  packages:
    - mc
    - wget
    - jq
    - unzip
    - curl
    - xfsprogs
    - lvm2
    - teleport
    - docker-ce
    - iptables-persistent
  ```

  **Related log parts:**

  ```
  [   16.597420] cloud-init[994]: Get:1 http://repo.os.selectel.org bionic 
InRelease [10.7 kB]
  [   16.610710] cloud-init[994]: Get:2 http://mirror.selectel.ru/ubuntu bionic 
InRelease [242 kB]
  [   16.617046] cloud-init[994]: Get:3 http://mirror.selectel.ru/ubuntu 
bionic-updates InRelease [88.7 kB]
  [   16.623838] cloud-init[994]: Get:4 http://mirror.selectel.ru/ubuntu 
bionic-backports InRelease [74.6 kB]
  [   16.678604] cloud-init[994]: Get:5 
https://download.docker.com/linux/ubuntu bionic InRelease [64.4 kB]
  [   16.709311] cloud-init[994]: Get:6 http://repo.os.selectel.org bionic/main 
all Packages [2105 B]
  [   16.720857] cloud-init[994]: Get:7 http://repo.os.selectel.org bionic/main 
amd64 Packages [2105 B]
  [   16.809186] cloud-init[994]: Get:8 http://mirror.selectel.ru/ubuntu 
bionic/main Sources [829 kB]
  [   16.843598] cloud-init[994]: Get:9 http://mirror.selectel.ru/ubuntu 
bionic/multiverse Sources [181 kB]
  [   16.845851] cloud-init[994]: Get:10 http://mirror.selectel.ru/ubuntu 
bionic/restricted Sources [5324 B]
  [   16.848508] cloud-init[994]: Get:11 http://mirror.selectel.ru/ubuntu 
bionic/universe Sources [9051 kB]
  [   16.960021] cloud-init[994]: Get:12 http://security.ubuntu.com/ubuntu 
bionic-security InRelease [88.7 kB]
  [   16.982934] cloud-init[994]: Get:13 http://mirror.selectel.ru/ubuntu 
bionic/main amd64 Packages [1019 kB]
  [   16.999303] cloud-init[994]: Get:14 http://mirror.selectel.ru/ubuntu 
bionic/restricted amd64 Packages [9184 B]
  [   17.002854] cloud-init[994]: Get:15 http://mirror.selectel.ru/ubuntu 
bionic/universe amd64 Packages [8570 kB]
  [   17.110796] cloud-init[994]: Get:16 http://mirror.selectel.ru/ubuntu 
bionic/multiverse amd64 Packages [151 kB]
  [   17.116528] cloud-init[994]: Get:17 http://mirror.selectel.ru/ubuntu 
bionic-updates/restricted Sources [23.7 kB]
  [   17.119188] cloud-init[994]: Get:18 http://mirror.selectel.ru/ubuntu 
bionic-updates/universe Sources [456 kB]
  [   17.122502] cloud-init[994]: Err:19 https://deb.releases.teleport.dev 
stable InRelease
  [   17.124650] cloud-init[994]:   503  Service Unavailable [IP: 13.33.246.28 
443]
  [   17.126251] cloud-init[994]: Get:20 http://mirror.selectel.ru/ubuntu 
bionic-updates/multiverse Sources [15.9 kB]
  [   17.128904] cloud-init[994]: Get:21 http://mirror.selectel.ru/ubuntu 
bionic-updates/main

[Yahoo-eng-team] [Bug 1954789] Re: FreeBSD - double quotes for rc.conf

[Brett Holman]

I don't think this has anything to do with "_unquote()", which is used
for parsing the file.

The behavior you are seeing is due to shlex.quote()[1][2], which
produces POSIX shell tokens:

>  shlex.quote(s)
>
> Return a shell-escaped version of the string s. The returned value is a 
> string that can safely be used as one token in a shell command line, for 
> cases where you cannot use a list.

Without a compelling reason to make this change, it would likely be
better to stick with a library implementation than to roll our own. If
this behavior were the result of a function that was part of cloud-init
function, then I would tend to agree with you; neat & tidy would be
better than the alternative. As it stands I don't think current behavior
is broken and shlex provides some security, so I'm going to close this.

Feel free to reopen if you still think this is worthwhile behavior to
change and we can discuss further.


[1] 
https://github.com/canonical/cloud-init/blob/a97fd062f7dbd4b824fd006edd08927ef9dbf24a/cloudinit/distros/bsd_utils.py#L32
[2] https://docs.python.org/3/library/shlex.html#shlex.quote

** Changed in: cloud-init
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1954789

Title:
  FreeBSD - double quotes for rc.conf

Status in cloud-init:
  Invalid

Bug description:
  Please ensure all variable values are double quoted in "etc/rc.conf".

  While rc.conf(5) does not explicitly call for the use of single or
  double quotes in ${rc_conf_files}, "etc/defaults/rc.conf" does.
  rc.conf(5) does, in fact, use double quotes '"' in all of it's
  examples. It is best practice to keep "etc/rc.conf" neat and tidy with
  the use of double quotes around all variable values.

  The bsd_utils.py (https://github.com/canonical/cloud-
  init/blob/main/cloudinit/distros/bsd_utils.py#L15) script has a
  "_unquote" function, that seems counterintuitive to the formatting of
  this file.

  ## etc/defaults/rc.conf
  
  # All arguments must be in double or single quotes.
  #
  # For a more detailed explanation of all the rc.conf variables, please
  # refer to the rc.conf(5) manual page.
  

  ## etc/rc.conf with a mix of quotes and no quotes, as applied by cloud-init
  $ cat /etc/rc.conf
  sshd_enable="YES"
  cloudinit_enable="YES"
  qemu_guest_agent_enable="YES"
  qemu_guest_agent_flags="-d -v -l /var/log/qemu-ga.log"
  ntpdate_enable="YES"
  ntpdate_flags="ntp.domain.net"
  ntpd_enable="YES"
  ifconfig_vtnet0_name=eth0
  defaultrouter=1.2.3.1
  ifconfig_eth0='1.2.3.4 netmask 255.255.255.0'
  hostname=freebsd13-short.localdomain

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1954789/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1818302] Re: Need to keep apply_network_config=false in azure data source and make it configurable through cloud-init

[Brett Holman]

I just noticed the date on this, please disregard previous comments.
This showed up in the triage bug queue as NEW for some reason and I
failed to note the date.

It seems this was resolved in a previous release, please reopen if
further attention to this issue is required.

** Changed in: cloud-init
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1818302

Title:
  Need to keep apply_network_config=false in azure data source and make
  it configurable through cloud-init

Status in cloud-init:
  Fix Released

Bug description:
  Cloud Provider: Azure
  Image: Ubuntu 18.04 LTS

  New release of 18.04 LTS on Azure has apply_network_config=true, this
  forces cloud-init to use metadata to get all the IP address. If a
  virtual machine as a lot of nics with secondary IP addresses by the
  time IPs are configured, the azure data source ends up using secondary
  CA to talk to 168.* address which is not supported. All communications
  must use Primary CA. Due to this high percentage of provisioning
  failures occurs on Ubuntu 18.04 for VMs with multiple Nics and
  secondary addresses.

  
  019-02-05 00:26:53,652 - azure.py[DEBUG]: Azure endpoint found at 
168.63.129.16
  2019-02-05 00:26:53,652 - url_helper.py[DEBUG]: [0/11] open 
'http://168.63.129.16/machine/?comp=goalstate' with {'url': 
'http://168.63.129.16/machine/?comp=goalstate', 'allow_redirects': True, 
'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent': 
'Cloud-Init/18.4-0ubuntu1~18.04.1', 'x-ms-agent-name': 'WALinuxAgent', 
'x-ms-version': '2012-11-30'}} configuration
  2019-02-05 00:26:58,660 - url_helper.py[DEBUG]: Please wait 1 seconds while 
we wait to try again
  2019-02-05 00:26:59,662 - url_helper.py[DEBUG]: [1/11] open 
'http://168.63.129.16/machine/?comp=goalstate' with {'url': 
'http://168.63.129.16/machine/?comp=goalstate', 'allow_redirects': True, 
'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent': 
'Cloud-Init/18.4-0ubuntu1~18.04.1', 'x-ms-agent-name': 'WALinuxAgent', 
'x-ms-version': '2012-11-30'}} configuration
  2019-02-05 00:27:04,668 - url_helper.py[DEBUG]: Please wait 1 seconds while 
we wait to try again
  2019-02-05 00:27:05,670 - url_helper.py[DEBUG]: [2/11] open 
'http://168.63.129.16/machine/?comp=goalstate' with {'url': 
'http://168.63.129.16/machine/?comp=goalstate', 'allow_redirects': True, 
'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent': 
'Cloud-Init/18.4-0ubuntu1~18.04.1', 'x-ms-agent-name': 'WALinuxAgent', 
'x-ms-version': '2012-11-30'}} configuration
  2019-02-05 00:27:10,676 - url_helper.py[DEBUG]: Please wait 1 seconds while 
we wait to try again

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1818302/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1960939] [NEW] Release 22.1

[Brett Holman]

Public bug reported:

== Release Notes ==

Cloud-init release 22.1 is now available

The 22.1 release:
 * spanned about 3 months
 * had 27 contributors from 29 domains
 * fixed 8 Launchpad issues

Highlights:
  

== Changelog ==
 - sources/azure: report ready in local phase (#1265) [Chris Patterson]
 - sources/azure: validate IMDS network configuration metadata (#1257)
   [Chris Patterson]
 - docs: Add more details to runcmd docs (#1266)
 - use PEP 589 syntax for TypeDict (#1253)
 - mypy: introduce type checking (#1254) [Chris Patterson]
 - Fix extra ipv6 issues, code reduction and simplification (#1243) [eb3095]
 - tests: when generating crypted password, generate in target env (#1252)
 - sources/azure: address mypy/pyright typing complaints (#1245)
   [Chris Patterson]
 - Docs for x-shellscript* userdata (#1260)
 - test_apt_security: azure platform has specific security URL overrides
   (#1263)
 - tests: lsblk --json output changes mountpoint key to mountpoinst []
   (#1261)
 - mounts: fix mount opts string for ephemeral disk (#1250)
   [Chris Patterson]
 - Shell script handlers by freq (#1166) [Chris Lalos]
 - minor improvements to documentation (#1259) [Mark Esler]
 - cloud-id: publish /run/cloud-init/cloud-id- files (#1244)
 - add "eslerm" as contributor (#1258) [Mark Esler]
 - sources/azure: refactor ssh key handling (#1248) [Chris Patterson]
 - bump pycloudlib (#1256)
 - sources/hetzner: Use EphemeralDHCPv4 instead of static configuration
   (#1251) [Markus Schade]
 - bump pycloudlib version (#1255)
 - Fix IPv6 netmask format for sysconfig (#1215) [Harald] (LP: #1959148)
 - sources/azure: drop debug print (#1249) [Chris Patterson]
 - tests: do not check instance.pull_file().ok() (#1246)
 - sources/azure: consolidate ephemeral DHCP configuration (#1229)
   [Chris Patterson]
 - cc_salt_minion freebsd fix for rc.conf (#1236)
 - sources/azure: fix metadata check in _check_if_nic_is_primary() (#1232)
   [Chris Patterson]
 - Add _netdev option to mount Azure ephemeral disk (#1213) [Eduardo Otubo]
 - testing: stop universally overwriting /etc/cloud/cloud.cfg.d (#1237)
 - Integration test changes (#1240)
 - Fix Gentoo Locales (#1205)
 - Add "slingamn" as contributor (#1235) [Shivaram Lingamneni]
 - integration: do not LXD bind mount /etc/cloud/cloud.cfg.d (#1234)
 - Integration testing docs and refactor (#1231)
 - vultr: Return metadata immediately when found (#1233) [eb3095]
 - spell check docs with spellintian (#1223)
 - docs: include upstream python version info (#1230)
 - Schema a d (#1211)
 - Move LXD to end ds-identify DSLIST (#1228) (LP: #1959118)
 - fix parallel tox execution (#1214)
 - sources/azure: refactor _report_ready_if_needed and _poll_imds (#1222)
   [Chris Patterson]
 - Do not support setting up archive.canonical.com as a source (#1219)
   [Steve Langasek] (LP: #1959343)
 - Vultr: Fix lo being used for DHCP, try next on cmd fail (#1208) [eb3095]
 - sources/azure: refactor _should_reprovision[_after_nic_attach]() logic
   (#1206) [Chris Patterson]
 - update ssh logs to show ssh private key gens pub and simplify code
   (#1221) [Steve Weber]
 - Remove mitechie from stale PR github action (#1217)
 - Include POST format in cc_phone_home docs (#1218) (LP: #1959149)
 - Add json parsing of ip addr show (SC-723) (#1210)
 - cc_rsyslog: fix typo in docstring (#1207) [Louis Sautier]
 - Update .github-cla-signers (#1204) [Chris Lalos]
 - sources/azure: drop unused case in _report_failure() (#1200)
   [Chris Patterson]
 - sources/azure: always initialize _ephemeral_dhcp_ctx on unpickle (#1199)
   [Chris Patterson]
 - Add support for gentoo templates and cloud.cfg (#1179) [vteratipally]
 - sources/azure: unpack ret tuple in crawl_metadata() (#1194)
   [Chris Patterson]
 - tests: focal caplog has whitespace indentation for multi-line logs
   (#1201)
 - Seek interfaces, skip dummy interface, fix region codes (#1192) [eb3095]
 - integration: test against the Ubuntu daily images (#1198)
   [Paride Legovini]
 - cmd: status and cloud-id avoid change in behavior for 'not run' (#1197)
 - tox: pass PYCLOUDLIB_* env vars into integration tests when present
   (#1196)
 - sources/azure: set ovf_is_accessible when OVF is read successfully
   (#1193) [Chris Patterson]
 - Enable OVF environment transport via ISO in example (#1195) [Megian]
 - sources/azure: consolidate DHCP variants to EphemeralDHCPv4WithReporting
   (#1190) [Chris Patterson]
 - Single JSON schema validation in early boot (#1175)
 - Add DatasourceOVF network-config propery to Ubuntu OVF example (#1184)
   [Megian]
 - testing: support pycloudlib config file (#1189)
 - Ensure system_cfg read before ds net config on Oracle (SC-720) (#1174)
   (LP: #1956788)
 - Test Optimization Proposal (SC-736) (#1188)
 - cli: cloud-id report not-run or disabled state as cloud-id (#1162)
 - Remove distutils usage (#1177) [Shreenidhi Shedi]
 - add .python-version to gitignore (#1186)
 - print error if datasource import fails (#1170)
   [Emanuele Giuseppe Esposito]
 - Add

[Yahoo-eng-team] [Bug 1960939] Re: Release 22.1

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.1. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1960939

Title:
  Release 22.1

Status in cloud-init:
  Fix Released

Bug description:
  == Release Notes ==

  Cloud-init release 22.1 is now available

  The 22.1 release:
   * spanned about 3 months
   * had 27 contributors from 29 domains
   * fixed 8 Launchpad issues

  Highlights:
   - Remove 3.5 and xenial support
   - Add miraclelinux support
   - Add Strict Metaschema Validation
   - Add new config module to set keyboard layout

  == Changelog ==
   - sources/azure: report ready in local phase (#1265) [Chris Patterson]
   - sources/azure: validate IMDS network configuration metadata (#1257)
     [Chris Patterson]
   - docs: Add more details to runcmd docs (#1266)
   - use PEP 589 syntax for TypeDict (#1253)
   - mypy: introduce type checking (#1254) [Chris Patterson]
   - Fix extra ipv6 issues, code reduction and simplification (#1243) [eb3095]
   - tests: when generating crypted password, generate in target env (#1252)
   - sources/azure: address mypy/pyright typing complaints (#1245)
     [Chris Patterson]
   - Docs for x-shellscript* userdata (#1260)
   - test_apt_security: azure platform has specific security URL overrides
     (#1263)
   - tests: lsblk --json output changes mountpoint key to mountpoinst []
     (#1261)
   - mounts: fix mount opts string for ephemeral disk (#1250)
     [Chris Patterson]
   - Shell script handlers by freq (#1166) [Chris Lalos]
   - minor improvements to documentation (#1259) [Mark Esler]
   - cloud-id: publish /run/cloud-init/cloud-id- files (#1244)
   - add "eslerm" as contributor (#1258) [Mark Esler]
   - sources/azure: refactor ssh key handling (#1248) [Chris Patterson]
   - bump pycloudlib (#1256)
   - sources/hetzner: Use EphemeralDHCPv4 instead of static configuration
     (#1251) [Markus Schade]
   - bump pycloudlib version (#1255)
   - Fix IPv6 netmask format for sysconfig (#1215) [Harald] (LP: #1959148)
   - sources/azure: drop debug print (#1249) [Chris Patterson]
   - tests: do not check instance.pull_file().ok() (#1246)
   - sources/azure: consolidate ephemeral DHCP configuration (#1229)
     [Chris Patterson]
   - cc_salt_minion freebsd fix for rc.conf (#1236)
   - sources/azure: fix metadata check in _check_if_nic_is_primary() (#1232)
     [Chris Patterson]
   - Add _netdev option to mount Azure ephemeral disk (#1213) [Eduardo Otubo]
   - testing: stop universally overwriting /etc/cloud/cloud.cfg.d (#1237)
   - Integration test changes (#1240)
   - Fix Gentoo Locales (#1205)
   - Add "slingamn" as contributor (#1235) [Shivaram Lingamneni]
   - integration: do not LXD bind mount /etc/cloud/cloud.cfg.d (#1234)
   - Integration testing docs and refactor (#1231)
   - vultr: Return metadata immediately when found (#1233) [eb3095]
   - spell check docs with spellintian (#1223)
   - docs: include upstream python version info (#1230)
   - Schema a d (#1211)
   - Move LXD to end ds-identify DSLIST (#1228) (LP: #1959118)
   - fix parallel tox execution (#1214)
   - sources/azure: refactor _report_ready_if_needed and _poll_imds (#1222)
     [Chris Patterson]
   - Do not support setting up archive.canonical.com as a source (#1219)
     [Steve Langasek] (LP: #1959343)
   - Vultr: Fix lo being used for DHCP, try next on cmd fail (#1208) [eb3095]
   - sources/azure: refactor _should_reprovision[_after_nic_attach]() logic
     (#1206) [Chris Patterson]
   - update ssh logs to show ssh private key gens pub and simplify code
     (#1221) [Steve Weber]
   - Remove mitechie from stale PR github action (#1217)
   - Include POST format in cc_phone_home docs (#1218) (LP: #1959149)
   - Add json parsing of ip addr show (SC-723) (#1210)
   - cc_rsyslog: fix typo in docstring (#1207) [Louis Sautier]
   - Update .github-cla-signers (#1204) [Chris Lalos]
   - sources/azure: drop unused case in _report_failure() (#1200)
     [Chris Patterson]
   - sources/azure: always initialize _ephemeral_dhcp_ctx on unpickle (#1199)
     [Chris Patterson]
   - Add support for gentoo templates and cloud.cfg (#1179) [vteratipally]
   - sources/azure: unpack ret tuple in crawl_metadata() (#1194)
     [Chris Patterson]
   - tests: focal caplog has whitespace indentation for multi-line logs
     (#1201)
   - Seek interfaces, skip dummy interface, fix region codes (#1192) [eb3095]
   - integration: test against the Ubuntu daily images (#1198)
     [Paride Legovini]
   - cmd: status and cloud-id avoid change in behavior for 'not run' (#1197)
   - tox: pass PYCLOUDLIB_* env vars into integration tests when present
     (#1196)
   - sources/azure: set ovf_is_accessible when OVF is read successfully
     (#1193) [Chris P

[Yahoo-eng-team] [Bug 1959149] Re: Phone-home documentation is lacking

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.1. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1959149

Title:
  Phone-home documentation is lacking

Status in cloud-init:
  Fix Released

Bug description:
  From:
  https://cloudinit.readthedocs.io/en/latest/topics/modules.html#phone-
  home

  There is no documentation present on how the server receiving the
  phone-home call can expect the data. What fields are present, what
  does each key give the server, what data format is used etc.

  I think this is a problem that should be addressed to make it easier
  for developers, like me, who want to build a server which is phone-
  home'd to by cloud-init. This should be documented, rather than
  require the developer to figure it out by trial and error.

  The provided reporting guidelines do not apply to this bug report, as
  it is not a bug in cloud-init itself.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1959149/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1876941] Re: Document that network-config MAC addresses should be lower case

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.1. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1876941

Title:
  Document that network-config MAC addresses should be lower case

Status in cloud-init:
  Fix Released

Bug description:
  Currently users may see failures if using upper-case MAC addresses in
  network configuration, because cloud-init does not appropriately
  normalise the case of MAC addresses in all situations.

  https://cloudinit.readthedocs.io/en/latest/topics/network-config-
  format-v2.html should be updated to (a) only use lower-case MAC
  addresses, and (b) indicate to users that this is an intentional
  choice that they need to follow.

  (https://bugs.launchpad.net/cloud-init/+bug/1876363 covers fixing the
  underlying issue, this is strictly about documenting the currently-
  required input.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1876941/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1825027] Re: cloudinit tests fail when running as root

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.1. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1825027

Title:
  cloudinit tests fail when running as root

Status in cloud-init:
  Fix Released

Bug description:
  The tests under cloudinit/cmd/tests/test_query.py will fail if run as
  root.

  sudo nosetests3 test_query.py --debug=query

  query: WARNING: Missing root-readable 
/tmp/ci-TestQuery.0ztjrur1/run_dir/instance-data-sensitive.json. Using redacted 
/tmp/ci-TestQuery.0ztjrur1/run_dir/instance-data.json instead.
  query: ERROR: Missing instance-data file: 
/tmp/ci-TestQuery.0ztjrur1/run_dir/instance-data.json
  .Equery: ERROR: Missing instance-data file: /tmp/ci-TestQuery.2_qzzunv/absent
  .query: ERROR: Expected one of the options: --all, --format, --list-keys or 
varname
  .query: ERROR: No read permission on '/tmp/ci-TestQuery.faxmaofy/unreadable'. 
Try sudo
  .EEquery: WARNING: Missing root-readable 
/tmp/ci-TestQuery.rhy7l_rq/run_dir/instance-data-sensitive.json. Using redacted 
/tmp/ci-TestQuery.rhy7l_rq/run_dir/instance-data.json instead.
  query: ERROR: Missing instance-data file: 
/tmp/ci-TestQuery.rhy7l_rq/run_dir/instance-data.json
  ..
  ==
  ERROR: 
cloudinit.cmd.tests.test_query.TestQuery.test_handle_args_dumps_all_instance_data
  --
  Traceback (most recent call last):
File "/home/anhvo/repos/cloud-init/cloudinit/cmd/tests/test_query.py", line 
153, in test_handle_args_dumps_all_instance_data
  self.assertEqual(0, query.handle_args('anyname', args))
File "/home/anhvo/repos/cloud-init/cloudinit/cmd/query.py", line 124, in 
handle_args
  instance_data['userdata'] = util.load_file(user_data_fn)
File "/home/anhvo/repos/cloud-init/cloudinit/util.py", line 1359, in 
load_file
  with open(fname, 'rb') as ifh:
  FileNotFoundError: [Errno 2] No such file or directory: 'ud'

  ==
  ERROR: 
cloudinit.cmd.tests.test_query.TestQuery.test_handle_args_list_keys_errors_when_varname_is_not_a_dict
  --
  Traceback (most recent call last):
File "/home/anhvo/repos/cloud-init/cloudinit/cmd/tests/test_query.py", line 
255, in test_handle_args_list_keys_errors_when_varname_is_not_a_dict
  self.assertEqual(1, query.handle_args('anyname', args))
File "/home/anhvo/repos/cloud-init/cloudinit/cmd/query.py", line 124, in 
handle_args
  instance_data['userdata'] = util.load_file(user_data_fn)
File "/home/anhvo/repos/cloud-init/cloudinit/util.py", line 1359, in 
load_file
  with open(fname, 'rb') as ifh:
  FileNotFoundError: [Errno 2] No such file or directory: 'ud'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1825027/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1959148] Re: cloud-init writes route6-$DEVICE config with a HEX netmask. ip route does not like : Error: inet6 prefix is expected rather than "fd00:fd00:fd00::/ffff:ffff:ffff:fff

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.1. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1959148

Title:
  cloud-init writes route6-$DEVICE config with a HEX netmask. ip route
  does not like : Error: inet6 prefix is expected rather than
  "fd00:fd00:fd00::/:::::".

Status in cloud-init:
  Fix Released
Status in OpenStack Compute (nova):
  New

Bug description:
  Description of problem:
  The routes put in route6-$DEVICE by cloud-init is in an invalid format.

  The schema[1] for network_matadata uses a non-converntinal format for
  the IPv6 netmask. It is stored as an IPv6 address, similar to how IPv4
  netmasks are written 255.255.255.0 the IPv6 netmask is written as
  ::::: in the network metadata.

  cloud-init does not translate this. So you end up with:

  cat /etc/sysconfig/network-scripts/route6-ens3
  # Created by cloud-init on instance boot automatically, do not edit.
  #
  ::/:: via fd00:fd00:fd00:2::fffe  dev ens3
  fd00:fd00:fd00:1::/::::: via fd00:fd00:fd00:2::fffe  dev ens3
  fd00:fd00:fd00::/::::: via fd00:fd00:fd00:2::fffe  dev ens3

  The result is that the routes are ignored since it is not a valid
  inet6 prefix.

  [1]
  
https://docs.openstack.org/nova/latest/_downloads/9119ca7ac90aa2990e762c08baea3a36/network_data.json

  
  Actual results:
  Jan 26 14:12:45 overcloud-novacompute-0 NetworkManager[1027]:   
[1643206365.7973] ifcfg-rh: ignoring invalid route at "::/:: via 
fd00:fd00:fd00:2::fffe  dev ens3" 
(/etc/sysconfig/network-scripts/route6-ens3:3): Argument for "::/::" is not 
ADDR/PREFIX format
  Jan 26 14:12:45 overcloud-novacompute-0 NetworkManager[1027]:   
[1643206365.7977] ifcfg-rh: ignoring invalid route at 
"fd00:fd00:fd00:1::/::::: via fd00:fd00:fd00:2::fffe  dev ens3" 
(/etc/sysconfig/network-scripts/route6-ens3:4): Argument for 
"fd00:fd00:fd00:1::/:::::" is not ADDR/PREFIX format
  Jan 26 14:12:45 overcloud-novacompute-0 NetworkManager[1027]:   
[1643206365.7979] ifcfg-rh: ignoring invalid route at 
"fd00:fd00:fd00::/::::: via fd00:fd00:fd00:2::fffe  dev ens3" 
(/etc/sysconfig/network-scripts/route6-ens3:5): Argument for 
"fd00:fd00:fd00::/:::::" is not ADDR/PREFIX format

  ip -6 route add fd00:fd00:fd00::/::::: via fd00:fd00:fd00::1
  Error: inet6 prefix is expected rather than 
"fd00:fd00:fd00::/:::::".

  Expected results:
  The netmask should be the decimal number in CIDR annotation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1959148/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1944611] Re: Apt lock race on Oracle

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.1. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1944611

Title:
  Apt lock race on Oracle

Status in cloud-init:
  Fix Released

Bug description:
  When trying to do any kind of apt operation via cloud-init on Oracle,
  the operation often fails because snap seeding is holding the apt
  lock:

  cloud-init.log:
  2021-06-15 21:32:31,809 - util.py[WARNING]: Running module ubuntu-drivers 
() failed
  2021-06-15 21:32:31,809 - util.py[DEBUG]: Running module ubuntu-drivers 
() failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 885, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 186, in run
  results = functor(*args)
File 
"/usr/lib/python3/dist-packages/cloudinit/config/cc_ubuntu_drivers.py", line 
161, in handle
  install_drivers(cfg['drivers'], cloud.distro.install_packages)
File 
"/usr/lib/python3/dist-packages/cloudinit/config/cc_ubuntu_drivers.py", line 
115, in install_drivers
  pkg_install_func(['ubuntu-drivers-common'])
File "/usr/lib/python3/dist-packages/cloudinit/distros/debian.py", line 
111, in install_packages
  self.update_package_sources()
File "/usr/lib/python3/dist-packages/cloudinit/distros/debian.py", line 
206, in update_package_sources
  ["update"], freq=PER_INSTANCE)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 186, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/distros/debian.py", line 
202, in package_command
  args=(cmd,), kwargs={'env': e, 'capture': False})
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2348, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/subp.py", line 295, in subp
  cmd=args)
  cloudinit.subp.ProcessExecutionError: Unexpected error while running command.
  Command: ['eatmydata', 'apt-get', '--option=Dpkg::Options::=--force-confold', 
'--option=Dpkg::options::=--force-unsafe-io', '--assume-yes', '--quiet', 
'update']

  cloud-init-output.log:
  Reading package lists...
  E: Could not get lock /var/lib/apt/lists/lock - open (11: Resource 
temporarily unavailable)
  E: Unable to lock directory /var/lib/apt/lists/
  Cloud-init v. 21.1-19-gbad84ad4-0ubuntu1~18.04.2 running 'modules:final' at 
Tue, 15 Jun 2021 21:32:29 +. Up 36.68 seconds.
  2021-06-15 21:32:31,809 - util.py[WARNING]: Running module ubuntu-drivers 
() failed

  apt/history.log:
  Start-Date: 2021-06-15  21:32:39
  Commandline: apt install -o Dpkg::Options::=--force-confold -y dpkg-sig
  Requested-By: snap_daemon (584788)
  Install: libconfig-file-perl:amd64 (1.50-3, automatic), dpkg-sig:amd64 
(0.13.1+nmu4)
  End-Date: 2021-06-15  21:32:40

  I've also seen another snap entry in a separate log:
  Start-Date: 2021-09-21  21:35:53
  Commandline: apt --allow-downgrades install -o 
Dpkg::Options::=--force-confold -y 
/var/lib/oracle-cloud-agent/plugins/unifiedmonitoring/temp-unified-monitoring.deb
  Requested-By: snap_daemon (584788)
  Install: unified-monitoring-agent:amd64 (2.5.8-0)
  End-Date: 2021-09-21  21:36:12

  This is most easily observed when launching an instance with the following 
cloud-config:
  #cloud-config
  drivers:
nvidia:
  license-accepted: true

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1944611/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1956788] Re: system_cfg not read on Oracle datasource

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.1. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1956788

Title:
  system_cfg not read on Oracle datasource

Status in cloud-init:
  Fix Released

Bug description:
  In https://github.com/canonical/cloud-
  init/commit/2c52e6e88b19f5db8d55eb7280ee27703e05d75f , the order of
  reading network config was changed for Oracle due to initramfs needing
  to take lower precedence than the datasource. However, this also
  bumped system_cfg to a lower precedence than ds, which means that any
  network configuration specified in /etc/cloud will not be applied.

  system_cfg should instead be moved above ds so network configuration
  in /etc/cloud takes precedence.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1956788/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1949407] Re: crash in cloud-init when using set-name on networkd renderer

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.1. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1949407

Title:
  crash in cloud-init when using set-name on networkd renderer

Status in cloud-init:
  Fix Released

Bug description:
  When using set-name with a  networkd renderer, we are hitting the following 
crash:
  Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/cloudinit/cmd/main.py", line 682, in 
status_wrapper
  ret = functor(name, args)
File "/usr/lib/python3.7/site-packages/cloudinit/cmd/main.py", line 391, in 
main_init
  init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL))
File "/usr/lib/python3.7/site-packages/cloudinit/stages.py", line 825, in 
apply_network_config
  netcfg, bring_up=bring_up)
File "/usr/lib/python3.7/site-packages/cloudinit/distros/__init__.py", line 
222, in apply_network_config
  self._write_network_state(network_state)
File "/usr/lib/python3.7/site-packages/cloudinit/distros/__init__.py", line 
125, in _write_network_state
  renderer.render_network_state(network_state)
File "/usr/lib/python3.7/site-packages/cloudinit/net/networkd.py", line 
220, in render_network_state
  ret_dict = self._render_content(network_state)
File "/usr/lib/python3.7/site-packages/cloudinit/net/networkd.py", line 
245, in _render_content
  self.dhcp_domain(ns.config['ethernets'][name], cfg)
  KeyError: 'eth0'

  1. Tell us your cloud provider
  DataSourceVMware

  2. Any appropriate cloud-init configuration you can provide us
  instance-id: "management-appliance-control-plane-0"
  local-hostname: "management-appliance-control-plane-0"
  wait-on-network:
ipv4: false
ipv6: false
  network:
version: 2
ethernets:
  id0:
match:
  macaddress: "00:50:56:9d:14:42"
set-name: "eth0"
wakeonlan: true
addresses:
- "192.168.20.30/24"
gateway4: "192.168.20.1"
nameservers:
  addresses:
  - "127.0.0.53"
  - ""
  - ""

  3. Perform the following on the system and attach it to this bug:
  Attached is the output of cloud-init collect-logs

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1949407/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1948681] Re: Exception when no activator found

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.1. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1948681

Title:
  Exception when no activator found

Status in cloud-init:
  Fix Released

Bug description:
  On FreeBSD system:

  2021-10-24 14:00:10,707 - util.py[WARNING]: failed stage init
  failed run of stage init
  
  Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/cloudinit/cmd/main.py", line 
682, in status_wrapper
  ret = functor(name, args)
File "/usr/local/lib/python3.8/site-packages/cloudinit/cmd/main.py", line 
391, in main_init
  init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL))
File "/usr/local/lib/python3.8/site-packages/cloudinit/stages.py", line 
824, in apply_network_config
  return self.distro.apply_network_config(
File 
"/usr/local/lib/python3.8/site-packages/cloudinit/distros/__init__.py", line 
230, in apply_network_config
  network_activator = activators.select_activator()
File "/usr/local/lib/python3.8/site-packages/cloudinit/net/activators.py", 
line 274, in select_activator
  raise RuntimeError(
  RuntimeError: No available network activators found. Searched through list: 
[, , , ]
  

  Given that there are additional network management tools that we
  haven't yet supported with activators, we should log a warning and
  continue without network activation here, especially since this was a
  no-op for years.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1948681/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1951593] Re: Feature request: keyboard layout module

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.1. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1951593

Title:
  Feature request: keyboard layout module

Status in cloud-init:
  Fix Released

Bug description:
  It would be nice if generic support to set a keyboard layout was added
  to cloudinit.

  
  - It seems one can currently do set keyboard layout when using the Ubuntu 
installer, with autoinstall.
  But when using just cloudinit with ready made images (e.g. with the Ubuntu 
server images for the Pi), there does not seem to be an option for it.

  - As an alternative, I tried writing /etc/default/keyboard with write_files 
manually, and runcmd'ing "dpkg-reconfigure -f noninteractive 
keyboard-configuration" but that leaves to be desired.
  Since it is run pretty late in the boot process, the new keyboard layout does 
not take effect until first reboot.
  And it obviously will only work with Debian based distributions.
  Generic commands to set a keyboard layout (that could also work with other 
Linux distributions in the future) would be nicer.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1951593/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1954842] Re: ubuntu-advantage enable fips will fail due to missing --assume-yes

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.1. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1954842

Title:
  ubuntu-advantage enable fips will fail due to missing --assume-yes

Status in cloud-init:
  Fix Released

Bug description:
  cloud-provider: AWS
  cloud-init configuration (relevant section):

  ubuntu-advantage:
token: 
enable:
- fips

  (no reports attached, as bug is viewable in the code, however I can
  reproduce if you'd like)

  ubuntu-advantage (ua) calls often have prompts. the ubuntu_advantage
  directive runs without the `--assume-yes` flag from ua

  for service in enable:
  try:
  cmd = ['ua', 'enable', service]
  subp.subp(cmd, capture=True)
  except subp.ProcessExecutionError as e:
  enable_errors.append((service, e))

  
  
https://github.com/canonical/cloud-init/blob/bedac77e9348e7a54c0ec364fb61df90cd893972/cloudinit/config/cc_ubuntu_advantage.py#L124

  This will not work with FIPS, as running `ua enable fips` without
  `--assume-yes` will result in prompts.

  I propose having `ua enable --assume-yes $service` be the default call
  in cloud-init

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1954842/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1633453] Re: ssh is started before cloud-init completed

[Brett Holman]

This was resolved in upstream cloud-init in 23.3, which moved
Before=systemd-user-sessions.service from cloud-init.service to cloud-
config.service to resolve LP: #2013403. That change was temporarily
reverted on Ubuntu due to a snap-related performance regression. On
Noble and newer, the snap regression has been resolved, and with that
resolution the fix for this problem has been re-introduced.

Closing.

** Changed in: cloud-init (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1633453

Title:
  ssh is started before cloud-init completed

Status in cloud-init:
  Expired
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  Hello,

  Previously, ssh was only started after cloud-init finished configuring
  the host. In Yakkety, it is quite easy to log into a machine with SSH
  while cloud-init is still running. This enables to log as root or to
  run apt-get update while cloud-init is still finishing to write system
  configuration. This is annoying with automation.

  With Xenial, this never happens, but with Yakkety, this happens all
  the time.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1633453/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1861128] Re: getty.target starts before cloud-config is done

[Brett Holman]

** Changed in: cloud-init (Ubuntu)
   Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1861128

Title:
  getty.target starts before cloud-config is done

Status in cloud-init:
  Expired
Status in cloud-init package in Ubuntu:
  Won't Fix

Bug description:
  On targets that are normally accessed via serial console (i.e.
  Subiquity, Ubuntu Classic/Core on RPi, etc) cloud-init often does not
  complete before getty spawns login shell.

  This creates subpar user experience, as it appears as if one can
  login, and should be able to login using cloud-init provided
  credentials, but in practice cannot.

  To mitigate this we have started to add the following override on some
  of our images:

  See: http://launchpadlibrarian.net/461986467/livecd-
  rootfs_2.636_2.637.diff.gz

  +mkdir -p /etc/systemd/system/cloud-config.service.d
  +cat << EOF > /etc/systemd/system/cloud-config.service.d/getty-wait.conf
  +# Wait for cloud-init to finish (creating users, etc.) before running getty
  +
  +[Unit]
  +Before=getty.target
  +EOF

  Instead, cloud-config.service itself should declare
  `Before=getty.target`

  Use case is monitoring RPi booting on serial console, and loging in
  once getty is up. With expectation that login succeeds.

  Currently login fails, more cloud-config spew appears on screen, then
  one has to hit enter to realise that login is up, realize that one is
  now trying to login with empty username, hit enter again, and now type
  in username & password to finally login.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1861128/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1303934] Re: no error message to console when cloud-config-url fails to load

[Brett Holman]

** Changed in: cloud-init (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1303934

Title:
  no error message to console when cloud-config-url fails to load

Status in cloud-init:
  Expired
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  When booting an Ubuntu 12.04 ephmeral into MAAS commissioning on a
  node which was unable to reach the region controller, I got the
  following traceback:

  | Can not apply stage final, no datasource found! Likely bad things to come!
  | 
  | Traceback (most recent call last):
  |   File "/usr/bin/cloud-init", line 315, in main_modules
  | init.fetch()
  |   File "/usr/lib/python2.7/dist-packages/cloudinit/stages.py", line 302, in 
fetch
  | return self._get_data_source()
  |   File "/usr/lib/python2.7/dist-packages/cloudinit/stages.py", line 234, in 
_get_data_source
  | pkg_list)
  |   File "/usr/lib/python2.7/dist-packages/cloudinit/sources/__init__.py", 
line 212, in find_source
  | raise DataSourceNotFoundException(msg)
  | DataSourceNotFoundException: Did not find any data source, searched 
classes: ()
  | 

  Fuller log attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1303934/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1675571] Re: Cloud-init update renders secondary addresses to be incompatible with standard tools

[Brett Holman]

** Changed in: cloud-init (Ubuntu)
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1675571

Title:
  Cloud-init update renders secondary addresses to be incompatible with
  standard tools

Status in cloud-init:
  Expired
Status in curtin:
  Confirmed
Status in cloud-init package in Ubuntu:
  Won't Fix
Status in resolvconf package in Ubuntu:
  New
Status in resolvconf package in Debian:
  Won't Fix

Bug description:
  The change of how cloud-init renders 
/etc/network/interface.d/50-cloud-init.cfg, standard tools no longer work as 
expected:
  * resolvconf will nullify nameservers
  * if* commands ignore secondary addresses

  [ORIGINAL REPORT]

  Regresion from Bug #1657940.

  When provisioning with multiple eth0 addresses, /etc/resolv.conf is
  empty:

  Consider:
  root@tester:~# cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet static
  address 138.197.98.102
  dns-nameservers 8.8.8.8 8.8.4.4
  gateway 138.197.96.1
  netmask 255.255.240.0

  # control-alias eth0
  iface eth0 inet static
  address 10.17.0.11
  netmask 255.255.0.0

  Which then yields an empty /etc/resolv.conf:
  root@tester:/run/resolvconf# cat interface/eth0.inet

  root@tester:/run/resolvconf# cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

  The problem is that resolvconfg does pattern matching for eth*.inet.
  The second definition of eth0 has no nameserver and therefore
  overrides the definition.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1675571/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1703789] Re: Disk setup example text only lists MBR as valid table_type

[Brett Holman]

** Changed in: cloud-init (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1703789

Title:
  Disk setup example text only lists MBR as valid table_type

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  The disk setup example in the docs mentions that only MBR table_type
  is supported, while support for GPT was introduced in 0.7.7.

  See here for disk setup example text: https://git.launchpad.net/cloud-
  init/tree/doc/examples/cloud-config-disk-setup.txt#n99

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1703789/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1607345] Re: Collect all logs needed to debug curtin/cloud-init for each deployment

[Brett Holman]

Cloud-init now supports event reporting, so closing this item. If you
believe this to be not completed please open a new bug against cloud-
init on Github with more details.

** Changed in: cloud-init (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1607345

Title:
  Collect all logs needed to debug curtin/cloud-init for each deployment

Status in cloud-init:
  Expired
Status in MAAS:
  Expired
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Zesty:
  Won't Fix

Bug description:
  Re-opening this bug as confirmed because the previous SRU content
  released only provided only 'cloud-init collect-logs'. A command line
  tool which tars all cloud-init install logs and artifacts for triage.

  However, those fixes did not provide any configuration options for
  MAAS to request that those logs are automatically published to MAAS
  upon error.

  
  Cloud-init should provide cloud-config which allows consumers to specify an 
endpoint and oauth credentials to which cloud-init will automatically POST all 
compressed cloud-init log artifacts.

  
  === Original Description ===
  According to https://bugs.launchpad.net/maas/+bug/1604962/comments/12, these 
logs are needed to debug curtin/cloud-init issues but aren't collected 
automatically by MAAS:

  - /var/log/cloud-init*
  - /run/cloud-init*
  - /var/log/cloud
  - /tmp/install.log

  We need these to be automatically collected by MAAS so we can
  automatically collect them as artifacts in the case of failures in
  OIL.  curtin/cloud-init issues can be race conditions that are
  difficult to reproduce manually, so we need to grab the logs required
  to debug the first time it happens.

  === Begin SRU Template ===
  [Impact]
  ubuntu-bug cloud-init now collects cloud-init-related information for a 
bug-report

  [Test Case]

  # Launch instance under test
  $ for release in xenial zesty;
    do
  ref=$release-proposed;
  lxc-proposed-snapshot --proposed --publish $release $ref;
  lxc launch $ref $name;
  sleep 10;
  lxc exec $name ubuntu-bug cloud-init  # And follow the prompts to report 
a bogus bug
    done

  [Regression Potential]
  Worst case scenario is the apport wrapper doesn't work and the developer has 
to file a bug manually instead.

  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=ca2730e2ac86b05f7e6

  === End SRU Template ===

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1607345/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1969572] Re: documentation describes this as "the industry standard" anything

[Brett Holman]

The statement is intended to claim that it is in widespread use and is
widely supported, which is true. "Industry standard" is vague and open
to interpretation (as you've demonstrated). In this case, and commonly
in English usage, "industry standard" does not imply the existence of a
standards body.

** Changed in: cloud-init
   Status: New => Opinion

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1969572

Title:
  documentation describes this as "the industry standard" anything

Status in cloud-init:
  Opinion

Bug description:
  Can the documentation please be updated to no longer claim that this
  is "the industry standard" tool for cloud instance initialization?

  I realize the project is ambitious and empathize with that, but, it's
  misleading and I've had to correct folks who rely on the documentation
  and don't always see the merit of marketing.

  To be clear, there is no standards body that specifies cloud-init as
  "the industry standard" for anything as of the time of this bug
  filing, making the statement inaccurate.

  If it's just a wording thing, it's certainly used in the AWS space,
  but it's not as heavily used (by consumers of CSPs anyway) in the
  Azure and GCP space.  The 4 or so major CSPs seem to be mentioning it
  in their documentation, but this is not a reflection of how end users
  are doing things.

  I also cite the process I had to follow just to file this bug after
  being made aware of this in the github repository as evidence of
  "standard practices" having nothing to do with this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1969572/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1971105] Re: cloud-init not initing...

[Brett Holman]

dgarvey: Thanks for reporting back. I'm glad you figured it out.

It sounds like this has been resolved. Since I don't think this was an
issue with cloud-init, I'm marking it as "Invalid". Please reopen this
bug with more details if you believe that further action is required for
cloud-init.

Regards,
Brett Holman

** Changed in: cloud-init
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1971105

Title:
  cloud-init not initing...

Status in cloud-init:
  Invalid

Bug description:
  I am seeing systemd reset here.
  [root@sdo-img-rhel79-test-apr30 cloud-init_debug]# dmesg | grep -i term
  [  133.522528] systemd-journald[103]: Received SIGTERM from PID 1 (systemd).
  [root@sdo-img-rhel79-test-apr30 cloud-init_debug]# dmesg > dmesg.txt
  [root@sdo-img-rhel79-test-apr30 cloud-init_debug]#

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1971105/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1974053] [NEW] Release 22.2

[Brett Holman]

Public bug reported:

Summary: Release 22.2
Further information:
== Release Notes ==

Cloud-init release 22.2 is now available

The 22.2 release:
 * spanned about 3 months
 * had 28 contributors from 31 domains
 * fixed 1 Launchpad issues

Highlights:
  

== Changelog ==
 - Fix test due to caplog incompatibility (#1461) [Alberto Contreras]
 - Align rhel custom files with upstream (#1431)
   [Emanuele Giuseppe Esposito]
 - cc_write_files: Improve schema. (#1460) [Alberto Contreras]
 - cli: Redact files with permission errors in commands (#1440)
   [Alberto Contreras] (LP: #1953430)
 - Improve cc_set_passwords. (#1456) [Alberto Contreras]
 - testing: make fake cloud-init wait actually wait (#1459)
 - Scaleway: Fix network configuration for netplan 0.102 and later (#1455)
   [Maxime Corbin]
 - Fix 'ephmeral' typos in disk names(#1452) [Mike Hucka]
 - schema: version schema-cloud-config-v1.json (#1424)
 - cc_modules: set default meta frequency value when no config available
   (#1457)
 - Log generic warning on non-systemd systems. (#1450) [Alberto Contreras]
 - cc_snap.maybe_install_squashfuse no longer needed in Bionic++. (#1448)
   [Alberto Contreras]
 - Drop support of *-sk keys in cc_ssh (#1451) [Alberto Contreras]
 - testing: Fix console_log tests (#1437)
 - tests: cc_set_passoword update for systemd, non-systemd distros  (#1449)
 - Fix bug in url_helper/dual_stack() logging (#1426)
 - schema: render schema paths from _CustomSafeLoaderWithMarks (#1391)
   (GH: SC-929)
 - testing: Make integration tests kinetic friendly (#1441)
 - Handle error if SSH service no present. (#1422)
   [Alberto Contreras] (GH: #1969526)
 - Fix network-manager activator availability and order (#1438)
 - sources/azure: remove reprovisioning marker (#1414) [Chris Patterson]
 - upstart: drop vestigial support for upstart (#1421)
 - testing: Ensure NoCloud detected in test (#1439)
 - Update .github-cla-signers kallioli [Kevin Allioli]
 - Consistently strip top-level network key (#1417) (GH: #1906187)
 - testing: Fix LXD VM metadata test (#1430)
 - testing: Add NoCloud setup for NoCloud test (#1425)
 - Update linters and adapt code for compatibility (#1434) [Paride Legovini]
 - run-container: add support for LXD VMs (#1428) [Paride Legovini]
 - integration-reqs: bump pycloudlib pinned commit (#1427) [Paride Legovini]
 - Fix NoCloud docs (#1423)
 - Docs fixes (#1406)
 - docs: Add docs for module creation (#1415)
 - Remove cheetah from templater (#1416)
 - tests: verify_ordered_items fallback to re.escape if needed (#1420)
 - Misc module cleanup (#1418)
 - docs: Fix doc warnings and enable errors (#1419)
   [Alberto Contreras] (GH: #1876341)
 - Refactor cloudinit.sources.NetworkConfigSource to enum (#1413)
   [Alberto Contreras] (GH: #1874875)
 - Don't fail if IB and Ethernet devices 'collide' (#1411)
 - Use cc_* module meta defintion over hardcoded vars (SC-888) (#1385)
 - Fix cc_rsyslog.py initialization (#1404) [Alberto Contreras]
 - Promote cloud-init schema from devel to top level subcommand (#1402)
 - mypy: disable missing imports warning for httpretty (#1412)
   [Chris Patterson]
 - users: error when home should not be created AND ssh keys provided
   [Jeffrey 'jf' Lim]
 - Allow growpart to resize encrypted partitions (#1316)
 - Fix typo in integration_test.rst (#1405) [Alberto Contreras]
 - cloudinit.net refactor: apply_network_config_names (#1388)
   [Alberto Contreras] (GH: #1884602)
 - tests/azure: add fixtures for hardcoded paths (markers and data_dir)
   (#1399) [Chris Patterson]
 - testing: Add responses workaround for focal/impish (#1403)
 - cc_ssh_import_id: fix is_key_in_nested_dict to avoid early False
 - Fix ds-identify not detecting NoCloud seed in config (#1381)
   (GH: #1876375)
 - sources/azure: retry dhcp for failed processes (#1401) [Chris Patterson]
 - Move notes about refactorization out of CONTRIBUTING.rst (#1389)
 - Shave ~8ms off generator runtime (#1387)
 - Fix provisioning dhcp timeout to 20 minutes (#1394) [Chris Patterson]
 - schema: module example strict testing fix seed_random
 - cc_set_hostname: examples small typo (perserve vs preserve)
   [Wouter Schoot]
 - sources/azure: refactor http_with_retries to remove **kwargs (#1392)
   [Chris Patterson]
 - declare dependency on ssh-import-id (#1334)
 - drop references to old dependencies and old centos script
 - sources/azure: only wait for primary nic to be attached during restore
   (#1378) [Anh Vo]
 - cc_ntp: migrated legacy schema to cloud-init-schema.json (#1384)
   (GH: SC-803)
 - Network functions refactor and bugfixes (#1383)
 - schema: add JSON defs for modules cc_users_groups (#1379)
   (GH: SC-928, SC-846, SC-897, #1858930)
 - Fix doc typo (#1382) [Alberto Contreras]
 - Add support for dual stack IPv6/IPv4 IMDS to Ec2 (#1160)
 - Fix KeyError when rendering sysconfig IPv6 routes (#1380) (GH: #1958506)
 - Return a namedtuple from subp() (#1376)
 - Mypy stubs and other tox maintenance (SC-920) (#1374)
 - Distro Compatibility Fixes (#1375)
 - Pull 

[Yahoo-eng-team] [Bug 1969526] Re: cc-ssh: traceback when openssh-server absent

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1969526

Title:
  cc-ssh: traceback when openssh-server absent

Status in cloud-init:
  Fix Released

Bug description:
  In minimal cloud images without openssh-server, cloud-init will get
  the following traceback when the following cloud-config is provided:

  ```
  #cloud-config
  ssh_pwauth: true
  ```

  2022-04-19 20:42:32,593 - stages.py[DEBUG]: Running module set-passwords 
() with 
frequency once-per-instance
  2022-04-19 20:42:32,593 - handlers.py[DEBUG]: start: 
modules-config/config-set-passwords: running config-set-passwords with 
frequency once-per-instance
  2022-04-19 20:42:32,593 - util.py[DEBUG]: Writing to 
/var/lib/cloud/instances/rocky-8/sem/config_set_passwords - wb: [644] 24 bytes
  2022-04-19 20:42:32,593 - helpers.py[DEBUG]: Running config-set-passwords 
using lock ()
  2022-04-19 20:42:32,594 - ssh_util.py[DEBUG]: line 1: option 
PasswordAuthentication added with no
  2022-04-19 20:42:32,594 - util.py[DEBUG]: Writing to /etc/ssh/sshd_config - 
wb: [644] 26 bytes
  2022-04-19 20:42:32,594 - subp.py[DEBUG]: Running command ['service', 'sshd', 
'restart'] with allowed return codes [0] (shell=False, capture=True)
  2022-04-19 20:42:32,620 - handlers.py[DEBUG]: finish: 
modules-config/config-set-passwords: FAIL: running config-set-passwords with 
frequency once-per-instance
  2022-04-19 20:42:32,621 - util.py[WARNING]: Running module set-passwords 
() failed
  2022-04-19 20:42:32,621 - util.py[DEBUG]: Running module set-passwords 
() failed
  Traceback (most recent call last):
    File "/usr/lib/python3.6/site-packages/cloudinit/stages.py", line 876, in 
_run_modules
  freq=freq)
    File "/usr/lib/python3.6/site-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
    File "/usr/lib/python3.6/site-packages/cloudinit/helpers.py", line 185, in 
run
  results = functor(*args)
    File 
"/usr/lib/python3.6/site-packages/cloudinit/config/cc_set_passwords.py", line 
234, in handle
  service_name=cloud.distro.get_option('ssh_svcname', 'ssh'))
    File 
"/usr/lib/python3.6/site-packages/cloudinit/config/cc_set_passwords.py", line 
131, in handle_ssh_pwauth
  subp.subp(cmd)
    File "/usr/lib/python3.6/site-packages/cloudinit/subp.py", line 295, in subp
  cmd=args)
  cloudinit.subp.ProcessExecutionError: Unexpected error while running command.
  Command: ['service', 'sshd', 'restart']
  Exit code: 5
  Reason: -
  Stdout:
  Stderr: Redirecting to /bin/systemctl restart sshd.service
  Failed to restart sshd.service: Unit sshd.service not found.

  While one could argue that cloud images without openssh-server might
  have limited utility, there are use cases for slim apps/micro-services
  that may not rely on this stack and cloud-init should probably cope
  better in the face of this missing dependency.

  While working this issue, let's add a Suggests: openssh-server to
  debian/control for Deb-based systems.


  
  --- Steps to reproduce problem
  cat > ssh_needed.yaml << EOF
  #cloud-config
  ssh_pwauth: true
  EOF

  lxc launch ubuntu-daily:focal f1 -c user.user-data="$(cat ssh_needed.yaml)" 
  lxc exec f1 -- cloud-init status --wait
  lxc exec f1 apt remove opensssh-server
  # reset PasswordAuthentication off again so that cloud-init wants to reset 
ssh server
  lxc exec f1 --  sed -i 's/PasswordAuthentication yes/PasswordAuthentication 
no/' /etc/ssh/sshd_config
  # force clean reboot so cloud-init reruns
  lxc exec f1 -- cloud-init clean --logs --reboot
  lxc exec f1 -- cloud-init status --wait --long

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1969526/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1876341] Re: Broken analyze link in CLI page

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1876341

Title:
  Broken analyze link in CLI page

Status in cloud-init:
  Fix Released

Bug description:
  In the first sentence of the Analyze section of the CLI docs:
  https://cloudinit.readthedocs.io/en/latest/topics/cli.html#analyze

  ...there is a link that should point to this top-level document on the
  behavior of Analyze:
  https://cloudinit.readthedocs.io/en/latest/topics/analyze.html

  Instead it points to the cli_analyze label within the CLI page. There
  are some warnings in the docs build about duplicate labels which seem
  related -- but merely changing the label name did not resolve the
  issue for me.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1876341/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1958506] Re: KeyError: 'NETMASK2'

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1958506

Title:
  KeyError: 'NETMASK2'

Status in cloud-init:
  Fix Released

Bug description:
  cat /etc/os-release
  NAME="AlmaLinux"
  VERSION="8.5 (Arctic Sphynx)"
  ID="almalinux"
  ID_LIKE="rhel centos fedora"
  VERSION_ID="8.5"
  PLATFORM_ID="platform:el8"
  PRETTY_NAME="AlmaLinux 8.5 (Arctic Sphynx)"
  ANSI_COLOR="0;34"
  CPE_NAME="cpe:/o:almalinux:almalinux:8::baseos"
  HOME_URL="https://almalinux.org/";
  DOCUMENTATION_URL="https://wiki.almalinux.org/";
  BUG_REPORT_URL="https://bugs.almalinux.org/";

  ALMALINUX_MANTISBT_PROJECT="AlmaLinux-8"
  ALMALINUX_MANTISBT_PROJECT_VERSION="8.5"

  rpm -qa | grep cloud-init
  cloud-init-21.1-7.el8_5.3.alma.noarch

  cloud-init status -w

  status: error

  2022-01-20 08:12:51,021 - subp.py[DEBUG]: Running command ['ip', '-6', 
'addr', 'show', 'permanent', 'scope', 'global'] with allowed return codes [0] 
(shell=False, capture=True)
  2022-01-20 08:12:51,039 - subp.py[DEBUG]: Running command ['ip', '-4', 
'addr', 'show'] with allowed return codes [0] (shell=False, capture=True)
  2022-01-20 08:12:51,052 - __init__.py[DEBUG]: achieving renaming of 
[['52:54:00:27:b0:7a', 'eth0', None, None]] with ops [('rename', 
'52:54:00:27:b0:7a', 'eth0', ('ens3', 'eth0'))]
  2022-01-20 08:12:51,052 - subp.py[DEBUG]: Running command ['ip', 'link', 
'set', 'ens3', 'name', 'eth0'] with allowed return codes [0] (shell=False, 
capture=True)
  2022-01-20 08:12:51,068 - stages.py[INFO]: Applying network configuration 
from ds bringup=False: {'version': 2, 'ethernets': {'eth0': {'set-name': 
'eth0', 'mtu': 1400, 'match': {'macaddress': '52:54:00:27:b0:7a'
  }, 'addresses': ['10.54.2.35/21', '2a00:1730:fff9:100::5e/128'], 'gateway4': 
'10.54.0.1', 'gateway6': '2a00:1730:fff9:100::1', 'routes': [{'to': 
'10.54.0.1/32', 'via': '0.0.0.0', 'scope': 'link'}, {'to': '0.0.0.
  0/0', 'via': '10.54.0.1', 'scope': 'link'}, {'to': 
'2a00:1730:fff9:100::1/128', 'via': '::0', 'scope': 'link'}, {'to': '::0/0', 
'via': '2a00:1730:fff9:100::1', 'scope': 'link'}], 'nameservers': {'addresses': 
['1
  0.52.1.1', '10.52.1.71', '2001:4860:4860::', '2001:4860:4860::8844']
  2022-01-20 08:12:51,069 - __init__.py[DEBUG]: Selected renderer 'sysconfig' 
from priority list: None
  2022-01-20 08:12:51,069 - network_state.py[DEBUG]: v2(ethernets) -> 
v1(physical):
  {'type': 'physical', 'name': 'eth0', 'mac_address': '52:54:00:27:b0:7a', 
'mtu': 1400, 'match': {'macaddress': '52:54:00:27:b0:7a'}, 'subnets': [{'type': 
'static', 'address': '10.54.2.35/21', 'gateway': '10.54.0.
  1', 'dns_nameservers': ['10.52.1.1', '10.52.1.71', '2001:4860:4860::', 
'2001:4860:4860::8844'], 'routes': [{'gateway': '0.0.0.0', 'network': 
'10.54.0.1', 'prefix': 32, 'netmask': '255.255.255.255'}, {'gatewa
  y': '10.54.0.1', 'network': '0.0.0.0', 'prefix': 0, 'netmask': '0.0.0.0'}, 
{'gateway': '::0', 'network': '2a00:1730:fff9:100::1', 'prefix': 128}, 
{'gateway': '2a00:1730:fff9:100::1', 'network': '::0', 'prefix':
  0}]}, {'type': 'static', 'address': '2a00:1730:fff9:100::5e/128', 'gateway': 
'2a00:1730:fff9:100::1'}]}
  2022-01-20 08:12:51,084 - network_state.py[DEBUG]: v2_common: handling config:
  {'eth0': {'set-name': 'eth0', 'mtu': 1400, 'match': {'macaddress': 
'52:54:00:27:b0:7a'}, 'addresses': ['10.54.2.35/21', 
'2a00:1730:fff9:100::5e/128'], 'gateway4': '10.54.0.1', 'gateway6': 
'2a00:1730:fff9:100::1'
  , 'routes': [{'to': '10.54.0.1/32', 'via': '0.0.0.0', 'scope': 'link'}, 
{'to': '0.0.0.0/0', 'via': '10.54.0.1', 'scope': 'link'}, {'to': 
'2a00:1730:fff9:100::1/128', 'via': '::0', 'scope': 'link'}, {'to': '::0/0
  ', 'via': '2a00:1730:fff9:100::1', 'scope': 'link'}], 'nameservers': 
{'addresses': ['10.52.1.1', '10.52.1.71', '2001:4860:4860::', 
'2001:4860:4860::8844']}}}
  2022-01-20 08:12:51,085 - sysconfig.py[DEBUG]: eth0 has 4 entries in 
dns_nameservers. Only 3 are used.
  2022-01-20 08:12:51,095 - util.py[WARNING]: failed stage init-local
  2022-01-20 08:12:51,100 - util.py[DEBUG]: failed stage init-local
  Traceback (most recent call last):
    File "/usr/lib/python3.6/site-packages/cloudinit/cmd/main.py", line 652, in 
status_wrapper
  ret = functor(name, args)
    File "/usr/lib/python3.6/site-packages/cloudinit/cmd/main.py", line 361, in 
main_init
  init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL))
    File "/usr/lib/python3.6/site-packages/cloudinit/stages.py", line 735, in 
apply_network_config
  return self.distro.apply_network_config(netcfg, bring_up=bring_up)
    File "/usr/lib/python3.6/site-packages/cloudinit/distros/__init__.py", line 
206, in apply_network_confi

[Yahoo-eng-team] [Bug 1858931] Re: schema: add jsonschema definition to cc_write_files

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1858931

Title:
  schema: add jsonschema definition to cc_write_files

Status in cloud-init:
  Fix Released

Bug description:
  Add initial jsonschema definition for validation of cloud-config
  user data to cloudinit/config/cc_write_files.py.

  Add a schema dictionary to the cc_*.py module which describes allowed
  cloud-config properties which are honored by the module.

  
  jsonschema support for a cloud-config module should entail:
   - module-level schema dict definition in cc_*py
 - schema should contain the keys:
   id, name, title, description, distros, examples, frequency, type,
   properties
   - handler should call validate_cloudconfig_schema(cfg, schema) if valid
 top-level config module keys are provided

  Good examples are:
  - cloudinit/config/cc_runcmd.py
  - cloudinit/config/cc_ubuntu_drivers.py
  - cloudinit/config/cc_zypper_add_repo.py
  - cloudinit/config/cc_ntp.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1858931/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1858902] Re: schema: add jsonschema definition to cc_lxd

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1858902

Title:
  schema: add jsonschema definition to cc_lxd

Status in cloud-init:
  Fix Released

Bug description:
  Add initial jsonschema definition for validation of cloud-config
  user data to cloudinit/config/cc_lxd.py.

  Add a schema dictionary to the cc_*.py module which describes allowed
  cloud-config properties which are honored by the module.

  
  jsonschema support for a cloud-config module should entail:
   - module-level schema dict definition in cc_*py
 - schema should contain the keys:
   id, name, title, description, distros, examples, frequency, type,
   properties
   - handler should call validate_cloudconfig_schema(cfg, schema) if valid
 top-level config module keys are provided

  Good examples are:
  - cloudinit/config/cc_runcmd.py
  - cloudinit/config/cc_ubuntu_drivers.py
  - cloudinit/config/cc_zypper_add_repo.py
  - cloudinit/config/cc_ntp.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1858902/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1884602] Re: cloudinit.net refactor: apply_network_config_names

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1884602

Title:
  cloudinit.net refactor: apply_network_config_names

Status in cloud-init:
  Fix Released

Bug description:
  This bug is tracking part of the refactor of cloudinit.net into
  cloudinit.distros.networking, specifically the refactoring of the function
  named in the title of this bug.  See [0] for further details.

  [0]
  https://cloudinit.readthedocs.io/en/latest/topics/hacking.html#cloudinit-
  net-cloudinit-distros-networking-hierarchy

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1884602/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1858932] Re: schema: add jsonschema definition to cc_yum_add_repo

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1858932

Title:
  schema: add jsonschema definition to cc_yum_add_repo

Status in cloud-init:
  Fix Released

Bug description:
  Add initial jsonschema definition for validation of cloud-config
  user data to cloudinit/config/cc_yum_add_repo.py.

  Add a schema dictionary to the cc_*.py module which describes allowed
  cloud-config properties which are honored by the module.

  
  jsonschema support for a cloud-config module should entail:
   - module-level schema dict definition in cc_*py
 - schema should contain the keys:
   id, name, title, description, distros, examples, frequency, type,
   properties
   - handler should call validate_cloudconfig_schema(cfg, schema) if valid
 top-level config module keys are provided

  Good examples are:
  - cloudinit/config/cc_runcmd.py
  - cloudinit/config/cc_ubuntu_drivers.py
  - cloudinit/config/cc_zypper_add_repo.py
  - cloudinit/config/cc_ntp.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1858932/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1858928] Re: schema: add jsonschema definition to cc_update_etc_hosts

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1858928

Title:
  schema: add jsonschema definition to cc_update_etc_hosts

Status in cloud-init:
  Fix Released

Bug description:
  Add initial jsonschema definition for validation of cloud-config
  user data to cloudinit/config/cc_update_etc_hosts.py.

  Add a schema dictionary to the cc_*.py module which describes allowed
  cloud-config properties which are honored by the module.

  
  jsonschema support for a cloud-config module should entail:
   - module-level schema dict definition in cc_*py
 - schema should contain the keys:
   id, name, title, description, distros, examples, frequency, type,
   properties
   - handler should call validate_cloudconfig_schema(cfg, schema) if valid
 top-level config module keys are provided

  Good examples are:
  - cloudinit/config/cc_runcmd.py
  - cloudinit/config/cc_ubuntu_drivers.py
  - cloudinit/config/cc_zypper_add_repo.py
  - cloudinit/config/cc_ntp.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1858928/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1858901] Re: schema: add jsonschema definition to cc_locale

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1858901

Title:
  schema: add jsonschema definition to cc_locale

Status in cloud-init:
  Fix Released

Bug description:
  Add initial jsonschema definition for validation of cloud-config
  user data to cloudinit/config/cc_locale.py.

  Add a schema dictionary to the cc_*.py module which describes allowed
  cloud-config properties which are honored by the module.

  
  jsonschema support for a cloud-config module should entail:
   - module-level schema dict definition in cc_*py
 - schema should contain the keys:
   id, name, title, description, distros, examples, frequency, type,
   properties
   - handler should call validate_cloudconfig_schema(cfg, schema) if valid
 top-level config module keys are provided

  Good examples are:
  - cloudinit/config/cc_runcmd.py
  - cloudinit/config/cc_ubuntu_drivers.py
  - cloudinit/config/cc_zypper_add_repo.py
  - cloudinit/config/cc_ntp.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1858901/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1858930] Re: schema: add jsonschema definition to cc_users_groups

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1858930

Title:
  schema: add jsonschema definition to cc_users_groups

Status in cloud-init:
  Fix Released

Bug description:
  Add initial jsonschema definition for validation of cloud-config
  user data to cloudinit/config/cc_users_groups.py.

  Add a schema dictionary to the cc_*.py module which describes allowed
  cloud-config properties which are honored by the module.

  
  jsonschema support for a cloud-config module should entail:
   - module-level schema dict definition in cc_*py
 - schema should contain the keys:
   id, name, title, description, distros, examples, frequency, type,
   properties
   - handler should call validate_cloudconfig_schema(cfg, schema) if valid
 top-level config module keys are provided

  Good examples are:
  - cloudinit/config/cc_runcmd.py
  - cloudinit/config/cc_ubuntu_drivers.py
  - cloudinit/config/cc_zypper_add_repo.py
  - cloudinit/config/cc_ntp.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1858930/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1858899] Re: schema: add jsonschema definition to cc_keys_to_console

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1858899

Title:
  schema: add jsonschema definition to cc_keys_to_console

Status in cloud-init:
  Fix Released

Bug description:
  Add initial jsonschema definition for validation of cloud-config
  user data to cloudinit/config/cc_keys_to_console.py.

  Add a schema dictionary to the cc_*.py module which describes allowed
  cloud-config properties which are honored by the module.

  
  jsonschema support for a cloud-config module should entail:
   - module-level schema dict definition in cc_*py
 - schema should contain the keys:
   id, name, title, description, distros, examples, frequency, type,
   properties
   - handler should call validate_cloudconfig_schema(cfg, schema) if valid
 top-level config module keys are provided

  Good examples are:
  - cloudinit/config/cc_runcmd.py
  - cloudinit/config/cc_ubuntu_drivers.py
  - cloudinit/config/cc_zypper_add_repo.py
  - cloudinit/config/cc_ntp.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1858899/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1906187] Re: Top-level 'network' key results in error using v2 config

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1906187

Title:
  Top-level 'network' key results in error using v2 config

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Committed
Status in netplan.io package in Ubuntu:
  Invalid

Bug description:
  I've created a 'network-config' file with Terraform's yamldecode() function 
that contains (btw. I've tried with the version being a Number w/o quotes and 
as well as a String as shown here):
  ---
  "network":
    "ethernets":
  "eth0":
    "gateway4": "192.168.1.1"
    "nameservers":
  "addresses":
  - "192.168.1.74"
  - "192.168.1.104"
  "search":
  - "fritz.box"
    "set-name": "eth0"
    "version": "2"
  ---
  After running on Raspberry Pi 4B with 4 GB, created with 
ubuntu-20.04.1-preinstalled-server-arm64+raspi.img.xz, the machine's setup 
fails and /var/log/cloud-init.log reveals that:
  ---
  2020-04-01 17:23:48,649 - util.py[DEBUG]: Reading from 
/boot/firmware//network-config (quiet=False)
  2020-04-01 17:23:48,649 - util.py[DEBUG]: Read 245 bytes from 
/boot/firmware//network-config
  2020-04-01 17:23:48,650 - util.py[DEBUG]: Attempting to load yaml from string 
of length 240 with allowed root types (,)
  2020-04-01 17:23:48,652 - util.py[DEBUG]: Attempting to load yaml from string 
of length 245 with allowed root types (,)
  2020-04-01 17:23:48,656 - DataSourceNoCloud.py[DEBUG]: Top level network key 
in network-config but missing 'config' or 'version': {'network': {'ethernets': 
{'eth0': {'gateway4': '192.168.1.1', 'nameservers': {'addresses': 
['192.168.1.74', '192.168.1.104'], 'search': ['fritz.box']}, 'set-name': 
'eth0'}}, 'version': '2'}}
  ---
  The corresponding /var/log/clout-init-output.log reveals the trace and that 
Network won't come up.
  ---
  Cloud-init v. 20.2-45-g5f7825e2-0ubuntu1~20.04.1 running 'init-local' at Wed, 
01 Apr 2020 17:23:48 +. Up 21.71 seconds.
  2020-04-01 17:23:48,796 - util.py[WARNING]: failed stage init-local
  failed run of stage init-local
  
  Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 653, in 
status_wrapper
  ret = functor(name, args)
    File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 362, in 
main_init
  init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL))
    File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 699, in 
apply_network_config
  net.wait_for_physdevs(netcfg)
    File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 523, 
in wait_for_physdevs
  physdevs = extract_physdevs(netcfg)
    File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 519, 
in extract_physdevs
  raise RuntimeError('Unknown network config version: %s' % version)
  RuntimeError: Unknown network config version: None
  
  Cloud-init v. 20.2-45-g5f7825e2-0ubuntu1~20.04.1 running 'init' at Wed, 01 
Apr 2020 17:23:50 +. Up 23.69 seconds.
  ci-info: +++Net device 
info
  ci-info: 
++---+---+---+---+---+
  ci-info: | Device |   Up  |  Address  |Mask   | Scope | Hw-Address
|
  ci-info: 
++---+---+---+---+---+
  ci-info: |  eth0  | False | . | . |   .   | dc:a6:32:b1:78:8e 
|
  ci-info: |   lo   |  True | 127.0.0.1 | 255.0.0.0 |  host | . 
|
  ci-info: |   lo   |  True |  ::1/128  | . |  host | . 
|
  ci-info: | wlan0  | False | . | . |   .   | dc:a6:32:b1:78:8f 
|
  ci-info: 
++---+---+---+---+---+
  ci-info: +++Route IPv6 info+++
  ci-info: +---+-+-+---+---+
  ci-info: | Route | Destination | Gateway | Interface | Flags |
  ci-info: +---+-+-+---+---+
  ci-info: +---+-+-+---+---+
  2020-04-01 17:23:50,653 - stages.py[WARNING]: Failed to rename devices: 
Failed to apply network config names: Unknown network config version: None

  
  Related bugs:
   * bug 1798117: juju sends "network" top level key to user.network-config in 
lxd containers

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1906187/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-te

[Yahoo-eng-team] [Bug 1962759] Re: jinja-template doesn't support 'do' extension.

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1962759

Title:
  jinja-template doesn't support 'do' extension.

Status in cloud-init:
  Fix Released

Bug description:
  example user-data file with jinja

  ## template: jinja
  #!/bin/sh

  {% set data_result = [] %}
  {% set data_input = [1,2,3] %}
  {% for i in data_input %}
{% do data_result.append(i) %}
  {% endfor %}
  echo results: {{data_result}} >>results.out

  
  The following exception is thrown when using jinja2 'do' statement.

  jinja2.exceptions.TemplateSyntaxError: Encountered unknown tag 'do'.
  Jinja was looking for the following tags: 'endfor' or 'else'. The
  innermost block that needs to be closed is 'for'.

  I'm using cloud-init from a 64bitencoded file passed into terraform
  azure provider custom_data.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1962759/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1953430] Re: cloud-init query traceback on root read-only etc/cloud/cloud.cfg.d/ files

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1953430

Title:
  cloud-init query traceback on root read-only etc/cloud/cloud.cfg.d/
  files

Status in cloud-init:
  Fix Released

Bug description:
  If any files are root read-only in /etc/cloud/cloud.cfg.d cloud-init query 
tracebacks for non-root user
  cloud-init version: 21.4

  Reproducible on Jammy Desktop installer images

  csmith@csmith-Standard-PC-i440FX-PIIX-1996:~$ cloud-init query --all
  Traceback (most recent call last):
    File "/usr/bin/cloud-init", line 33, in 
  sys.exit(load_entry_point('cloud-init==21.4', 'console_scripts', 
'cloud-init')())
    File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 927, in 
main
  retval = util.log_time(
    File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2472, in 
log_time
  ret = func(*args, **kwargs)
    File "/usr/lib/python3/dist-packages/cloudinit/cmd/query.py", line 109, in 
handle_args
  paths = read_cfg_paths()
    File "/usr/lib/python3/dist-packages/cloudinit/cmd/devel/__init__.py", line 
22, in read_cfg_paths
  init.read_cfg()
    File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 229, in 
read_cfg
  self._cfg = self._read_cfg(extra_fns)
    File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 237, in 
_read_cfg
  base_cfg=fetch_base_config())
    File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 1049, in 
fetch_base_config
  util.read_conf_with_confd(CLOUD_CONFIG),
    File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 950, in 
read_conf_with_confd
  confd_cfg = read_conf_d(confd)
    File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 925, in 
read_conf_d
  cfgs.append(read_conf(os.path.join(confd, fn)))
    File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 271, in 
read_conf
  return load_yaml(load_file(fname), default={})
    File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1361, in 
load_file
  with open(fname, 'rb') as ifh:
  PermissionError: [Errno 13] Permission denied: 
'/etc/cloud/cloud.cfg.d/99-installer.cfg'

  # works fine for root user
  csmith@csmith-Standard-PC-i440FX-PIIX-1996:~$ sudo cloud-init query --all
  [sudo] password for csmith:
  {
   "_beta_keys": [
    "subplatform"
   ],
   "availability_zone": null,
   "base64_encoded_keys": [],
   "cloud_name": "none",
   "distro": "ubuntu",
   "distro_release": "jammy",
   "distro_version": "22.04",
   "ds": {
    "_doc": "EXPERIMENTAL: The structure and format of content scoped under the 
'ds' key may change in subsequent releases of cloud-init.",
    "meta_data": {
     "instance_id": "fd598361-12e8-41e0-a7eb-7c9f2d7d3b41"
    }
   },
   "instance_id": "iid-datasource-none",
   "kernel_release": "5.13.0-19-generic",
   "local_hostname": "csmith-Standard-PC-i440FX-PIIX-1996",
   "machine": "x86_64",
   "merged_cfg": {
    "_doc": "Merged cloud-init system config from /etc/cloud/cloud.cfg and 
/etc/cloud/cloud.cfg.d/",
    "_log": [
     
"[loggers]\nkeys=root,cloudinit\n\n[handlers]\nkeys=consoleHandler,cloudLogHandler\n\n[formatters]\nkeys=simpleFormatter,arg0Formatter\n\n[logger_root]\nlevel=DEBUG\nhandlers=consoleHandler,cloudLogHandler\n\n[logger_cloudinit]\nlevel=DEBUG\nqualname=cloudinit\nhandlers=\npropagate=1\n\n[handler_consoleHandler]\nclass=StreamHandler\nlevel=WARNING\nformatter=arg0Formatter\nargs=(sys.stderr,)\n\n[formatter_arg0Formatter]\nformat=%(asctime)s
 - %(filename)s[%(levelname)s]: 
%(message)s\n\n[formatter_simpleFormatter]\nformat=[CLOUDINIT] 
%(filename)s[%(levelname)s]: %(message)s\n",
     
"[handler_cloudLogHandler]\nclass=FileHandler\nlevel=DEBUG\nformatter=arg0Formatter\nargs=('/var/log/cloud-init.log',
 'a', 'UTF-8')\n",
     
"[handler_cloudLogHandler]\nclass=handlers.SysLogHandler\nlevel=DEBUG\nformatter=simpleFormatter\nargs=(\"/dev/log\",
 handlers.SysLogHandler.LOG_USER)\n"
    ],
    "apt": {
     "preserve_sources_list": true
    },
    "cloud_config_modules": [
     "emit_upstart",
     "snap",
     "ssh-import-id",
     "locale",
     "set-passwords",
     "grub-dpkg",
     "apt-pipelining",
     "apt-configure",
     "ubuntu-advantage",
     "ntp",
     "timezone",
     "disable-ec2-metadata",
     "runcmd",
     "byobu"
    ],
    "cloud_final_modules": [
     "package-update-upgrade-install",
     "fan",
     "landscape",
     "lxd",
     "ubuntu-drivers",
     "write-files-deferred",
     "puppet",
     "chef",
     "mcollective",
     "salt-minion",
     "reset_rmc",
     "refresh_rmc_and_interface",
     "rightscale_userdata",
     "scripts-vendor",
     "scripts-per-once",
     "scripts-

[Yahoo-eng-team] [Bug 1858900] Re: schema: add jsonschema definition to cc_landscape

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1858900

Title:
  schema: add jsonschema definition to cc_landscape

Status in cloud-init:
  Fix Released

Bug description:
  Add initial jsonschema definition for validation of cloud-config
  user data to cloudinit/config/cc_landscape.py.

  Add a schema dictionary to the cc_*.py module which describes allowed
  cloud-config properties which are honored by the module.

  
  jsonschema support for a cloud-config module should entail:
   - module-level schema dict definition in cc_*py
 - schema should contain the keys:
   id, name, title, description, distros, examples, frequency, type,
   properties
   - handler should call validate_cloudconfig_schema(cfg, schema) if valid
 top-level config module keys are provided

  Good examples are:
  - cloudinit/config/cc_runcmd.py
  - cloudinit/config/cc_ubuntu_drivers.py
  - cloudinit/config/cc_zypper_add_repo.py
  - cloudinit/config/cc_ntp.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1858900/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1855945] Re: Network Config Version 2 Device Configuration ID used as interface name when set-name is not specified

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1855945

Title:
  Network Config Version 2 Device Configuration ID used as interface
  name when set-name is not specified

Status in cloud-init:
  Fix Released

Bug description:
  With Cloud-Init Network Config Version 2, the name of Device
  Configuration ID object is overwriting the ethernet interface device
  name when set-name is not specified.

  Example - Version 2 metadata:

  instance-id: "management-cluster-controlplane-0"
  network:
version: 2
ethernets:
  id0:
match:
  macaddress: "00:50:56:a5:1a:78"

  When 'set-name' is not defined within the version 2 config, then
  cloud-init network_state.py retrieves the name of the ethernet dict.
  In the above case it would be "id0":

  
  network_state.py code 
[https://github.com/canonical/cloud-init/blob/ec6924ea1d321cc87e7414bee7734074590045b8/cloudinit/net/network_state.py#L645]

  for eth, cfg in command.items():
  phy_cmd = {
  'type': 'physical',
  'name': cfg.get('set-name', eth),
  }

  
  See debug output where set-name is not specified and the ethernet device 
config id = id0:

  2019-12-05 01:50:14,692 - network_state.py[DEBUG]: v2(ethernets) -> 
v1(physical):
  {'subnets': [{'dns_nameservers': ['10.10.10.10'], 'type': 'static', 
'gateway': '10.7.7.254', 'address': '10.7.5.102/21'}], 'name': 'id0', 
'mac_address': '00:50:56:a5:75:b3', 'type': 'physical', 'wakeonlan': True, 
'match': {'macaddress': '00:50:56:a5:75:b3'}}

  
  Within CentOS the sysconfig renderer then later uses this Device Config ID 
for the /etc/sysconfig/network-scripts/ifcfg- name and the DEVICE= parameter.

  sysconfig.py code [https://github.com/canonical/cloud-
  
init/blob/ec6924ea1d321cc87e7414bee7734074590045b8/cloudinit/net/sysconfig.py#L701-L702]


  cloud-init.log - without set-name configured:

  
  2019-12-05 21:11:38,913 - stages.py[DEBUG]: Using distro class 
  2019-12-05 21:11:38,914 - __init__.py[DEBUG]: no interfaces to rename
  2019-12-05 21:11:38,914 - __init__.py[DEBUG]: Datasource 
DataSourceVMwareGuestInfo not updated for events: System boot
  2019-12-05 21:11:38,914 - stages.py[DEBUG]: No network config applied. 
Neither a new instance nor datasource network update on 'System boot' event
  2019-12-05 21:11:38,914 - handlers.py[DEBUG]: start: 
init-network/setup-datasource: setting up datasource
  2019-12-05 21:11:38,914 - DataSourceVMwareGuestInfo.py[INFO]: got host-info: 
{'network': {'interfaces': {'by-mac': OrderedDict([('00:50:56:a5:b2:b2', 
{'ipv6': [{'addr': 'fe80::250:56ff:fea5:b2b2%eth0', 'netmask': 
':::::/64'}]})]), 'by-ipv4': OrderedDict(), 'by-ipv6': 
OrderedDict([('fe80::250:56ff:fea5:b2b2%eth0', {'netmask': 
':::::/64', 'mac': '00:50:56:a5:b2:b2'})])}}, 'hostname': 
'localhost', 'local-hostname': 'localhost'}


  cloud-init.log - with set-name: eth0 configured:

  2019-12-05 21:57:19,179 - util.py[DEBUG]: Running command ['ip', '-6', 
'addr', 'show', 'permanent', 'scope', 'global'] with allowed return codes [0] 
(shell=False, capture=True)
  2019-12-05 21:57:19,190 - util.py[DEBUG]: Running command ['ip', '-4', 
'addr', 'show'] with allowed return codes [0] (shell=False, capture=True)
  2019-12-05 21:57:19,198 - __init__.py[DEBUG]: no work necessary for renaming 
of [['00:50:56:a5:b2:b2', 'eth0', 'vmxnet3', '0x07b0']]
  2019-12-05 21:57:19,198 - stages.py[INFO]: Applying network configuration 
from system_cfg bringup=False: {'version': 2, 'ethernets': {'id0': {'match': 
{'macaddress': '00:50:56:a5:b2:b2'}, 'wakeonlan': True, 'set-name': 'eth0', 
'dhcp4': False, 'dhcp6': False, 'addresses': ['10.7.5.101/21'], 'gateway4': 
'10.7.7.254', 'nameservers': {'addresses': ['10.10.10.10']
  2019-12-05 21:57:19,199 - __init__.py[WARNING]: apply_network_config is not 
currently implemented for distribution ''.  Attempting to use apply_network
  2019-12-05 21:57:19,199 - network_state.py[DEBUG]: v2(ethernets) -> 
v1(physical):
  {'type': 'physical', 'name': 'eth0', 'mac_address': '00:50:56:a5:b2:b2', 
'match': {'macaddress': '00:50:56:a5:b2:b2'}, 'wakeonlan': True, 'subnets': 
[{'type': 'static', 'address': '10.7.5.101/21', 'gateway': '10.7.7.254', 
'dns_nameservers': ['10.10.10.10']}]}
  2019-12-05 21:57:19,206 - network_state.py[DEBUG]: v2_common: handling config:
  {'id0': {'match': {'macaddress': '00:50:56:a5:b2:b2'}, 'wakeonlan': True, 
'set-name': 'eth0', 'dhcp4': False, 'dhcp6': False, 'addresses': 
['10.7.5.101/21'], 'gateway4': '10.7.7.254', 'nameservers': {'addresses': 
['10.10.10.10']}}}
  2019-12-05 21:57:19,207 - photon.py[DEBUG

[Yahoo-eng-team] [Bug 1874875] Re: cloudinit.sources.NetworkConfigSource can be refactored to an enum

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1874875

Title:
  cloudinit.sources.NetworkConfigSource can be refactored to an enum

Status in cloud-init:
  Fix Released

Bug description:
  It is currently implemented as a namedtuple, because it was written
  when the codebase supported Python 2 (where using an enum would have
  introduced a new dependency).  As enum is in the stdlib in all our
  supported Python releases, we can now use it without that constraint.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1874875/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1876375] Re: ds-identify cannot detect seed defined in cfg file

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1876375

Title:
  ds-identify cannot detect seed defined in cfg file

Status in cloud-init:
  Fix Released

Bug description:
  Cloud-init version 20.1-10-g71af48df-0ubuntu5 from a core20 image
  I added a file called 98_nocloud.cfg that looks like this:
  --
  #cloud-config
  datasource_list: [ NoCloud, None ]
  datasource:
NoCloud:
  user-data: |
#cloud-config
users:
  - name: ubuntu
ssh-authorized-keys:
  - 
homedir: /home/ubuntu
sudo: ALL=(ALL) NOPASSWD:ALL
shell: /bin/bash

  meta-data: |
instance_id: cloud-image

  --

  == Reproducing ==
  1. create a usb stick, or kvm image for core20
  2. place the above file in the ubuntu-seed partition under 
/data/etc/cloud/cloud.cfg.d/98_nocloud.cfg
  =

  When I boot, the datasource is not used and cloud-init does not process it 
*unless* I also include this line at the top:
  datasource_list: [ NoCloud, None ]

  
  This was surprising though, because another existing file in 
/etc/cloud/cloud.cfg.d called 90_dpkg.cfg has these contents:
  # to update this file, run dpkg-reconfigure cloud-init
  datasource_list: [ NoCloud, ConfigDrive, OpenNebula, DigitalOcean, Azure, 
AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, SmartOS, Bigstep, Scaleway, 
AliYun, Ec2, CloudStack, Hetzner, IBMCloud, Oracle, Exoscale, RbxCloud, None ]

  
  Here are the contents of /run/cloud-init/ds_identify.log when it fails:
  [up 4.57s] ds-identify 
  policy loaded: mode=search report=false found=first maybe=none 
notfound=disabled
  /etc/cloud/cloud.cfg.d/90_dpkg.cfg set datasource_list: [ NoCloud, 
ConfigDrive, OpenNebula, DigitalOcean, Azure, AltCloud, OVF, MAAS, GCE, 
OpenStack, CloudSigma, SmartOS, Bigstep, Scaleway, AliYun, Ec2, CloudStack, 
Hetzner, IBMCloud, Oracle, Exoscale, RbxCloud, None ]
  DMI_PRODUCT_NAME=Standard PC (i440FX + PIIX, 1996)
  DMI_SYS_VENDOR=QEMU
  DMI_PRODUCT_SERIAL=
  DMI_PRODUCT_UUID=unavailable
  PID_1_PRODUCT_NAME=unavailable
  DMI_CHASSIS_ASSET_TAG=
  FS_LABELS=ubuntu-seed,ubuntu-boot,ubuntu-data
  ISO9660_DEVS=
  KERNEL_CMDLINE=snapd_recovery_mode=run console=ttyS0 console=tty1 panic=-1
  VIRT=kvm
  UNAME_KERNEL_NAME=Linux
  UNAME_KERNEL_RELEASE=5.4.0-26-generic
  UNAME_KERNEL_VERSION=#30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020
  UNAME_MACHINE=x86_64
  UNAME_NODENAME=ubuntu
  UNAME_OPERATING_SYSTEM=GNU/Linux
  DSNAME=
  DSLIST=NoCloud ConfigDrive OpenNebula DigitalOcean Azure AltCloud OVF MAAS 
GCE OpenStack CloudSigma SmartOS Bigstep Scaleway AliYun Ec2 CloudStack Hetzner 
IBMCloud Oracle Exoscale RbxCloud None
  MODE=search
  ON_FOUND=first
  ON_MAYBE=none
  ON_NOTFOUND=disabled
  pid=607 ppid=591
  is_container=false
  is_ds_enabled(IBMCloud) = true.
  is_ds_enabled(IBMCloud) = true.
  ec2 platform is 'Unknown'.
  No ds found [mode=search, notfound=disabled]. Disabled cloud-init [1]
  [up 4.76s] returning 1

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1876375/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1858929] Re: schema: add jsonschema definition to cc_update_hostname

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1858929

Title:
  schema: add jsonschema definition to cc_update_hostname

Status in cloud-init:
  Fix Released

Bug description:
  Add initial jsonschema definition for validation of cloud-config
  user data to cloudinit/config/cc_update_hostname.py.

  Add a schema dictionary to the cc_*.py module which describes allowed
  cloud-config properties which are honored by the module.

  
  jsonschema support for a cloud-config module should entail:
   - module-level schema dict definition in cc_*py
 - schema should contain the keys:
   id, name, title, description, distros, examples, frequency, type,
   properties
   - handler should call validate_cloudconfig_schema(cfg, schema) if valid
 top-level config module keys are provided

  Good examples are:
  - cloudinit/config/cc_runcmd.py
  - cloudinit/config/cc_ubuntu_drivers.py
  - cloudinit/config/cc_zypper_add_repo.py
  - cloudinit/config/cc_ntp.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1858929/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1977759] [NEW] VMware vs OVF Detection Bug

[Brett Holman]

Public bug reported:

Originally reported in IRC, there appears to be a bug in cloud detection
for VMware

** Affects: cloud-init
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1977759

Title:
  VMware vs OVF Detection Bug

Status in cloud-init:
  New

Bug description:
  Originally reported in IRC, there appears to be a bug in cloud
  detection for VMware

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1977759/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1978328] [NEW] setup.py is not PEP517 compliant

[Brett Holman]

Public bug reported:

A bug[1] was filed downstream for this, and reported upstream in #cloud-
init IRC by Sam (Gentoo maintainer).

This causes build failure on Gentoo/OpenRC, which is carrying a
downstream workaround[2] for now.

It looks like the upstream installation method for init scripts and
additional bits (non-Python files at all) isn't compatible with PEP517,
so PEP517 installs are broken right now.

PEP517 with the wheel spec doesn't have a good way of installing data
files.

[1] https://bugs.gentoo.org/850628
[2] 
https://github.com/gentoo/gentoo/commit/44cfdb3c49f7ebce1e66324ad5ac68285d8d08bb

** Affects: cloud-init
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1978328

Title:
  setup.py is not PEP517 compliant

Status in cloud-init:
  New

Bug description:
  A bug[1] was filed downstream for this, and reported upstream in
  #cloud-init IRC by Sam (Gentoo maintainer).

  This causes build failure on Gentoo/OpenRC, which is carrying a
  downstream workaround[2] for now.

  It looks like the upstream installation method for init scripts and
  additional bits (non-Python files at all) isn't compatible with
  PEP517, so PEP517 installs are broken right now.

  PEP517 with the wheel spec doesn't have a good way of installing data
  files.

  [1] https://bugs.gentoo.org/850628
  [2] 
https://github.com/gentoo/gentoo/commit/44cfdb3c49f7ebce1e66324ad5ac68285d8d08bb

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1978328/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1799544] Re: package-update-upgrade-install does not work on Gentoo

[Brett Holman]

** Changed in: cloud-init
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1799544

Title:
  package-update-upgrade-install does not work on Gentoo

Status in cloud-init:
  Fix Released

Bug description:
  I'm testing cloud-init in a nocloud setup. I'm trying to perform
  installation of packages using the appropriate module and after fixing
  some issues in Gentoo packaging, I hit an error in execution due to
  cmd = list('emerge') being interpreted as ['e', 'm', 'e', ...] while
  it was meant as ['emerge'].

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1799544/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1986703] [NEW] Release 22.3

[Brett Holman]

Public bug reported:

Summary: Release 22.3
Further information:
== Release Notes ==

Cloud-init release 22.3 is now available

The 22.3 release:
 * spanned about 3 months
 * had 25 contributors from 27 domains
 * fixed 18 Launchpad issues

Highlights:
  

== Changelog ==
 - integration tests: Ensure one setup for all tests (#1661)
 - tests: ansible test fixes (#1660)
 - Prevent concurrency issue in test_webhook_hander.py (#1658)
 - Workaround net_setup_link race with udev (#1655) (LP: #1983516)
 - test: drop erroneous lxd assertion, verify command succeeded (#1657)
 - Fix Chrony usage on Centos Stream (#1648) [Sven Haardiek] (LP: #1885952)
 - sources/azure: handle network unreachable errors for savable PPS (#1642)
   [Chris Patterson]
 - Return cc_set_hostname to PER_INSTANCE frequency (#1651) (LP: #1983811)
 - test: Collect integration test time by default (#1638)
 - test: Drop forced package install hack in lxd integration test (#1649)
 - schema: Resolve user-data if --system given (#1644)
   [Alberto Contreras] (LP: #1983306)
 - test: use fake filesystem to avoid file removal (#1647)
   [Alberto Contreras]
 - tox: Fix tip-flake8 and tip-mypy (#1635) [Alberto Contreras]
 - config: Add wireguard config module (#1570) [Fabian Lichtenegger-Lukas]
 - tests: can run without azure-cli, tests expect inactive ansible (#1643)
 - typing: Type UrlResponse.contents (#1633) [Alberto Contreras]
 - testing: fix references to `DEPRECATED.` (#1641) [Alberto Contreras]
 - ssh_util: Handle sshd_config.d folder [Alberto Contreras] (LP: #1968873)
 - schema: Enable deprecations in cc_update_etc_hosts (#1631)
   [Alberto Contreras]
 - Add Ansible Config Module (#1579)
 - util: Support Idle process state in get_proc_ppid() (#1637)
 - schema: Enable deprecations in cc_growpart (#1628) [Alberto Contreras]
 - schema: Enable deprecations in cc_users_groups (#1627)
   [Alberto Contreras]
 - util: Fix error path and parsing in get_proc_ppid()
 - main: avoid downloading full contents cmdline urls (#1606)
   [Alberto Contreras] (LP: #1937319)
 - schema: Enable deprecations in cc_scripts_vendor (#1629)
   [Alberto Contreras]
 - schema: Enable deprecations in cc_set_passwords (#1630)
   [Alberto Contreras]
 - sources/azure: add experimental support for preprovisioned os disks
   (#1622) [Chris Patterson]
 - Remove configobj a_to_u calls (#1632) [Stefano Rivera]
 - cc_debug: Drop this module (#1614) [Alberto Contreras]
 - schema: add aggregate descriptions in anyOf/oneOf (#1636)
 - testing: migrate test_sshutil to pytest (#1617) [Alberto Contreras]
 - testing: Fix test_ca_certs integration test (#1626) [Alberto Contreras]
 - testing: add support for pycloudlib's pro images (#1604)
   [Alberto Contreras]
 - testing: migrate test_cc_set_passwords to pytest (#1615)
   [Alberto Contreras]
 - network: add system_info network activator cloud.cfg overrides (#1619)
   (LP: #1958377)
 - docs: Align git remotes with uss-tableflip setup (#1624)
   [Alberto Contreras]
 - testing: cover active config module checks (#1609) [Alberto Contreras]
 - lxd: lvm avoid thinpool when kernel module absent
 - lxd: enable MTU configuration in cloud-init
 - doc: pin doc8 to last passing version
 - cc_set_passwords fixes (#1590)
 - Modernise importer.py and type ModuleDetails (#1605) [Alberto Contreras]
 - config: Def activate_by_schema_keys for t-z (#1613) [Alberto Contreras]
 - config: define activate_by_schema_keys for p-r mods (#1611)
   [Alberto Contreras]
 - clean: add param to remove /etc/machine-id for golden image creation
 - config: define `activate_by_schema_keys` for a-f mods (#1608)
   [Alberto Contreras]
 - config: define activate_by_schema_keys for s mods (#1612)
   [Alberto Contreras]
 - sources/azure: reorganize tests for network config (#1586)
   [Chris Patterson]
 - config: Define activate_by_schema_keys for g-n mods (#1610)
   [Alberto Contreras]
 - meta-schema: add infra to skip inapplicable modules [Alberto Contreras]
 - sources/azure: don't set cfg["password"] for default user pw (#1592)
   [Chris Patterson]
 - schema: activate grub-dpkg deprecations (#1600) [Alberto Contreras]
 - docs: clarify user password purposes (#1593)
 - cc_lxd: Add btrfs and lvm lxd storage options (SC-1026) (#1585)
 - archlinux: Fix distro naming[1] (#1601) [Kristian Klausen]
 - cc_ubuntu_autoinstall: support live-installer autoinstall config
 - clean: allow third party cleanup scripts in /etc/cloud/clean.d (#1581)
 - sources/azure: refactor chassis asset tag handling (#1574)
   [Chris Patterson]
 - Add "netcho" as contributor (#1591) [Kaloyan Kotlarski]
 - testing: drop impish support (#1596) [Alberto Contreras]
 - black: fix missed formatting issue which landed in main (#1594)
 - bsd: Don't assume that root user is in root group (#1587)
 - docs: Fix comment typo regarding use of packages (#1582)
   [Peter Mescalchin]
 - Update govc command in VMWare walkthrough (#1576) [manioo8]
 - Update .github-cla-signers (#1588) [Daniel Mullins]
 - Rename the openmandriva user t

[Yahoo-eng-team] [Bug 1986703] Re: Release 22.3

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1986703

Title:
   Release 22.3

Status in cloud-init:
  Fix Released

Bug description:
  Summary: Release 22.3
  Further information:
  == Release Notes ==

  Cloud-init release 22.3 is now available

  The 22.3 release:
   * spanned about 3 months
   * had 25 contributors from 27 domains
   * fixed 18 Launchpad issues

  Highlights:

  Config Module Additions / Deletions:
   - Ansible config module
   - Wireguard config module
   - Drop debug module

  Behavior changes:
   - schema: Resolve user-data if --system given
   - mounts: fix suggested_swapsize for > 64GB hosts
   - Add support for OpenMandriva

  New Features:
   - clean: add param to remove /etc/machine-id for golden image creation
   - Return cc_set_hostname to PER_INSTANCE frequency
   - clean: allow third party cleanup scripts in /etc/cloud/clean.d
   - ssh_util: Handle sshd_config.d folder

  Optimizations:
   - meta-schema: add infra to skip inapplicable modules
   - main: avoid downloading full contents cmdline urls
   - Update WebHookHandler to run as background thread
   - net: Implement link-local ephemeral ipv6

  
  New Features:
   - clean: add param to remove /etc/machine-id for golden image creation
   - Return cc_set_hostname to PER_INSTANCE frequency (#1651) (LP: #1983811)
   - clean: allow third party cleanup scripts in /etc/cloud/clean.d (#1581)
   - ssh_util: Handle sshd_config.d folder [Alberto Contreras] (LP: #1968873)
 [Alberto Contreras]

  Optimizations:
   - meta-schema: add infra to skip inapplicable modules [Alberto Contreras]
   - main: avoid downloading full contents cmdline urls (#1606)
 [Alberto Contreras] (LP: #1937319)
   - Update WebHookHandler to run as background thread (SC-456) (#1491)
 (LP: #1910552)
   - net: Implement link-local ephemeral ipv6

  == Changelog ==
   - sources: obj.pkl cache should be written anyime get_data is run (#1669)
   - schema: drop release number from version file (#1664)
   - pycloudlib: bump to quiet azure HTTP info logs (#1668)
   - test: fix wireguard integration tests (#1666)
   - Github is deprecating the 18.04 runner starting 12.1 (#1665)
   - integration tests: Ensure one setup for all tests (#1661)
   - tests: ansible test fixes (#1660)
   - Prevent concurrency issue in test_webhook_hander.py (#1658)
   - Workaround net_setup_link race with udev (#1655) (LP: #1983516)
   - test: drop erroneous lxd assertion, verify command succeeded (#1657)
   - Fix Chrony usage on Centos Stream (#1648) [Sven Haardiek] (LP: #1885952)
   - sources/azure: handle network unreachable errors for savable PPS (#1642)
     [Chris Patterson]
   - Return cc_set_hostname to PER_INSTANCE frequency (#1651) (LP: #1983811)
   - test: Collect integration test time by default (#1638)
   - test: Drop forced package install hack in lxd integration test (#1649)
   - schema: Resolve user-data if --system given (#1644)
     [Alberto Contreras] (LP: #1983306)
   - test: use fake filesystem to avoid file removal (#1647)
     [Alberto Contreras]
   - tox: Fix tip-flake8 and tip-mypy (#1635) [Alberto Contreras]
   - config: Add wireguard config module (#1570) [Fabian Lichtenegger-Lukas]
   - tests: can run without azure-cli, tests expect inactive ansible (#1643)
   - typing: Type UrlResponse.contents (#1633) [Alberto Contreras]
   - testing: fix references to `DEPRECATED.` (#1641) [Alberto Contreras]
   - ssh_util: Handle sshd_config.d folder [Alberto Contreras] (LP: #1968873)
   - schema: Enable deprecations in cc_update_etc_hosts (#1631)
     [Alberto Contreras]
   - Add Ansible Config Module (#1579)
   - util: Support Idle process state in get_proc_ppid() (#1637)
   - schema: Enable deprecations in cc_growpart (#1628) [Alberto Contreras]
   - schema: Enable deprecations in cc_users_groups (#1627)
     [Alberto Contreras]
   - util: Fix error path and parsing in get_proc_ppid()
   - main: avoid downloading full contents cmdline urls (#1606)
     [Alberto Contreras] (LP: #1937319)
   - schema: Enable deprecations in cc_scripts_vendor (#1629)
     [Alberto Contreras]
   - schema: Enable deprecations in cc_set_passwords (#1630)
     [Alberto Contreras]
   - sources/azure: add experimental support for preprovisioned os disks
     (#1622) [Chris Patterson]
   - Remove configobj a_to_u calls (#1632) [Stefano Rivera]
   - cc_debug: Drop this module (#1614) [Alberto Contreras]
   - schema: add aggregate descriptions in anyOf/oneOf (#1636)
   - testing: migrate test_sshutil to pytest (#1617) [Alberto Contreras]
   - testing: Fix test_ca_certs integration test (#1626) [Alberto Contreras]
   - testing: add support for pycloudlib's p

[Yahoo-eng-team] [Bug 1983516] Re: failed to generate config when interface was renamed

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1983516

Title:
  failed to generate config when interface was renamed

Status in cloud-init:
  Fix Released

Bug description:
  2022-08-03 18:42:31,598 - util.py[DEBUG]: Writing to 
/etc/netplan/50-cloud-init.yaml - wb: [644] 1359 bytes
  2022-08-03 18:42:31,598 - subp.py[DEBUG]: Running command ['netplan', 
'generate'] with allowed return codes [0] (shell=False, capture=True)
  2022-08-03 18:42:31,875 - subp.py[DEBUG]: Running command ['udevadm', 
'test-builtin', 'net_setup_link', '/sys/class/net/eth2'] with allowed return 
codes [0] (shell=False, capture=True)
  2022-08-03 18:42:31,880 - subp.py[DEBUG]: Running command ['udevadm', 
'test-builtin', 'net_setup_link', '/sys/class/net/eth0'] with allowed return 
codes [0] (shell=False, capture=True)
  2022-08-03 18:42:31,956 - subp.py[DEBUG]: Running command ['udevadm', 
'test-builtin', 'net_setup_link', '/sys/class/net/eth7'] with allowed return 
codes [0] (shell=False, capture=True)
  2022-08-03 18:42:31,959 - util.py[WARNING]: failed stage init-local
  2022-08-03 18:42:31,959 - util.py[DEBUG]: failed stage init-local
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 740, in 
status_wrapper
  ret = functor(name, args)
File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 410, in 
main_init
  init.apply_network_config(bring_up=bring_up_interfaces)
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 937, in 
apply_network_config
  return self.distro.apply_network_config(
File "/usr/lib/python3/dist-packages/cloudinit/distros/__init__.py", line 
233, in apply_network_config
  self._write_network_state(network_state)
File "/usr/lib/python3/dist-packages/cloudinit/distros/debian.py", line 
142, in _write_network_state
  return super()._write_network_state(network_state)
File "/usr/lib/python3/dist-packages/cloudinit/distros/__init__.py", line 
129, in _write_network_state
  renderer.render_network_state(network_state)
File "/usr/lib/python3/dist-packages/cloudinit/net/netplan.py", line 260, 
in render_network_state
  self._net_setup_link(run=self._postcmds)
File "/usr/lib/python3/dist-packages/cloudinit/net/netplan.py", line 282, 
in _net_setup_link
  subp.subp(cmd, capture=True)
File "/usr/lib/python3/dist-packages/cloudinit/subp.py", line 335, in subp
  raise ProcessExecutionError(
  cloudinit.subp.ProcessExecutionError: Unexpected error while running command.
  Command: ['udevadm', 'test-builtin', 'net_setup_link', '/sys/class/net/eth7']
  Exit code: 1
  Reason: -
  Stdout:
  Stderr: Load module index
  Parsed configuration file /usr/lib/systemd/network/99-default.link
  Parsed configuration file 
/usr/lib/systemd/network/73-usb-net-by-mac.link
  Parsed configuration file /run/systemd/network/10-netplan-eth3.link
  Parsed configuration file /run/systemd/network/10-netplan-eth2.link
  Parsed configuration file /run/systemd/network/10-netplan-eth1.link
  Parsed configuration file /run/systemd/network/10-netplan-eth0.link
  Created link configuration context.
  Failed to open device '/sys/class/net/eth7': No such device
  Unload module index
  Unloaded link configuration context.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1983516/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1983811] Re: Hostname getting set to fqdn after upgrading to cloud-init-22.2

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1983811

Title:
  Hostname getting set to fqdn after upgrading to cloud-init-22.2

Status in cloud-init:
  Fix Released

Bug description:
  Hi All,

  Environment details:
  cloud-init-22.2
  Photon OS 3.0 and above

  I am seeing something weird after upgrading to cloud-init-22.2

  My /etc/hosts looks like this:

  $ cat /etc/hosts 
  127.0.1.1ph3dev.local ph3dev
  127.0.0.1localhost

  And my /etc/hostname

  $ cat /etc/hostname
  ph3dev

  Now if I do systemctl restart cloud-init , /etc/hostname is getting
  changed.

  $ cat /etc/hostname 
  ph3dev.local

  And hostname command return fqdn instead of short name. Isn't it
  incorrect to have fqdn in /etc/hostname?

  I have prefer_fqdn_over_hostname = True in photon.py

  I changed frequency = PER_ONCE in cc_set_hostname.py and it doesn't
  modify /etc/hostname after that and this is how it was in cloud-init
  <= v22.1 and even in v22.1 we have prefer_fqdn_over_hostname set in
  photon.py but it doesn't modify /etc/hostname file.

  I doubt that https://github.com/canonical/cloud-init/pull/1365 has
  introduced this change, not sure though.

  We discussed a bit about this issue in
  https://github.com/canonical/cloud-init/pull/1365.

  If it helps, I see the follwing entries in cloud-init-22.1 logs:

  ```
  2022-08-08 06:58:38,498 - stages.py[DEBUG]: Running module set_hostname 
() with 
frequency once-per-instance
  ```

  And in cloud-init-22.2:
  ```
  2022-08-08 07:00:38,512 - modules.py[DEBUG]: Running module set_hostname 
() with 
frequency always
  ```
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1983811/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1983306] Re: schema validation not in line with specification

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1983306

Title:
  schema validation not in line with specification

Status in cloud-init:
  Fix Released

Bug description:
  Related to #1983303. My user-data begins with #include, as it's not a
  "Cloud Config Data" but an "Include File" as described in the official
  documentation. However, this causes the validator `cloud-init schema
  --system` to complain that

  ```
  Error:
  Cloud config schema errors: format-l1.c1: File None needs to begin with 
"#cloud-config"
  ```

  Ok I thought, I just manually add "#cloud-config" at the top and re-
  test:

  ```
  Error:
  Cloud-config is not a YAML dict.
  ```

  Well, it's not a YAML dict because it's not a cloud config data but an
  include file, which isn't in the YAML format.

  See the specification:
  https://cloudinit.readthedocs.io/en/latest/topics/format.html

  Also look at the implementation in `user_data.py`, function
  `_do_include`. As you can see, this file isn't processed as YAML but
  parsed line by line. So the specification and implementation agree,
  but the schema validator doesn't and thinks it should process it as
  YAML.

  This wouldn't be a practical problem for me, but due to #1983303 I get
  mangled logs and can't work around it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1983306/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1976564] Re: cloud-config: cloud_dir setting not honored globally by cloud-init

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1976564

Title:
  cloud-config: cloud_dir setting not honored globally by cloud-init

Status in cloud-init:
  Fix Released

Bug description:
  Changes to /etc/cloud/cloud.cfg system_info: paths: cloud_dir setting
  is not honored globally in cloud-init. Some paths continue to hardcode
  /var/lib/cloud paths to certain operations.

  Affects cloud-init version 22.2

  [Test Plan]

  cat > 95-custom-cloud-dir.cfg < '../../var/lib/cloud/data/result.json'

  # Expect to find no files in /var/lib/cloud
  lxc exec dev-x find /var/lib/cloud
  /var/lib/cloud
  /var/lib/cloud/data
  /var/lib/cloud/data/status.json

  [ Possible hardcoded paths to resolve]
  - cloudinit/util.py:fetch_ssl_details
  - cloudinit/sources/DataSourceBigstep.py
  - cloudinit/sources/DataSourceAzure.py
  - cloudinit/cmd/main.py:status_wrapper
  - cloudinit/cmd/devel/logs.py
  - cloudinit/apport.py:USER_DATA_FILE
  - cloudinit/config/cc_snap.py:ASSERTIONS_FILE

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1976564/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1980854] Re: tox lowest-supported-dev tests fail

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1980854

Title:
  tox lowest-supported-dev tests fail

Status in cloud-init:
  Fix Released

Bug description:
  I'm working on cloud-init with a view to adding support for the devuan
  distro (debian without systemd). I'm working on a local machine rather
  than a cloud provider, and I'm doing the development on devuan v4
  (chimaera) based on debian 11 (bullseye) - so I can't run the commands
  ubuntu-bug or journalctl. The version of python 3 on devuan chimaera
  is 3.9.

  When I run the tests, using tox, I get 140 failures from the lowest-
  supported-dev environment. I've identified that they're caused by two
  problems:

  1) jinja2 tries to import soft_unicode() from the package markupsafe.
  This has been removed from recent versions of markupsafe, and this
  causes jinja2 to fail to initialise properly, resulting in errors
  like:

  WARNING   cloudinit.templater:templater.py:128 Jinja not available as
  the selected renderer for desired template, reverting to the basic
  renderer.

  The problem has been flagged up in markupsafe:

  https://github.com/pallets/markupsafe/issues/304

  - but is apparently still unresolved. The recommended workaround is to
  use markupsafe 2.0.1, which was the last version to include
  soft_unicode(). This can be done by adding

  markupsafe==2.0.1

  to the deps in the [lowest-supported-deps] section of tox.ini,
  directly below jinja==2.10

  2) In python 3.9, threading.Thread.isAlive has been removed:

  https://github.com/spotify/luigi/issues/2939

  The recommendation is to use threading.Thread.is_alive instead.

  This breaks httpretty 0.9.5. The earliest version of httpretty in
  which this is fixed is 0.9.7

  Changing "httpretty==0.9.5" to "httpretty==0.9.7" in tox.ini works
  around this.

  With these two changes to tox.ini in place, tox on cloud-init under
  devuan 4 runs without failures.

  Hope this is useful. Happy to provide further information if required.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1980854/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1979877] Re: cloud-init fails with KeyError when nameserver config and matching interface are present

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1979877

Title:
  cloud-init fails with KeyError when nameserver config and matching
  interface are present

Status in cloud-init:
  Fix Released

Bug description:
  cloud-init fails to parse network configuration with a KeyError if:

  - The configuration has a `nameservers` configuration, and
  - The configuration matches an existing interface on the machine, and
  - The configuration name does not match that interfaces name.

  Consider the following network config:

  ```
  version: 2
  ethernets:
eth:
  match:
macaddress: '00:11:22:33:44:55'
  addresses: [10.0.0.2/24]
  gateway4: 10.0.0.1
  nameservers: 
addresses: [10.0.0.1]
  ```

  Now, if a device is present with the mac address 00:11:22:33:44:55,
  parsing will fail with the following stack trace:

  ```
  2022-06-25 10:26:43,657 - util.py[WARNING]: failed stage init-local
  2022-06-25 10:26:43,657 - util.py[DEBUG]: failed stage init-local
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 738, in 
status_wrapper
  ret = functor(name, args)
File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 410, in 
main_init
  init.apply_network_config(bring_up=bring_up_interfaces)
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 937, in 
apply_network_config
  return self.distro.apply_network_config(
File "/usr/lib/python3/dist-packages/cloudinit/distros/__init__.py", line 
231, in apply_network_config
  network_state = parse_net_config_data(netconfig)
File "/usr/lib/python3/dist-packages/cloudinit/net/network_state.py", line 
1056, in parse_net_config_data
  nsi.parse_config(skip_broken=skip_broken)
File "/usr/lib/python3/dist-packages/cloudinit/net/network_state.py", line 
278, in parse_config
  self.parse_config_v2(skip_broken=skip_broken)
File "/usr/lib/python3/dist-packages/cloudinit/net/network_state.py", line 
328, in parse_config_v2
  self._v2_common(command)
File "/usr/lib/python3/dist-packages/cloudinit/net/network_state.py", line 
782, in _v2_common
  self._handle_individual_nameserver(name_cmd, iface)
File "/usr/lib/python3/dist-packages/cloudinit/net/network_state.py", line 
110, in decorator
  return func(self, command, *args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/net/network_state.py", line 
570, in _handle_individual_nameserver
  _iface[iface]["dns"] = {"nameservers": nameservers, "search": search}
  KeyError: 'eth'
  ```

  I've investigated the issue myself and created a test case:

  ```
  from unittest import mock

  from cloudinit import safeyaml
  from cloudinit.net import network_state

  
  class TestNetDns:
  @mock.patch("cloudinit.net.network_state.get_interfaces_by_mac")
  def test_networkd_render_x(self, by_mac):
  by_mac.return_value = {"00:11:22:33:44:55": "foobar"}
  network_state.parse_net_config_data(safeyaml.load("""\
  version: 2
  ethernets:
eth:
  match:
macaddress: '00:11:22:33:44:55'
  addresses: [10.0.0.2/24]
  gateway4: 10.0.0.1
  nameservers: 
addresses: [10.0.0.1]
  """))
  ```

  This test case will fail with the KeyError.

  The reason for this bug is that `handle_ethernets` will take the
  interface name from the system because no set-name setting is present.
  It will then add the network state under that interface name, not the
  configured key 'eth'. Later, _handle_individual_nameserver will try to
  look up the state for 'eth' and fail.

  A quick bisect shows that this test case starts failing with commit
  bf94945fb855c40c5188cef5fb00327c51c41fef (though the mock doesn't work
  very far in the past). This commit introduced the name handling logic.

  As a workaround, you can give an explicit set-name statement, or
  change the key of the network config to match the physical device
  name.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1979877/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1977952] Re: In 22.2 cloud-init fails when phone-home module does not have "tries" parameter

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1977952

Title:
  In 22.2 cloud-init fails when phone-home module does not have "tries"
  parameter

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Bionic:
  Fix Released
Status in cloud-init source package in Focal:
  Fix Released
Status in cloud-init source package in Impish:
  Fix Released
Status in cloud-init source package in Jammy:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  The cloud-init "phone home" module contains an optional "tries" parameter. In 
release 22.2, this was accidentally changed to become mandatory. Any previously 
working cloud-config that didn't contain the "tries" parameter will now cause 
the module exit with exception. This happened because an overly broad exception 
handler for converting the 'tries' string to an int was changed to only raise 
on ValueError. However, if None (or any other non-string) is passed, a 
TypeError is raised, and this needs to be caught as well.

  [Test Case]
  1. Launch an Ubuntu instance on any cloud-init supported platform with the 
following userdata:

  #cloud-config
  phone_home:
url: http://192.168.1.1
post: all

  2. By inspecting /var/log/cloud-init.log, ensure the phone home module 
attempts to make a web request, with the following log:
  url_helper.py[DEBUG]: [0/10] open 'http://192.168.1.1' with {'url': 
'http://192.168.1.1', 'allow_redirects': True, 'method': 'POST', 'headers': 
{'User-Agent': 'Cloud-Init/22.2'}} configuration

  [Regression Potential]
  The parsing exceptions being caught should now be broad enough to handle any 
configuration we receive, but if not, we would still exit the module with 
exception.

  [Other Info]
  Github PR: https://github.com/canonical/cloud-init/pull/1500

  === End SRU Template ===

  Initial bug:

  Hi!

  We have some user-data files where we use the phone-home module of cloud-init.
  So far we did not use it's "tries" parameter and everything worked.
  However now in version 22.2 there was a change which causes cloud-init to 
fail.
  
https://github.com/canonical/cloud-init/compare/22.1...22.2#diff-a4aa83fbb946ba1ea7cf6c8dd5965cd62631dc9cb48d4baa50adddbfef06b82cL108

  In our case this change in the exception handling throws a TypeError,
  instead of the ValueError that is excepted:

  File "/usr/lib/python3/dist-packages/cloudinit/config/cc_phone_home.py", line 
132, in handle
     tries = int(tries)  # type: ignore
  TypeError: int() argument must be a string, a bytes-like object or a number, 
not 'NoneType'

  While we can add the "tries" parameter (and after that everything works just 
like before),
  this exception should be handled properly.

  Also according to guidelines:
  1. Tell us your cloud provider
  None
  2. Any appropriate cloud-init configuration you can provide us
  phone-home module
  3. Perform the following on the system and attach it to this bug:
  no logs are necessary

  Best regards:
  Zsolt

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1977952/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1979547] Re: cli: autocompletion for schema is wrong

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1979547

Title:
  cli: autocompletion for schema is wrong

Status in cloud-init:
  Fix Released

Bug description:
  The schema command was moved from the devel sub-command to the main
  one, but the autocompletion functionality still behaves as it would be
  under devel.

  Steps to reproduce:

  ```sh
  lxc launch ubuntu-daily:jammy jj
  lxc shell jj

  root@jj:~# cloud-init sch (Press TAB)

  root@jj:~# cloud-init devel (Press twice TAB)
  --helphotplug-hook  net-convert   schema

  root@jj:~# cloud-init --version
  /usr/bin/cloud-init 22.2-0ubuntu1~22.04.2

  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1979547/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1979065] Re: cc_set_passwords does not expire users if password given as hash

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1979065

Title:
  cc_set_passwords does not expire users if password given as hash

Status in cloud-init:
  Fix Released

Bug description:
  https://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-
  passwords

  Documentation explains three different ways of setting user password
  using chpasswd but doesn't mention that they would otherwise work any
  differently from one another. Passwords should by default be expired
  if not specifically set otherwise in chpasswd. Although if one sets
  the password as hash either in password or chpasswd list,
  cc_set_passwords.py skips passwd --expire  completely which
  doesn't match documented behaviour.

  https://github.com/canonical/cloud-
  
init/blob/728098325657cb2fec559cf321ccd5235e786381/cloudinit/config/cc_set_passwords.py#L260

  This part only applies to users which had either plain text password
  or random password set.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1979065/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1975907] Re: cloud-init devel net-convert crash when --debug is enabled

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1975907

Title:
  cloud-init devel net-convert crash when --debug is enabled

Status in cloud-init:
  Fix Released

Bug description:
  Since 22.2 enabling "--debug" for "cloud-init devel net-convert" will
  make cloud-init crash.

  Probably linked to 3e5938c6ae22b9f158f1404f41e3e43738cadff0 and the
  use of safe dumper.

  Stack trace shows:
  Traceback (most recent call last):

  
File "/xyz/git/cloud-init/bin/cloud-init", line 8, in   

   
  sys.exit(main())  

  
File 
"/xyz/git/cloud-init/lib/python3.8/site-packages/cloudinit/cmd/main.py", line 
1059, in main   

  retval = util.log_time(   

  
File "/xyz/git/cloud-init/lib/python3.8/site-packages/cloudinit/util.py", 
line 2637, in log_time  
 
  ret = func(*args, **kwargs)   

  
File 
"/xyz/git/cloud-init/lib/python3.8/site-packages/cloudinit/cmd/devel/net_convert.py",
 line 136, in handle_args   
 
  "\n".join(["", "Internal State", safeyaml.dumps(ns, noalias=True), ""])   

  
File 
"/xyz/git/cloud-init/lib/python3.8/site-packages/cloudinit/safeyaml.py", line 
161, in dumps   

  return yaml.dump( 

  
File "/xyz/git/cloud-init/lib/python3.8/site-packages/yaml/__init__.py", 
line 253, in dump   
  
  return dump_all([data], stream, Dumper=Dumper, **kwds)

  
File "/xyz/git/cloud-init/lib/python3.8/site-packages/yaml/__init__.py", 
line 241, in dump_all   
  
  dumper.represent(data)

  
File "/xyz/git/cloud-init/lib/python3.8/site-packages/yaml/representer.py", 
line 27, in represent   
   
  node = self.represent_data(data)  

  
File "/xyz/git/cloud-init/lib/python3.8/site-packages/yaml/representer.py", 
line 58, in represent_data  
   
  node = self.yaml_representers[None](self, data)   

  
File "/xyz/git/cloud-init/lib/python3.8/site-packages/yaml/representer.py",

[Yahoo-eng-team] [Bug 1975818] Re: Module "Yum Add Repo" should not replace "-" with "_" in repo_id

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1975818

Title:
  Module "Yum Add Repo" should not replace "-" with "_" in repo_id

Status in cloud-init:
  Fix Released

Bug description:
  Hello.

  there is no need to replace character "-" with "_" in repo id add
  using "Yum Add Repo" cloud-init module. All RHEL, EPEL or other
  vendor's repo ids contain "-" as word separator (eg. rhel-7-server-
  rpms, rhel-7-server-extras-rpms, rhel-7-server-optional-rpms,
  rhel-7-server-supplementary-rpm, epel-modular, docker-ce-stable, ...).
  This behavior breaks consistency with standard RHEL repo id naming.

  
  In this case I used OpenStack, RHEL 8.5 with cloud-init-21.1-7.el8._5.3.

  Cloud-init user-data.yaml looks like this:

  yum_repos:
rhel-8.5-appstream-mycloud:
  baseurl: 
  name: "repo name"
  enabled: True
  ...

  On deployed Nova instance result is:

  ls /etc/yum.repos.d/
  rhel_8.6_appstream_mycloud.repo

  head rhel_8.6_appstream_mycloud.repo
  # created by cloud-init on ...
  [rhel_8.6_appstream_mycloud]
  baseurl = ...
  ...

  
  Expected result was:

  /etc/yum.repos.d/rhel-8.5-appstream-mycloud.repo

  with content

  [rhel-8.5-appstream-mycloud]
  baseurl = ...


  I looked into code and found this function, where I recommend to
  remove this line:

  git diff
  diff --git a/cloudinit/config/cc_yum_add_repo.py 
b/cloudinit/config/cc_yum_add_repo.py
  index f7357192..8face5bf 100644
  --- a/cloudinit/config/cc_yum_add_repo.py
  +++ b/cloudinit/config/cc_yum_add_repo.py
  @@ -118,7 +118,6 @@ __doc__ = get_meta_doc(meta)

  
   def _canonicalize_id(repo_id):
  -repo_id = repo_id.lower().replace("-", "_")
   repo_id = repo_id.replace(" ", "_")
   return repo_id

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1975818/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1967942] Re: Oracle primary interface changes

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1967942

Title:
  Oracle primary interface changes

Status in cloud-init:
  Fix Released

Bug description:
  Currently if /run/initramfs/open-iscsi.interface does not exist, we do
  not detect the instance as iSCSI and do not use the files in
  /run/net-* . These files should be used regardless.

  Additionally, if we cannot setup a primary interface using these
  files, we use the ephemeral DHCP interface our primary interface. We
  should instead setup the temporary interface, retrieve metadata, and
  then change to use the primary interface based on what we find in
  metadata.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1967942/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1937319] Re: namespace collision on url kernel arg results in downloading iso multiple times

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1937319

Title:
  namespace collision on url kernel arg results in downloading iso
  multiple times

Status in cloud-init:
  Fix Released
Status in casper package in Ubuntu:
  Fix Released

Bug description:
  As listed at https://discourse.ubuntu.com/t/netbooting-the-live-
  server-installer/14510/135

  When attempting a netboot, we can end up in a situation where cloud-
  init downloads a full iso, only to decide that the first few bytes
  aren't the expected header and to ignore it.

  I suggest an enhancement where a small amount of data is downloaded at
  first, we check this data for the required #cloud-config, and then use
  that info to decide to continue to download the file or not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1937319/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1885952] Re: Wrong service name used for chrony when restarting service

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1885952

Title:
  Wrong service name used for chrony when restarting service

Status in cloud-init:
  Fix Released

Bug description:
  service is called chronyd and not chrony in CentOS/RH. Have been
  tested with lated CentOS cloud image + all latest updates (with epel
  enabled).

  [root@myhostname ~]# uname -a
  Linux myhostname 3.10.0-1127.13.1.el7.x86_64 #1 SMP Tue Jun 23 15:46:38 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux
  [root@myhostname ~]# cat /etc/centos-release
  CentOS Linux release 7.8.2003 (Core)


  [root@myhostname ~]# cloud-init single --name cc_ntp
  Cloud-init v. 18.5 running 'single' at Wed, 01 Jul 2020 19:16:33 +. Up 
54.51 seconds.
  2020-07-01 19:16:34,023 - cc_ntp.py[ERROR]: Failed to reload/start ntp 
service: Unexpected error while running command.
  Command: ['systemctl', 'reload-or-restart', 'chrony']
  Exit code: 5
  Reason: -
  Stdout: 
  Stderr: Failed to reload-or-restart chrony.service: Unit not found.
  Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/cloudinit/config/cc_ntp.py", line 
547, in handle
  systemd=cloud.distro.uses_systemd())
File "/usr/lib/python2.7/site-packages/cloudinit/config/cc_ntp.py", line 
436, in reload_ntp
  util.subp(cmd, capture=True)
File "/usr/lib/python2.7/site-packages/cloudinit/util.py", line 2084, in 
subp
  cmd=args)
  ProcessExecutionError: Unexpected error while running command.
  Command: ['systemctl', 'reload-or-restart', 'chrony']
  Exit code: 5
  Reason: -
  Stdout: 
  Stderr: Failed to reload-or-restart chrony.service: Unit not found.
  2020-07-01 19:16:34,025 - util.py[WARNING]: Running module cc_ntp () failed
  2020-07-01 19:16:34,040 - main.py[WARNING]: Ran cc_ntp but it failed!

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1885952/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1910552] Re: machines fail to boot if MAAS doesn't respond to cloud-init

[Brett Holman]

This bug is believed to be fixed in cloud-init in version 22.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1910552

Title:
  machines fail to boot if MAAS doesn't respond to cloud-init

Status in cloud-init:
  Fix Released
Status in MAAS:
  Triaged

Bug description:
  We have a recurring issue on a MAAS 2.3.7 (xenial), where once in a while we 
need to restart rackd and regiond to make maas respond to machines rebooting.
  This itself would be a different bug though.
  What I'd like to report here is that a machine should be able to finish its 
boot sequence even if it can't talk to the MAAS API.

  Observed behaviour:

  [  OK  ] Started Raise network interfaces.
  [  OK  ] Reached target Network.
   Starting Initial cloud-init job (metadata service crawler)...
  (stuck here indefinitely)

  (restart rackd and regiond)

  the machine reboots successfully.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1910552/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1988157] Re: cloud-init crash on EC2 datasources when IMDS returns an error

[Brett Holman]

** Changed in: cloud-init
   Status: New => Fix Committed

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1988157

Title:
  cloud-init crash on EC2 datasources when IMDS returns an error

Status in cloud-init:
  Fix Committed

Bug description:
  Hello,

  We are using the EC2 datasource for crawling the metadata and in our
  cloud provider, if the IMDS returns an 404 error on one metadata
  resource, cloud-init crashes and the setup fails.

  Here is the configuration
  ```/etc/cloud/cloud.cfg.d/99_metadata.cfg
  disable-ec2-metadata: false

  datasource_list: [ Ec2 ]
  datasource:
Ec2:
  strict_id: false
  metadata_urls: [ 'http://169.254.169.254:80' ]
  timeout: 5
  max_wait: 10
  ```

  Here is the log of the error
  ```
  [   23.223228] cloud-init[576]: Cloud-init v. 21.4-0ubuntu1~20.04.1 running 
'init' at Tue, 30 Aug 2022 11:43:36 +. Up 15.96 seconds.
  [   23.224719] cloud-init[576]: ci-info: 
+++Net device 
info+++
  [   23.226427] cloud-init[576]: ci-info: 
++--+--+---++---+
  [   23.228137] cloud-init[576]: ci-info: | Device |  Up  |   Address  
  |  Mask | Scope  | Hw-Address|
  [   23.230390] cloud-init[576]: ci-info: 
++--+--+---++---+
  [   23.232965] cloud-init[576]: ci-info: |  eth0  | True | 
10.9.42.189  | 255.255.255.0 | global | aa:03:94:21:c3:a1 |
  [   23.235247] cloud-init[576]: ci-info: |  eth0  | True | 
fe80::a803:94ff:fe21:c3a1/64 |   .   |  link  | aa:03:94:21:c3:a1 |
  [   23.250295] cloud-init[576]: ci-info: |   lo   | True |  127.0.0.1 
  |   255.0.0.0   |  host  | . |
  [   23.255043] cloud-init[576]: ci-info: |   lo   | True |   ::1/128  
  |   .   |  host  | . |
  [   23.256681] cloud-init[576]: ci-info: 
++--+--+---++---+
  [   23.258318] cloud-init[576]: ci-info: +Route 
IPv4 info+
  [   23.259755] cloud-init[576]: ci-info: 
+---+-+---+-+---+---+
  [   23.261224] cloud-init[576]: ci-info: | Route | Destination |  Gateway  |  
   Genmask | Interface | Flags |
  [   23.262683] cloud-init[576]: ci-info: 
+---+-+---+-+---+---+
  [   23.264190] cloud-init[576]: ci-info: |   0   |   0.0.0.0   | 10.9.42.3 |  
   0.0.0.0 |eth0   |   UG  |
  [   23.265660] cloud-init[576]: ci-info: |   1   |  10.9.42.0  |  0.0.0.0  |  
255.255.255.0  |eth0   |   U   |
  [   23.267324] cloud-init[576]: ci-info: |   2   |  10.9.42.3  |  0.0.0.0  | 
255.255.255.255 |eth0   |   UH  |
  [   23.277516] cloud-init[576]: ci-info: 
+---+-+---+-+---+---+
  [   23.279090] cloud-init[576]: ci-info: +++Route IPv6 
info+++
  [   23.280396] cloud-init[576]: ci-info: 
+---+-+-+---+---+
  [   23.281694] cloud-init[576]: ci-info: | Route | Destination | Gateway | 
Interface | Flags |
  [   23.283008] cloud-init[576]: ci-info: 
+---+-+-+---+---+
  [   23.284347] cloud-init[576]: ci-info: |   1   |  fe80::/64  |::   |
eth0   |   U   |
  [   23.285660] cloud-init[576]: ci-info: |   3   |local|::   |
eth0   |   U   |
  [   23.286969] cloud-init[576]: ci-info: |   4   |  multicast  |::   |
eth0   |   U   |
  [   23.288342] cloud-init[576]: ci-info: 
+---+-+-+---+---+
  [   23.289631] cloud-init[576]: 2022-08-30 11:43:44,207 - util.py[WARNING]: 
Failed fetching meta-data/ from url 
http://169.254.169.254:80/2016-09-02/meta-data/
  [   23.291570] cloud-init[576]: 2022-08-30 11:43:44,216 - util.py[WARNING]: 
Getting data from  failed
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1988157/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1988157] Re: cloud-init crash on EC2 datasources when IMDS returns an error

[Brett Holman]

** Changed in: cloud-init
   Status: Fix Released => Fix Committed

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1988157

Title:
  cloud-init crash on EC2 datasources when IMDS returns an error

Status in cloud-init:
  Fix Committed

Bug description:
  Hello,

  We are using the EC2 datasource for crawling the metadata and in our
  cloud provider, if the IMDS returns an 404 error on one metadata
  resource, cloud-init crashes and the setup fails.

  Here is the configuration
  ```/etc/cloud/cloud.cfg.d/99_metadata.cfg
  disable-ec2-metadata: false

  datasource_list: [ Ec2 ]
  datasource:
Ec2:
  strict_id: false
  metadata_urls: [ 'http://169.254.169.254:80' ]
  timeout: 5
  max_wait: 10
  ```

  Here is the log of the error
  ```
  [   23.223228] cloud-init[576]: Cloud-init v. 21.4-0ubuntu1~20.04.1 running 
'init' at Tue, 30 Aug 2022 11:43:36 +. Up 15.96 seconds.
  [   23.224719] cloud-init[576]: ci-info: 
+++Net device 
info+++
  [   23.226427] cloud-init[576]: ci-info: 
++--+--+---++---+
  [   23.228137] cloud-init[576]: ci-info: | Device |  Up  |   Address  
  |  Mask | Scope  | Hw-Address|
  [   23.230390] cloud-init[576]: ci-info: 
++--+--+---++---+
  [   23.232965] cloud-init[576]: ci-info: |  eth0  | True | 
10.9.42.189  | 255.255.255.0 | global | aa:03:94:21:c3:a1 |
  [   23.235247] cloud-init[576]: ci-info: |  eth0  | True | 
fe80::a803:94ff:fe21:c3a1/64 |   .   |  link  | aa:03:94:21:c3:a1 |
  [   23.250295] cloud-init[576]: ci-info: |   lo   | True |  127.0.0.1 
  |   255.0.0.0   |  host  | . |
  [   23.255043] cloud-init[576]: ci-info: |   lo   | True |   ::1/128  
  |   .   |  host  | . |
  [   23.256681] cloud-init[576]: ci-info: 
++--+--+---++---+
  [   23.258318] cloud-init[576]: ci-info: +Route 
IPv4 info+
  [   23.259755] cloud-init[576]: ci-info: 
+---+-+---+-+---+---+
  [   23.261224] cloud-init[576]: ci-info: | Route | Destination |  Gateway  |  
   Genmask | Interface | Flags |
  [   23.262683] cloud-init[576]: ci-info: 
+---+-+---+-+---+---+
  [   23.264190] cloud-init[576]: ci-info: |   0   |   0.0.0.0   | 10.9.42.3 |  
   0.0.0.0 |eth0   |   UG  |
  [   23.265660] cloud-init[576]: ci-info: |   1   |  10.9.42.0  |  0.0.0.0  |  
255.255.255.0  |eth0   |   U   |
  [   23.267324] cloud-init[576]: ci-info: |   2   |  10.9.42.3  |  0.0.0.0  | 
255.255.255.255 |eth0   |   UH  |
  [   23.277516] cloud-init[576]: ci-info: 
+---+-+---+-+---+---+
  [   23.279090] cloud-init[576]: ci-info: +++Route IPv6 
info+++
  [   23.280396] cloud-init[576]: ci-info: 
+---+-+-+---+---+
  [   23.281694] cloud-init[576]: ci-info: | Route | Destination | Gateway | 
Interface | Flags |
  [   23.283008] cloud-init[576]: ci-info: 
+---+-+-+---+---+
  [   23.284347] cloud-init[576]: ci-info: |   1   |  fe80::/64  |::   |
eth0   |   U   |
  [   23.285660] cloud-init[576]: ci-info: |   3   |local|::   |
eth0   |   U   |
  [   23.286969] cloud-init[576]: ci-info: |   4   |  multicast  |::   |
eth0   |   U   |
  [   23.288342] cloud-init[576]: ci-info: 
+---+-+-+---+---+
  [   23.289631] cloud-init[576]: 2022-08-30 11:43:44,207 - util.py[WARNING]: 
Failed fetching meta-data/ from url 
http://169.254.169.254:80/2016-09-02/meta-data/
  [   23.291570] cloud-init[576]: 2022-08-30 11:43:44,216 - util.py[WARNING]: 
Getting data from  failed
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1988157/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1986781] Re: [Ubuntu 22.04]cloud-init failed to complete after 10 minutes of waiting was shown during Installation via iDRAC Virtual Console

[Brett Holman]

Since the issue has been narrowed down to casper-md5check, which is out
of scope of cloud-init, I'm marking the cloud-init side of this bug as
"Invalid", since there is nothing actionable to do to in cloud-init to
resolve this bug, and the plans to increase debugging transparency that
Chad mentioned were already planned and scheduled.

** Changed in: cloud-init
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1986781

Title:
  [Ubuntu 22.04]cloud-init failed to complete after 10 minutes of
  waiting was shown during Installation via iDRAC Virtual Console

Status in cloud-init:
  Invalid
Status in subiquity:
  New

Bug description:
  Description:

  On Dell EMC PowerEdge system when Install Ubuntu 22.04 via iDRAC
  Virtual Console, cloud-init failed to complete after 10 minutes of
  waiting.

  Steps to Reproduce:

  1. Login to iDRAC and Launch Virtual Console.
  2. Connect to Virtual Media and Map ubuntu 22.04 iso file using Map CD/DVD 
option.
  3. Try Installing Ubuntu server.
  4. "cloud-init" failed to complete after 10 minutes of waiting was shown 
during Installation.

  Expected Results :-

  Installation should be successful.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1986781/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1991051] Re: Latest cloud-init release breaks Juju on LXD 4.0

[Brett Holman]

** Also affects: lxd
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1991051

Title:
  Latest cloud-init release breaks Juju on LXD 4.0

Status in cloud-images:
  New
Status in cloud-init:
  Invalid
Status in lxd:
  New
Status in cloud-init package in Ubuntu:
  Triaged

Bug description:
  Ubuntu focal comes with LXD 4.0 installed by default. When using Juju
  to create containers on a local LXD with focal based instances, the
  deployment breaks due to and incorrect cloud-init configuration (see
  https://github.com/lxc/lxd/issues/10951, which existed since 2015!). A
  fix is not meant to arrive in LXD 4.0 till November (see
  https://github.com/lxc/lxd/issues/10951#issuecomment-1258691195).

  The new behavior in cloud-init has real implications as right now our
  commercial offering of the Anbox Cloud Appliance on the AWS
  marketplace (https://aws.amazon.com/marketplace/pp/prodview-
  aqmdt52vqs5qk) is broken when people buy it without a simple path to
  fix, other than forcing users to upgrade to LXD 5.0. We will hotfix
  this and ask people at installation time to upgrade to LXD 5.0.

  However, have we considered rolling back the cloud-init update as it's
  causing issues for a variety of people? I know about one other product
  which broke due to this (OSM).

  Also see https://bugs.launchpad.net/juju/+bug/1990594

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1991051/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1603830] Re: Azure data source cannot generate public ssh key

[Brett Holman]

Modern supported "EL" derivatives appear to have this flag (tested on
centos8-stream and centos9-stream).

If this is believed to still be an issue, please reopen.


** Changed in: cloud-init
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1603830

Title:
  Azure data source cannot generate public ssh key

Status in cloud-init:
  Fix Released

Bug description:
  Given the following code on a EL based distribution:

  ```
  def crtfile_to_pubkey(fname):
  pipeline = ('openssl x509 -noout -pubkey < "$0" |'
  'ssh-keygen -i -m PKCS8 -f /dev/stdin')
  (out, _err) = util.subp(['sh', '-c', pipeline, fname], capture=True)
  return out.rstrip()
  ```

  Cloud-init is unable to generate a ssh public-key from the azure PKCS8 
certificate.
  The version of ssh-keygen on EL distributions does not have a -m flag.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1603830/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1993503] Re: grub_dpkg writes wrong device into debconf

[Brett Holman]

** Also affects: subiquity
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1993503

Title:
  grub_dpkg writes wrong device into debconf

Status in cloud-init:
  New
Status in subiquity:
  New

Bug description:
  After auto-installing ubuntu 22.04 onto a LV on a mdraid 1 with two
  disks cc_grub_dpkg overrides the correct `grub-pc/install_devices`
  debconf entry with a false one on first boot:

  ```
  ~# debconf-show grub-pc | grep grub-pc/install_devices:
  * grub-pc/install_devices: /dev/disk/by-id/dm-name-vg0-lv_root
  ```

  This breaks grub updates.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1993503/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1993503] Re: grub_dpkg writes wrong device into debconf

[Brett Holman]

> This is only possible for autoinstall. This bugreport is partly about
why disabling grub_dpkg in user-data better be the default for both
manual- and auto-install.

Since the requested behavior change can be driven by different user-data
from subiquity, I think this doesn't require cloud-init changes.

Since this doesn't require changes to cloud-init, and cloud-init will
not run this module unless configured to do so, I'm setting this bug to
invalid for cloud-init. I believe this to be a subiquity change.

Please update this bug if you think this is incorrect.

** Changed in: cloud-init
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1993503

Title:
  grub_dpkg writes wrong device into debconf

Status in cloud-init:
  Invalid
Status in subiquity:
  New

Bug description:
  After auto-installing ubuntu 22.04 onto a LV on a mdraid 1 with two
  disks cc_grub_dpkg overrides the correct `grub-pc/install_devices`
  debconf entry with a false one on first boot:

  ```
  ~# debconf-show grub-pc | grep grub-pc/install_devices:
  * grub-pc/install_devices: /dev/disk/by-id/dm-name-vg0-lv_root
  ```

  This breaks grub updates.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1993503/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1993068] Re: cloud-init starts as hostname ubuntu with dhcp before setting the real hostname

[Brett Holman]

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Also affects: subiquity
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1993068

Title:
  cloud-init starts as hostname ubuntu with dhcp before setting the real
  hostname

Status in cloud-init:
  New
Status in subiquity:
  New
Status in cloud-init package in Ubuntu:
  New

Bug description:
  Hi there, noticed a thing when setting up a Raspberry Pi 4 (CM4) with
  an ubuntu 22.04.1 server image, but I suspect it might affect more.

  I used this how-to:

  https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-
  pi#1-overview

  and it worked the second time. :) Sort of.

  The module is a Raspberry Pi Compute Module 4 Rev 1.1, CM4002016, no
  WLAN, 2GB RAM, 16GB eMMC drive. Omitting the WLAN settings when
  writing the image with the Pi Imager helped, otherwise the module
  won't be reachable by network, even if there is a cable on eth0 or via
  USB eth adapter. That as an aside.

  Now to the real issue: Giving all the data includes hostname, user /
  pass, ssh key. They will be set up correctly. However, when the module
  boots up the first time with the new image and cloud-init does its
  thing, it announces itself as hostname "ubuntu" to the DHCP server.
  Okay, why not, but why? Later on (20 minutes later, after completing
  sudo apt-get update and sudo apt-get dist-upgrade, and restarting of
  affected services) it correctly announces and registers with the
  desired hostname.

  2022-10-16T14:48:56.765932496Z DHCPDISCOVER from e4:5f:01:b7:98:68 via 
ovs_eth0
  2022-10-16T14:48:57.766149505Z DHCPOFFER on 192.168.0.157 to 
e4:5f:01:b7:98:68 (ubuntu) via ovs_eth0
  2022-10-16T14:48:57.838722880Z DHCPREQUEST for 192.168.0.157 (192.168.0.14) 
from e4:5f:01:b7:98:68 (ubuntu) via ovs_eth0
  2022-10-16T14:48:57.854729080Z DHCPACK on 192.168.0.157 to e4:5f:01:b7:98:68 
(ubuntu) via ovs_eth0
  2022-10-16T14:48:58.008077549Z Added new forward map from ubuntu.haus.lokal 
to 192.168.0.157
  2022-10-16T14:48:58.150293327Z Added reverse map from 
157.0.168.192.in-addr.arpa. to ubuntu.haus.lokal
  2022-10-16T15:09:31.369843970Z DHCPDISCOVER from e4:5f:01:b7:98:68 (ubuntu) 
via ovs_eth0
  2022-10-16T15:09:32.370471525Z DHCPOFFER on 192.168.0.157 to 
e4:5f:01:b7:98:68 (cmfour02) via ovs_eth0
  2022-10-16T15:09:32.372325758Z DHCPREQUEST for 192.168.0.157 (192.168.0.14) 
from e4:5f:01:b7:98:68 (cmfour02) via ovs_eth0
  2022-10-16T15:09:32.428124851Z Wrote 93 leases to leases file.
  2022-10-16T15:09:32.469561052Z DHCPACK on 192.168.0.157 to e4:5f:01:b7:98:68 
(cmfour02) via ovs_eth0
  2022-10-16T15:09:32.598233888Z Removed forward map from ubuntu.haus.lokal to 
192.168.0.157
  2022-10-16T15:09:32.889359255Z Removed reverse map on 
157.0.168.192.in-addr.arpa.
  2022-10-16T15:09:33.005177086Z Added new forward map from cmfour02.haus.lokal 
to 192.168.0.157
  2022-10-16T15:09:33.130294611Z Added reverse map from 
157.0.168.192.in-addr.arpa. to cmfour02.haus.lokal

  This is a bit odd, and given that the right hostname was available, I
  would suspect some order of execution issue.

  $ lsb_release -rd
  Description:  Ubuntu 22.04.1 LTS
  Release:  22.04

  apt-cache policy cloud-init
  cloud-init:
Installed: 22.3.4-0ubuntu1~22.04.1
Candidate: 22.3.4-0ubuntu1~22.04.1
Version table:
   *** 22.3.4-0ubuntu1~22.04.1 500
  500 http://ports.ubuntu.com/ubuntu-ports jammy-updates/main arm64 
Packages
  100 /var/lib/dpkg/status
   22.2-0ubuntu1~22.04.3 500
  500 http://ports.ubuntu.com/ubuntu-ports jammy-security/main arm64 
Packages
   22.1-14-g2e17a0d6-0ubuntu1~22.04.5 500
  500 http://ports.ubuntu.com/ubuntu-ports jammy/main arm64 Packages

  with best regards

  Jens Glathe

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1993068/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1993068] Re: cloud-init starts as hostname ubuntu with dhcp before setting the real hostname

[Brett Holman]

Hi Jens,

Thank you for reporting! I added the server autoinstaller project
(subiquity) to this bug, since it drives cloud-init configuration during
installs.

> Now to the real issue: Giving all the data includes hostname, user /
pass, ssh key. They will be set up correctly. However, when the module
boots up the first time with the new image and cloud-init does its
thing, it announces itself as hostname "ubuntu" to the DHCP server.
Okay, why not, but why?

Cloud-init is typically used to get configuration data during early boot
(often from a remote http server), which requires bringing up an
ephemeral network connection before configuration data is known. In
early boot stage, dhcp without knowing the configured hostname is a
common way to accomplish this.

Can you please explain why a dhcp request with a temporary hostname is a
bug?

** No longer affects: cloud-init (Ubuntu)

** Changed in: cloud-init
   Status: New => Incomplete

** Changed in: subiquity
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1993068

Title:
  cloud-init starts as hostname ubuntu with dhcp before setting the real
  hostname

Status in cloud-init:
  Incomplete
Status in subiquity:
  Incomplete

Bug description:
  Hi there, noticed a thing when setting up a Raspberry Pi 4 (CM4) with
  an ubuntu 22.04.1 server image, but I suspect it might affect more.

  I used this how-to:

  https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-
  pi#1-overview

  and it worked the second time. :) Sort of.

  The module is a Raspberry Pi Compute Module 4 Rev 1.1, CM4002016, no
  WLAN, 2GB RAM, 16GB eMMC drive. Omitting the WLAN settings when
  writing the image with the Pi Imager helped, otherwise the module
  won't be reachable by network, even if there is a cable on eth0 or via
  USB eth adapter. That as an aside.

  Now to the real issue: Giving all the data includes hostname, user /
  pass, ssh key. They will be set up correctly. However, when the module
  boots up the first time with the new image and cloud-init does its
  thing, it announces itself as hostname "ubuntu" to the DHCP server.
  Okay, why not, but why? Later on (20 minutes later, after completing
  sudo apt-get update and sudo apt-get dist-upgrade, and restarting of
  affected services) it correctly announces and registers with the
  desired hostname.

  2022-10-16T14:48:56.765932496Z DHCPDISCOVER from e4:5f:01:b7:98:68 via 
ovs_eth0
  2022-10-16T14:48:57.766149505Z DHCPOFFER on 192.168.0.157 to 
e4:5f:01:b7:98:68 (ubuntu) via ovs_eth0
  2022-10-16T14:48:57.838722880Z DHCPREQUEST for 192.168.0.157 (192.168.0.14) 
from e4:5f:01:b7:98:68 (ubuntu) via ovs_eth0
  2022-10-16T14:48:57.854729080Z DHCPACK on 192.168.0.157 to e4:5f:01:b7:98:68 
(ubuntu) via ovs_eth0
  2022-10-16T14:48:58.008077549Z Added new forward map from ubuntu.haus.lokal 
to 192.168.0.157
  2022-10-16T14:48:58.150293327Z Added reverse map from 
157.0.168.192.in-addr.arpa. to ubuntu.haus.lokal
  2022-10-16T15:09:31.369843970Z DHCPDISCOVER from e4:5f:01:b7:98:68 (ubuntu) 
via ovs_eth0
  2022-10-16T15:09:32.370471525Z DHCPOFFER on 192.168.0.157 to 
e4:5f:01:b7:98:68 (cmfour02) via ovs_eth0
  2022-10-16T15:09:32.372325758Z DHCPREQUEST for 192.168.0.157 (192.168.0.14) 
from e4:5f:01:b7:98:68 (cmfour02) via ovs_eth0
  2022-10-16T15:09:32.428124851Z Wrote 93 leases to leases file.
  2022-10-16T15:09:32.469561052Z DHCPACK on 192.168.0.157 to e4:5f:01:b7:98:68 
(cmfour02) via ovs_eth0
  2022-10-16T15:09:32.598233888Z Removed forward map from ubuntu.haus.lokal to 
192.168.0.157
  2022-10-16T15:09:32.889359255Z Removed reverse map on 
157.0.168.192.in-addr.arpa.
  2022-10-16T15:09:33.005177086Z Added new forward map from cmfour02.haus.lokal 
to 192.168.0.157
  2022-10-16T15:09:33.130294611Z Added reverse map from 
157.0.168.192.in-addr.arpa. to cmfour02.haus.lokal

  This is a bit odd, and given that the right hostname was available, I
  would suspect some order of execution issue.

  $ lsb_release -rd
  Description:  Ubuntu 22.04.1 LTS
  Release:  22.04

  apt-cache policy cloud-init
  cloud-init:
Installed: 22.3.4-0ubuntu1~22.04.1
Candidate: 22.3.4-0ubuntu1~22.04.1
Version table:
   *** 22.3.4-0ubuntu1~22.04.1 500
  500 http://ports.ubuntu.com/ubuntu-ports jammy-updates/main arm64 
Packages
  100 /var/lib/dpkg/status
   22.2-0ubuntu1~22.04.3 500
  500 http://ports.ubuntu.com/ubuntu-ports jammy-security/main arm64 
Packages
   22.1-14-g2e17a0d6-0ubuntu1~22.04.5 500
  500 http://ports.ubuntu.com/ubuntu-ports jammy/main arm64 Packages

  with best regards

  Jens Glathe

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1993068/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://lau

[Yahoo-eng-team] [Bug 1844191] Re: azure advanced networking sometimes triggers duplicate mac detection

[Brett Holman]

** Changed in: cloud-init
   Status: Fix Released => Confirmed

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1844191

Title:
  azure advanced networking sometimes triggers duplicate mac detection

Status in cloud-init:
  Confirmed

Bug description:
  Hi, we're still being affected by this on Azure with
  19.2-24-ge7881d5c-0ubuntu1~18.04.1 - using PACKER to build from image:
  BuildSource : Marketplace/Canonical/UbuntuServer/18.04-DAILY-LTS

  Here is the packer config:
  
  "provisioners": [
  {
"type": "shell",
"inline": [
  "while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo 
'Waiting for cloud-init...'; sleep 1; done"
]
  },
  {
  "type": "ansible",
  "playbook_file": "{{user `ansible_playbook`}}",
  "user": "packer",
  "extra_arguments": [ "--extra-vars", "codeVersion={{user 
`code_version`}} managed_image_name={{user `managed_image_name`}}" ]
  },
  {
  "type": "shell",
  "execute_command": "chmod +x {{ .Path }}; {{ .Vars }} sudo -E sh 
'{{ .Path }}'",
  "inline_shebang": "/bin/sh -x",
  "inline": [ "/usr/sbin/waagent -force -deprovision+user && export 
HISTSIZE=0 && sync" ]
  }]
  

  Here is the playbook:
  
  ---
  - hosts: all
remote_user: ubuntu
become: yes
become_method: sudo
become_user: root

environment:
  DEBIAN_FRONTEND: noninteractive
  

  Note: we are applying `enableAcceleratedNetworking: true` to the NIC,
  anecdotally we think this is related.

  Usually our playbook has more in it (obviously) but Azure kept
  pointing fingers at us that our image was causing the problem, so I
  ran this test simply deploying a blank deprovisioned image via our
  same process.

  And here's what happens on the serial console log:

  
  [   20.337603] sh[910]: + [ -e /var/lib/cloud/instance/obj.pkl ]
  [   20.343177] sh[910]: + echo cleaning persistent cloud-init object
  [   20.349027] [  OK  ] Started Network Time Synchronization.
  [  OK  ] Reached target System Time Synchronized.
  sh[910]: cleaning persistent cloud-init object
  [   20.361066] sh[910]: + rm /var/lib/cloud/instance/obj.pkl
  [   20.412333] sh[910]: + exit 0
  [   34.282291] cloud-init[938]: Cloud-init v. 
19.2-24-ge7881d5c-0ubuntu1~18.04.1 running 'init-local' at Mon, 16 Sep 2019 
18:02:23 +. Up 32.02 seconds.
  [   34.288809] cloud-init[938]: 2019-09-16 18:02:25,262 - util.py[WARNING]: 
failed stage init-local
  [   34.423057] cloud-init[938]: failed run of stage init-local
  [   34.437716] cloud-init[938]: 

  [   34.441088] cloud-init[938]: Traceback (most recent call last):
  [   34.443719] cloud-init[938]:   File 
"/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 653, in 
status_wrapper
  [   34.448072] cloud-init[938]: ret = functor(name, args)
  [   34.450532] cloud-init[938]:   File 
"/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 362, in main_init
  [   34.454849] cloud-init[938]: 
init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL))
  [   34.458725] cloud-init[938]:   File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 697, in 
apply_network_config
  [   34.463421] cloud-init[938]: net.wait_for_physdevs(netcfg)
  [   34.466051] cloud-init[938]:   File 
"/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 344, in 
wait_for_physdevs
  [   34.470673] cloud-init[938]: present_macs = 
get_interfaces_by_mac().keys()
  [   34.473964] cloud-init[938]:   File 
"/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 633, in 
get_interfaces_by_mac
  [   34.479325] cloud-init[938]: (name, ret[mac], mac))
  [   34.481838] cloud-init[938]: RuntimeError: duplicate mac found! both 
'eth0' and 'enP1s1' have mac '00:0d:3a:7c:f7:3f'
  [   34.486614] cloud-init[938]: 

  [FAILED] Failed to start Initial cloud-init job (pre-networking).
  See 'systemctl status cloud-init-local.service' for details.
  [  OK  ] Reached target Network (Pre).
   Starting Network Service...
  [  OK  ] Started Network Service.
   Starting Wait for Network to be Configured...
   Starting Network Name Resolution...
  [  OK  ] Started Wait for Network to be Configured.
   Starting Initial cloud-init job (metadata service crawler)...
  [  OK  ] Started Network Name Resolution.
  [  OK  ] Reached target Host and Network Name Lookups.
  [  OK  ] Reached target Network.
  

  When this happens, the machine never boots, and we get an
  OSProvisioningTimedOut error after about 30 minutes, and the machine
  never reaches healthy state.

To manage notifications about

[Yahoo-eng-team] [Bug 1996789] [NEW] Don't Break On Duplicate Mac Addresses

[Brett Holman]

Public bug reported:

Currently when duplicate mac addresses are detected, cloud-init dies.

While duplicate macs are typically corner cases, there are cases when
they can be valid[1].

Consider this example[2]. After bonding two interfaces, the interfaces
were left with duplicate mac addresses. Using cloud-init on this system
fails at the time that these devices are detected.

If no network config is given, or if a config is given configuring a
single address, we have the opportunity to do something intelligent to
allow cloud-init to boot by using the "fallback interface" (in cloud-
init this is the first interface), rather than throwing an exception and
dying.

Netplan's mac matching assumes 1:1 mapping between mac addresses and
interfaces, so in the case of multiple interfaces configured with
matches, we still can't do anything intelligent.


[1] Until these have unique addresses, these interfaces will not be usable on 
the same broadcast domain, but they should still be able to work individually 
on different networks.
[2] 
https://stackoverflow.com/questions/74459180/deleted-bond-interface-left-me-with-duplicate-mac-on-two-interfaces

** Affects: cloud-init
 Importance: Medium
 Status: New

** Attachment added: "failure on detection"
   https://bugs.launchpad.net/bugs/1996789/+attachment/5631030/+files/GSh4o.png

** Changed in: cloud-init
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1996789

Title:
  Don't Break On Duplicate Mac Addresses

Status in cloud-init:
  New

Bug description:
  Currently when duplicate mac addresses are detected, cloud-init dies.

  While duplicate macs are typically corner cases, there are cases when
  they can be valid[1].

  Consider this example[2]. After bonding two interfaces, the interfaces
  were left with duplicate mac addresses. Using cloud-init on this
  system fails at the time that these devices are detected.

  If no network config is given, or if a config is given configuring a
  single address, we have the opportunity to do something intelligent to
  allow cloud-init to boot by using the "fallback interface" (in cloud-
  init this is the first interface), rather than throwing an exception
  and dying.

  Netplan's mac matching assumes 1:1 mapping between mac addresses and
  interfaces, so in the case of multiple interfaces configured with
  matches, we still can't do anything intelligent.

  
  [1] Until these have unique addresses, these interfaces will not be usable on 
the same broadcast domain, but they should still be able to work individually 
on different networks.
  [2] 
https://stackoverflow.com/questions/74459180/deleted-bond-interface-left-me-with-duplicate-mac-on-two-interfaces

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1996789/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1997124] [NEW] Netplan/Systemd/Cloud-init/Dbus Race

[Brett Holman]

Public bug reported:

Cloud-init is seeing intermittent failures while running `netplan
apply`, which appears to be caused by a missing resource at the time of
call.

The symptom in cloud-init logs looks like:

Running ['netplan', 'apply'] resulted in stderr output: Failed to
connect system bus: No such file or directory

I think that this error[1] is likely caused by cloud-init running
netplan apply too early in boot process (before dbus is active).

Today I stumbled upon this error which was hit in MAAS[2]. We have also
hit it intermittently during tests (we didn't have a reproducer).

Realizing that this may not be a cloud-init error, but possibly a
dependency bug between dbus/systemd we decided to file this bug for
broader visibility to other projects.

I will follow up this initial report with some comments from our
discussion earlier.

[1] https://github.com/canonical/netplan/blob/main/src/dbus.c#L801
[2] 
https://discourse.maas.io/t/latest-ubuntu-20-04-image-causing-netplan-error/5970

** Affects: cloud-init
 Importance: Undecided
 Status: New

** Affects: systemd
 Importance: Undecided
 Status: New

** Also affects: systemd
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1997124

Title:
  Netplan/Systemd/Cloud-init/Dbus Race

Status in cloud-init:
  New
Status in systemd:
  New

Bug description:
  Cloud-init is seeing intermittent failures while running `netplan
  apply`, which appears to be caused by a missing resource at the time
  of call.

  The symptom in cloud-init logs looks like:

  Running ['netplan', 'apply'] resulted in stderr output: Failed to
  connect system bus: No such file or directory

  I think that this error[1] is likely caused by cloud-init running
  netplan apply too early in boot process (before dbus is active).

  Today I stumbled upon this error which was hit in MAAS[2]. We have
  also hit it intermittently during tests (we didn't have a reproducer).

  Realizing that this may not be a cloud-init error, but possibly a
  dependency bug between dbus/systemd we decided to file this bug for
  broader visibility to other projects.

  I will follow up this initial report with some comments from our
  discussion earlier.

  [1] https://github.com/canonical/netplan/blob/main/src/dbus.c#L801
  [2] 
https://discourse.maas.io/t/latest-ubuntu-20-04-image-causing-netplan-error/5970

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1997124/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1997124] Re: Netplan/Systemd/Cloud-init/Dbus Race

[Brett Holman]

> Separately we really ought to port networkd from dbus communication to
varlink such that it can be used safely on critical boot path. The rest
of the Systemd critical components are already using varlink.

+1

> did you mean to mark Ubuntu(Systemd) as affected?

Yes, I'll update that thanks.


** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

** No longer affects: systemd

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1997124

Title:
  Netplan/Systemd/Cloud-init/Dbus Race

Status in cloud-init:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Cloud-init is seeing intermittent failures while running `netplan
  apply`, which appears to be caused by a missing resource at the time
  of call.

  The symptom in cloud-init logs looks like:

  Running ['netplan', 'apply'] resulted in stderr output: Failed to
  connect system bus: No such file or directory

  I think that this error[1] is likely caused by cloud-init running
  netplan apply too early in boot process (before dbus is active).

  Today I stumbled upon this error which was hit in MAAS[2]. We have
  also hit it intermittently during tests (we didn't have a reproducer).

  Realizing that this may not be a cloud-init error, but possibly a
  dependency bug between dbus/systemd we decided to file this bug for
  broader visibility to other projects.

  I will follow up this initial report with some comments from our
  discussion earlier.

  [1] https://github.com/canonical/netplan/blob/main/src/dbus.c#L801
  [2] 
https://discourse.maas.io/t/latest-ubuntu-20-04-image-causing-netplan-error/5970

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1997124/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1988499] Re: Snap prevents repartitioning Azure resource disk

[Brett Holman]

** Also affects: snapd
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1988499

Title:
  Snap prevents repartitioning Azure resource disk

Status in cloud-init:
  New
Status in snapd:
  New

Bug description:
  In an Azure VM, the resource disk (a.k.a. “local” or “temp” disk) has
  a single partition created by the Azure infrastructure. Linux cloud-
  init creates an ext4 file system in that partition and arranges for it
  to be mounted on /mnt. In Ubuntu 20.04 and Ubuntu 22.04 images in the
  Azure Marketplace, snap then creates a bind mount of /mnt for its
  internal purposes.

  Some customers want to use the Azure resource disk for purposes other
  than a file system mounted on /mnt.  If they unmount the disk, and use
  a partition editor to remove or change the partition structure, the
  closing ioctl to re-read the partition table fails because the Linux
  kernel still has a reference to the disk.  The command “blockdev
  --rereadpt” also fails.

  After debugging this problem, it turns out that the umount of /mnt
  only partially succeeds, and that’s why the ioctl thinks the disk is
  still in use.  From what’s visible in the file system, the umount has
  succeeded.  And “lsblk” shows that /dev/sdb1 (assuming the resource
  disk is /dev/sdb) as not mounted anywhere.  But this message:

   [   51.885870] EXT4-fs (sdb1): unmounting filesystem.

  is *not* output in dmesg because internally the Linux kernel still has
  a reference to the mount that it is waiting (forever) to go away.

  The problem is that snap has a reference to the mount, which was
  created by “snap-confine” doing the bind mount. This behavior of snap
  is specifically for the /mnt mount point (and maybe “/” for the root
  file system?):

  * If I bugger things up a bit so that cloud-init doesn’t force the
  resource disk mount point to be /mnt, and change it to be /mnt2, then
  Ubuntu boots normally, and mounts the resource disk on /mnt2.  At that
  point, I can umount /mnt2, and the umount is done 100%, including the
  “unmounting filesystem” message in dmesg. The ioctl problem in fdisk
  or parted goes away commensurately.

  * If I remove “snap” entirely from my Ubuntu 20.04 installation, the
  problem also goes away.

  * The problem does not occur on RHEL 8.5 or CentOS 8.5, which don’t
  have snap in the first place.

  What’s the right way to solve this problem?  Unfortunately, I’m not
  knowledgeable about snap or what snap-confine is trying to do.

  * Why is snap tracking /mnt?  Is there a way to tell snap not to track
  /mnt?

  * Or is there some design flaw in snap that causes the mount on /mnt
  to not work normally?

  Longer run, we’re looking at enhancing cloud-init with an option to
  not mount the resource disk at all, which should avoid the problem.
  But still, there should be a way for the mount of the resource disk on
  /mnt to work normally.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1988499/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2003121] Re: machine-id is not reset when instance-id changes

[Brett Holman]

Resetting machine-id at runtime would be a pretty big break from current
expectations, and correct implementation would require foreknowledge of
services using machine-id that are provided in an image. The potential
for bugs due to implementation complexity, potential for boot speed
regression caused by services delaying until after machine-id is reset,
and expected future burden of such a feature due to changes in services
and variation in Ubuntu and other distros makes the perceived risk of
this feature outweigh the benefit. These complexity, risk, and potential
boot speed issues are not present when machine-id is correctly set at
boot time, so I'm hesitant to move forward with this request.

I'll mark this "Won't Fix" for now.

In the meantime, I'd like to point users experiencing the same issue
towards our build recommendation[1], specifically the --machine-id
option.

[1] https://cloudinit.readthedocs.io/en/latest/reference/cli.html#clean

** Changed in: cloud-init
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/2003121

Title:
  machine-id is not reset when instance-id changes

Status in cloud-init:
  Won't Fix

Bug description:
  As discussed in #ubuntu-server just now, it's expected that cloud-init
  will ensure that machine-id is not carried over when a VM is cloned
  and this is detectable by an instance-id change.

  This would align behaviour with ssh host key regeneration behaviour.

  Actual behaviour: currently if a VM is cloned and the instance-id
  changes, /etc/machine-id remains the same.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2003121/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2006518] [NEW] Inconsistent kernel command line datasource detection

[Brett Holman]

Public bug reported:

cloud-init has undocumented support for declaring datasources using the
kernel commandline. This proves valuable in edge case scenarios as a
workaround when ds-identify detection is broken.

This behavior is inconsistently supported across datasources, several of
which[1] do some form of runtime detection in the datasource module
which may override cmdline-specified datasources.

We should either fix current behavior or provide a new key name in the
cmdline that always overrides runtime cloud-init detection in all
datasources (likely involving a refactor into the datasource class).
Once complete, this should be documented.


Originally reported in [2].

[1] one example: 
https://github.com/canonical/cloud-init/blob/02202954c65a7a1cdb9b28703bd0af01edd0e091/cloudinit/sources/DataSourceOpenStack.py#L271
[2] https://bugs.launchpad.net/cloud-init/+bug/1815990

** Affects: cloud-init
 Importance: Medium
 Status: Triaged

** Changed in: cloud-init
   Importance: Undecided => Medium

** Changed in: cloud-init
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/2006518

Title:
  Inconsistent kernel command line datasource detection

Status in cloud-init:
  Triaged

Bug description:
  cloud-init has undocumented support for declaring datasources using
  the kernel commandline. This proves valuable in edge case scenarios as
  a workaround when ds-identify detection is broken.

  This behavior is inconsistently supported across datasources, several
  of which[1] do some form of runtime detection in the datasource module
  which may override cmdline-specified datasources.

  We should either fix current behavior or provide a new key name in the
  cmdline that always overrides runtime cloud-init detection in all
  datasources (likely involving a refactor into the datasource class).
  Once complete, this should be documented.

  
  Originally reported in [2].

  [1] one example: 
https://github.com/canonical/cloud-init/blob/02202954c65a7a1cdb9b28703bd0af01edd0e091/cloudinit/sources/DataSourceOpenStack.py#L271
  [2] https://bugs.launchpad.net/cloud-init/+bug/1815990

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2006518/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2006775] [NEW] [feature] support key by url in apt configure module

[Brett Holman]

Public bug reported:

A common way of distributing keys is by hosting them at a URL for
download. This is not currently supported by the apt configure module,
and would be a simple addition.

Example usage (note the suggested 'keyurl' key)

apt:
  sources:
  source1:
  keyurl: 'https://domain.io/keys/key1.gpg'
  source: 'deb [signed-by=$KEY_FILE] http:/// jammy main'

** Affects: cloud-init
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/2006775

Title:
  [feature] support key by url in apt configure module

Status in cloud-init:
  New

Bug description:
  A common way of distributing keys is by hosting them at a URL for
  download. This is not currently supported by the apt configure module,
  and would be a simple addition.

  Example usage (note the suggested 'keyurl' key)

  apt:
sources:
source1:
keyurl: 'https://domain.io/keys/key1.gpg'
source: 'deb [signed-by=$KEY_FILE] http:/// jammy main'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2006775/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2006784] Re: dhcp lookups depend on end-of-life dhclient

[Brett Holman]

NixOS is not supported by upstream cloud-init. Please contact your
distro maintainers for a fix.

Regarding ISC's client support, this is a real issue and plans for a
replacement are under way.

** Changed in: cloud-init
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/2006784

Title:
  dhcp lookups depend on end-of-life dhclient

Status in cloud-init:
  Invalid

Bug description:
  When using DataSourceHetzner, there is a required dhcp lookup. This
  digs down to a function named `maybe_perform_dhcp_discovery` which
  breaks when a `which dhclient` does not return a binary. This raises a
  `NoDHCPLeaseMissingDhclientError`.

  I have only tested this under NixOS, as its one of the first
  distributions to have have removed `dhclient` from its the package
  tree following the deprecation by ISC's to the package.

  DHCP lookups should be changed to support a non-deprecated dhcp
  library.

  
  Cloud-provider: Hetzner

  Cloud-init config:

  ```
  system_info:
distro: nixos
network:
  renderers: [networkd]
  users:
   - root

  disable_root: false
  preserve_hostname: false

  cloud_init_modules:
   - set_hostname
   - update_hostname
   - update_etc_hosts
  cloud_config_modules: []
  cloud_final_modules: []

  datasource_list:
   - DataSourceHetzner
  ```

  Source where error is raised from:
  
https://github.com/canonical/cloud-init/blob/b3978cbd6c68c883f5ab02630d8d7fcb220b270c/cloudinit/net/dhcp.py#L69

  End-of-life notice from ISC at 02 Jul 2021:
  https://www.isc.org/blogs/dhcp-client-relay-eom/

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2006784/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2009236] [NEW] Cloud-init inconsistently uses config

[Brett Holman]

Public bug reported:

On boot, cloud-init is able to pass cloud-config via userdata_raw, a
useful feature when testing behavior on a datasource that doesn't have
its own way of retrieving userdata.

system_info:
   datasource:
 None:
   userdata_raw: "#cloud-config\ngrub_dpkg:\n  enabled: true"


This works during boot as one might expect:

2023-03-03 21:15:59,255 - modules.py[DEBUG]: Running module grub-dpkg () with 
frequency once-per-instance
2023-03-03 21:15:59,256 - handlers.py[DEBUG]: start: 
modules-config/config-grub-dpkg: running config-grub-dpkg with frequency 
once-per-instance


However, cloud-init's single subcommand clearly uses a different configuration, 
since the following fails to run the same module with the same config:

```
cloud-init --debug --force single --frequency always --name cc_grub_dpkg
```

Furthermore, this userdata_raw isn't included in /run/cloud-
init/instance-data-sensitive.json, nor in cloud-init query -a.

Alarmingly, an invalid config provided via userdata_raw is not warned of
by cloud-init schema --system:

```
system_info:
   # This will affect which distro class gets used
   datasource:
 NoCloud:
   userdata_raw: |
 #cloud-config
 grub_dpkg:
   enabled: true
   invalid-key: true
```

output:
```
# cloud-init schema --system
Found cloud-config data types: user-data, vendor-data

1. user-data at 
/var/lib/cloud/instances/cloudinit-0302-160255pw859u9h/cloud-config.txt:
  Valid cloud-config: user-data

2. vendor-data at 
/var/lib/cloud/instances/cloudinit-0302-160255pw859u9h/vendor-cloud-config.txt:
  Valid cloud-config: vendor-data
 ```

These details reveal inconsistency in cloud-init config handling, and
all contribute to a confusing user experience when using userdata_raw.

There may be other inconsistencies too - configs passed directly on the
kernel commandline (cc:  end_cc), and configs sourced from a url
via the kernel commandline (cloud-config-url=) are both used during boot
- but I haven't looked to see whether they behave correctly with
(schema|single|query) subcommands or show up in /run/cloud-
init/instance-data-sensitive.json, but after this finding we probably
aught to audit for other issues like this.

** Affects: cloud-init
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/2009236

Title:
  Cloud-init inconsistently uses config

Status in cloud-init:
  New

Bug description:
  On boot, cloud-init is able to pass cloud-config via userdata_raw, a
  useful feature when testing behavior on a datasource that doesn't have
  its own way of retrieving userdata.

  system_info:
 datasource:
   None:
 userdata_raw: "#cloud-config\ngrub_dpkg:\n  enabled: true"

  
  This works during boot as one might expect:

  2023-03-03 21:15:59,255 - modules.py[DEBUG]: Running module grub-dpkg 
() with 
frequency once-per-instance
  2023-03-03 21:15:59,256 - handlers.py[DEBUG]: start: 
modules-config/config-grub-dpkg: running config-grub-dpkg with frequency 
once-per-instance

  
  However, cloud-init's single subcommand clearly uses a different 
configuration, since the following fails to run the same module with the same 
config:

  ```
  cloud-init --debug --force single --frequency always --name cc_grub_dpkg
  ```

  Furthermore, this userdata_raw isn't included in /run/cloud-
  init/instance-data-sensitive.json, nor in cloud-init query -a.

  Alarmingly, an invalid config provided via userdata_raw is not warned
  of by cloud-init schema --system:

  ```
  system_info:
 # This will affect which distro class gets used
 datasource:
   NoCloud:
 userdata_raw: |
   #cloud-config
   grub_dpkg:
 enabled: true
 invalid-key: true
  ```

  output:
  ```
  # cloud-init schema --system
  Found cloud-config data types: user-data, vendor-data

  1. user-data at 
/var/lib/cloud/instances/cloudinit-0302-160255pw859u9h/cloud-config.txt:
Valid cloud-config: user-data

  2. vendor-data at 
/var/lib/cloud/instances/cloudinit-0302-160255pw859u9h/vendor-cloud-config.txt:
Valid cloud-config: vendor-data
   ```

  These details reveal inconsistency in cloud-init config handling, and
  all contribute to a confusing user experience when using userdata_raw.

  There may be other inconsistencies too - configs passed directly on
  the kernel commandline (cc:  end_cc), and configs sourced from
  a url via the kernel commandline (cloud-config-url=) are both used
  during boot - but I haven't looked to see whether they behave
  correctly with (schema|single|query) subcommands or show up in
  /run/cloud-init/instance-data-sensitive.json, but after this finding
  we probably aught to audit for other issues like this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2009236/+subscr

[Yahoo-eng-team] [Bug 1988768] Re: locale language not installed after first boot 22.04.1 LTS

[Brett Holman]

** Changed in: cloud-init
   Status: Incomplete => Invalid

** Changed in: subiquity
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1988768

Title:
  locale language not installed after first boot 22.04.1 LTS

Status in cloud-init:
  Invalid
Status in subiquity:
  Invalid

Bug description:
  using the 'locale: de_DE' cloud-init user-data option results in an
  ubuntu installation displaying en_US on first boot login screen. When
  checking the region and language options in the UI login screen is set
  to 'German' but when checking the above selection for languages no
  languages are installed with the system. Keyboard layout 'de
  nodeadkeys' was set and active as expected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1988768/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2009746] Re: dpkg-reconfigure cloud-init: yaml.load errors during MAAS deloyment of Ubuntu 23.04(Lunar)

[Brett Holman]

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/2009746

Title:
  dpkg-reconfigure cloud-init: yaml.load errors during MAAS deloyment of
  Ubuntu 23.04(Lunar)

Status in cloud-init:
  Fix Released
Status in MAAS:
  Invalid
Status in maas package in Ubuntu:
  Invalid

Bug description:
  Affects  cloud-init 23.1.1 Lunar

  MAAS deployed Ubuntu 23.04 (Lunar) machines invoke `dpkg-reconfigure
  cloud-init`  which results in an exit 1 with the following traceback
  as seen in curtin logs:


  
  Running command ['unshare', '--fork', '--pid', '--', 'chroot', 
'/tmp/tmpwr8y_4f8/target', 'dpkg-reconfigure', '--frontend=noninteractive', 
'cloud-init'] with allowed return codes [0] (capture=True)
  finish: cmd-install/stage-curthooks/builtin/cmd-curthooks/writing-apt-config: 
FAIL: configuring apt configuring apt
  finish: cmd-install/stage-curthooks/builtin/cmd-curthooks: FAIL: curtin 
command curthooks
  Traceback (most recent call last):
File "/curtin/curtin/commands/main.py", line 202, in main
  ret = args.func(args)
^^^
File "/curtin/curtin/commands/curthooks.py", line 1886, in curthooks
  builtin_curthooks(cfg, target, state)
File "/curtin/curtin/commands/curthooks.py", line 1692, in builtin_curthooks
  do_apt_config(cfg, target)
File "/curtin/curtin/commands/curthooks.py", line 97, in do_apt_config
  apt_config.handle_apt(apt_cfg, target)
File "/curtin/curtin/commands/apt_config.py", line 73, in handle_apt
  apply_debconf_selections(cfg, target)
File "/curtin/curtin/commands/apt_config.py", line 167, in 
apply_debconf_selections
  dpkg_reconfigure(need_reconfig, target=target)
File "/curtin/curtin/commands/apt_config.py", line 133, in dpkg_reconfigure
  util.subp(['dpkg-reconfigure', '--frontend=noninteractive'] +
File "/curtin/curtin/util.py", line 275, in subp
  return _subp(*args, **kwargs)
 ^^
File "/curtin/curtin/util.py", line 139, in _subp
  raise ProcessExecutionError(stdout=out, stderr=err,
  curtin.util.ProcessExecutionError: Unexpected error while running command.
  Command: ['unshare', '--fork', '--pid', '--', 'chroot', 
'/tmp/tmpwr8y_4f8/target', 'dpkg-reconfigure', '--frontend=noninteractive', 
'cloud-init']
  Exit code: 1
  Reason: -
  Stdout: ''
  Stderr: Traceback (most recent call last):
File "", line 23, in 
  TypeError: load() missing 1 required positional argument: 'Loader'
  

  
  Ubuntu 23.04 Lunar has published PyYAML 6.0.1[1] which finally changed the 
signature on yaml.load to require a Loader= parameter.

  
  This traceback is due to a stale call to yaml.load() in 
cloud-init.postinst[2] that should have migrated to yaml.safe_load.

  In Jammy and and earlier, PyYAML was still emitting deprecation
  warning messages to stderr, but those warnings are silenced
  automatically by any invocation to `dpkg-reconfigure
  --frontend=noninteractive cloud-init`. So none of the warnings showed
  up in curtin or MAAS, until we got an explicit non-zero exit code.

  References:
  [1] Pyyaml 6.0.1 commit sync'd to lunar 
https://git.launchpad.net/ubuntu/+source/pyyaml/commit/?id=5308dbefbe5dc7ce4a19adbfdb4c4e08a798217d
  [2] yaml.load failure on Lunar: 
https://github.com/canonical/cloud-init/blob/ubuntu/devel/debian/cloud-init.postinst#L41

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2009746/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2003363] Re: Systemd-networkd generated configuration is wrong when both ipv4 and ipv6 addresses are used

[Brett Holman]

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/2003363

Title:
  Systemd-networkd generated configuration is wrong when both ipv4 and
  ipv6 addresses are used

Status in cloud-init:
  Fix Released

Bug description:
  We install the latest cloud-init 22.4.2-2, re-generating the new
  profile and the new network config file for systemd-networkd is
  something like

  root@arch /etc/systemd/network # cat 10-cloud-init-eth0.network 
  [Address]
  Address=192.0.2.2/24

  [Address]
  Address=2001:db8::2/48

  [Match]
  MACAddress=ea:3a:ec:46:79:8e
  Name=eth0

  [Network]
  DHCP=no
  DNS=8.8.8.8 8.8.4.4

  [Route]
  Gateway=192.0.2.1
  Gateway=2001:db8::1

  
  Only IPv6 is working, IPv4 is not working, there's no default route for IPv4, 
we need to change to

  [Route]
  Gateway=192.0.2.1

  [Route]
  Gateway=2001:db8::1

  
  Don't know if this is a bug from cloud-init or systemd-networkd

  The old bug https://bugs.launchpad.net/cloud-
  init/+bug/1973724?comments=all

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2003363/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1383510] Re: Documentation improvements needed

[Brett Holman]

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1383510

Title:
  Documentation improvements needed

Status in cloud-init:
  Fix Released

Bug description:
  1. Modules section is entirely empty.
  http://cloudinit.readthedocs.org/en/latest/topics/modules.html

  2. There's no "how to invoke" documentation. From the Arch Linux
  package, I can see that the following all appear to be valid
  invocations:

  cloud-init modules --mode=config
  cloud-init modules --mode=final
  cloud-init init --local
  cloud-init init

  But what might they all do?

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1383510/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1486113] Re: write_files runs before users/groups, renders "owner" useless

[Brett Holman]

This was resolved in the aforementioned pull request with the addition
of writing deferred files.

** Changed in: cloud-init
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1486113

Title:
  write_files runs before users/groups, renders "owner" useless

Status in cloud-init:
  Fix Released

Bug description:
  When the following cloud-init script is run the expectation is that a
  group called ssl-cert-client is created, and this group is applied to
  the file that is written via the "owner" tag.

  groups:
- ssl-cert-server
- ssl-cert-client
  write_files:
  - encoding: gzip
content: !!binary |
  $(echo ${rsa_client_private_key} | gzip - | openssl base64 | sed -e "s/^/
/")
owner: root:ssl-cert-client
path: /etc/ssl/certs/${resourcegroup}-${machine}.${domain}-client.key
permissions: '0640'

  What happens instead is that the writing of the file is attempted
  before the creation of the group, and this file write fails because
  the group ssl-cert-server does not yet exist.

  The two tasks need to be swapped round before they are practically
  useful.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1486113/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1521079] Re: can't install requirements by Makefile

[Brett Holman]

These targets no longer exist in the makefile, and these days we use tox
rather than the Makefile.

Closing

** Changed in: cloud-init
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1521079

Title:
  can't install requirements by Makefile

Status in cloud-init:
  Won't Fix

Bug description:
  `*requirements` target name is wrong, isn't it?.

  ```
  $ make pip-test-requirements
  make: Nothing to be done for 'pip-test-requirements'.

  $ make pip-test-requirements
  Installing cloud-init test dependencies...
  pip install -r "pip-test-requirements.txt" -q
  Could not open requirements file: [Errno 2] No such file or directory: 
'pip-test-requirements.txt'
  Makefile:30: recipe for target 'pip-test-requirements' failed
  make: *** [pip-test-requirements] Error 1
  ```

  Makefile
  ```
  pip-requirements:
  @echo "Installing cloud-init dependencies..."
  $(PIP_INSTALL) -r "$@.txt" -q

  pip-test-requirements:
  @echo "Installing cloud-init test dependencies..."
  $(PIP_INSTALL) -r "$@.txt" -q
  ```

  ```
  $ ls -l *requirements.txt
  -rw-r--r-- 1 vagrant vagrant 948 11月 30 15:12 requirements.txt
  -rw-r--r-- 1 vagrant vagrant  71 11月 30 15:12 test-requirements.txt
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1521079/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1720844] Re: UrlError from #include aborts stage

[Brett Holman]

Fixed in e10ad2d7854b87024b5d051db50166125fce2279

** Changed in: cloud-init
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1720844

Title:
  UrlError from #include aborts stage

Status in cloud-init:
  Fix Released

Bug description:
  If you have a bad URL or inaccessible server referenced in an #include
  document, a cloudinit.url_helper.UrlError is thrown which is not
  caught, so it aborts the stage and an instance can be left
  unconfigured.

  I've proposed a patch here:
  https://code.launchpad.net/~ajorgens/cloud-init/+git/cloud-
  init/+merge/331660

  Obviously a bad URL is not a great case, but aborting and leaving the
  instance unconfigured seems the worst choice in this scenario because
  it may not even be possible to log in to troubleshoot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1720844/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1845552] Re: ssh_util: fails to parse sshd_config when config contains an entry missing a value

[Brett Holman]

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1845552

Title:
  ssh_util: fails to parse sshd_config when config contains an entry
  missing a value

Status in cloud-init:
  Fix Released

Bug description:
  # Overview

  If the sshd_config contains keys with no values, cloud-init fails to
  parse the config. This results in a system that is inaccessible over
  ssh using pubkey authentication.

  # Steps to reproduce:

  1. Append the following content to /etc/ssh/sshd_config in a pristine
  Ubuntu cloud image:

  AllowUsers ubuntu
  AllowGroups ubuntu
  DenyUsers
  DenyGroups

  2. Boot the image with a cloud-config that injects an ssh key for the
  ubuntu user.

  3. Note the following error in the boot output:

  util.py[WARNING]: Applying ssh credentials failed!

  4. Attempt to login over ssh, note the pubkey authentication failure.

  # Cause of the issue

  In cloudinit/ssh_util.py, in parse_ssh_config_lines(), we attempt to
  parse each line of sshd_config. This function expects each line to be
  one of the following forms:

  # comment
  key value
  key=value

  If the line does not match one of these forms, we throw a ValueError.

  Instead, we could ignore the offending line:

  diff --git a/cloudinit/ssh_util.py b/cloudinit/ssh_util.py
  index 3f99b58c..ec5ef9fb 100644
  --- a/cloudinit/ssh_util.py
  +++ b/cloudinit/ssh_util.py
  @@ -304,7 +304,10 @@ def parse_ssh_config_lines(lines):
   try:
   key, val = line.split(None, 1)
   except ValueError:
  -key, val = line.split('=', 1)
  +try:
  +key, val = line.split('=', 1)
  +except ValueError:
  +continue
   ret.append(SshdConfigLine(line, key, val))
   return ret
   
  # Notes about debugging

  This issue was somewhat difficult to debug because the error message
  produced by cloud-init was not very useful. To dig in and find the
  actual issue, I modified cloudinit/config/cc_ssh.py to print the
  traceback:

  diff --git a/cloudinit/config/cc_ssh.py b/cloudinit/config/cc_ssh.py
  index fdd8f4d3..2b356a4c 100755
  --- a/cloudinit/config/cc_ssh.py
  +++ b/cloudinit/config/cc_ssh.py
  @@ -99,6 +99,7 @@ public keys.
   import glob
   import os
   import sys
  +import traceback
   
   from cloudinit.distros import ug_util
   from cloudinit import ssh_util
  @@ -213,8 +214,9 @@ def handle(_name, cfg, cloud, log, _args):
   keys.extend(cfgkeys)
   
   apply_credentials(keys, user, disable_root, disable_root_opts)
  -except Exception:
  -util.logexc(log, "Applying ssh credentials failed!")
  +except Exception as err:
  +util.logexc(log, "Applying ssh credentials failed: {}".format(err))
  +traceback.print_exc()
   
   
   def apply_credentials(keys, user, disable_root, disable_root_opts):

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1845552/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1785275] Re: cloud-init pre-networking fails if kernel cmdline defines static ip

[Brett Holman]

Fix released in 20.1

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1785275

Title:
  cloud-init pre-networking fails if kernel cmdline defines static ip

Status in cloud-init:
  Fix Released

Bug description:
  cloud-init pre-networking fails when grub is configured to use a
  static IP with the 'autoconf' field set to 'none'
  (https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt).

  Cloud provider: vsphere

  
  Static IP is configured here (/etc/default/grub).
  ---
  # https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
  # off or none: don't use autoconfiguration (do static IP assignment 
instead)
  GRUB_CMDLINE_LINUX=ip=10.121.105.37::10.121.104.1:255.255.252.0::eth0:none


  ---

  
  Error:
File "/usr/lib/python3/dist-packages/cloudinit/net/cmdline.py", line 58, in 
_klibc_to_config_entry  

  raise ValueError("Unexpected value for PROTO: %s" % proto)


  ValueError: Unexpected value for PROTO: none  

  
  Workarounds:
  Option 1. Change the grub config to use 'dhcp' even though it defines most of 
the fields statically
  GRUB_CMDLINE_LINUX=ip=10.121.105.37::10.121.104.1:255.255.252.0::eth0:dhcp

  Option 2. Patch to normalize 'none' to 'static' (I'd guess there's a more 
proper fix further up the call)
  --- /usr/lib/python3/dist-packages/cloudinit/net/cmdline.py.orig
2018-08-03 15:44:11.204005997 +
  +++ /usr/lib/python3/dist-packages/cloudinit/net/cmdline.py 2018-08-03 
15:44:15.448006149 +
  @@ -52,6 +52,8 @@
   else:
   proto = 'static'

  +if proto == 'none':
  +proto = 'static'
   if proto not in ('static', 'dhcp', 'dhcp6'):
   raise ValueError("Unexpected value for PROTO: %s" % proto)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1785275/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1740937] Re: Support Ansible

[Brett Holman]

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1740937

Title:
  Support Ansible

Status in cloud-init:
  Fix Released

Bug description:
  cloud-init already has support for Chef and Puppet (if I remember also
  for Salt). Would be nice support to execute playbooks in a elegant
  way,

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1740937/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1962150] Re: status symlink non-atomicity traceback with status --wait

[Brett Holman]

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1962150

Title:
  status symlink non-atomicity traceback with status --wait

Status in cloud-init:
  Fix Released

Bug description:
  MAAS run system-tests on a regular basis using LXD containers to set
  things up.

  A recent run failed waiting for the LXD container to finish booting,
  with a traceback from cloud-init.

  After launching the container, the script runs `timeout 2000 cloud-
  init status --wait --long` to ensure that the commands we pass through
  as user-data are complete.

  Here's a redacted snippet from the logs

   2022-02-23 17:21:00 INFO : Waiting for boot to finish...
   2022-02-23 17:21:00 INFO  timeout 2000 cloud-init status --wait --long
   2022-02-23 17:21:04 INFO ..
   2022-02-23 17:21:04 INFO Traceback (most recent call last):
   2022-02-23 17:21:04 INFO   File "/usr/bin/cloud-init", line 11, in 
   2022-02-23 17:21:04 INFO load_entry_point('cloud-init==21.4', 
'console_scripts', 'cloud-init')()
   2022-02-23 17:21:04 INFO   File 
"/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 927, in main
   2022-02-23 17:21:04 INFO retval = util.log_time(
   2022-02-23 17:21:04 INFO   File 
"/usr/lib/python3/dist-packages/cloudinit/util.py", line 2472, in log_time
   2022-02-23 17:21:04 INFO ret = func(*args, **kwargs)
   2022-02-23 17:21:04 INFO   File 
"/usr/lib/python3/dist-packages/cloudinit/cmd/status.py", line 60, in 
handle_status_args
   2022-02-23 17:21:04 INFO status, status_detail, time = 
_get_status_details(init.paths)
   2022-02-23 17:21:04 INFO   File 
"/usr/lib/python3/dist-packages/cloudinit/cmd/status.py", line 123, in 
_get_status_details
   2022-02-23 17:21:04 INFO status_v1 = 
load_json(load_file(status_file)).get('v1', {})
   2022-02-23 17:21:04 INFO   File 
"/usr/lib/python3/dist-packages/cloudinit/util.py", line 1361, in load_file
   2022-02-23 17:21:04 INFO with open(fname, 'rb') as ifh:
   2022-02-23 17:21:04 INFO FileNotFoundError: [Errno 2] No such file or 
directory: '/run/cloud-init/status.json'

  You can see from the ... that there are a few successful attempts to
  wait, but then it fails.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1962150/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1854863] Re: Can't fork over SSH

[Brett Holman]

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1854863

Title:
  Can't fork over SSH

Status in cloud-init:
  Fix Released

Bug description:
  https://github.com/canonical/cloud-init/pull/74

  I am unable to fork the cloud-init project over ssh or https.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1854863/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1889545] Re: cc_users_groups docs should note that its settings only apply to user creation (so have no effect on existing users)

[Brett Holman]

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1889545

Title:
  cc_users_groups docs should note that its settings only apply to user
  creation (so have no effect on existing users)

Status in cloud-init:
  Fix Released

Bug description:
  cloud-init does not create users that already exist in the system, for
  obvious reasons.  It is not obvious, however, that `users`
  configuration in cloud-config will only be honoured on user creation
  (see [0] for the code that skips existing users, as well as a comment
  from a developer who was perhaps also surprised by this).

  We should include a note in the docs to help people understand this.

  [0] https://github.com/canonical/cloud-
  
init/blob/a13febd286d21f1754e32f4a05e722039eb452b8/cloudinit/distros/__init__.py#L399-L401

  [Original Report]
  In https://cloudinit.readthedocs.io/en/latest/topics/examples.html (line 20)

  Does 'passwd' field in config file work?

  I tried with below config

  Content of cloud-config.ci
  ```
  hostname: dev-host

  users:
  - name: root
    lock-passwd: false
    passwd: $1$root$1fvaXuILgb4rdRlHdQ80N/

  ```

  And did - 'cloud-init --file ./cloud-config.ci init'

  I generated hash of password using below command:
  pass=(echo "password" |  openssl passwd -1 -stdin -salt root)
  And I don't see anything in logs regarding password.

  If I use plain_text_passwd or hashed_passwd in my config file, I see
  some log message about password.

  Attaching log tarball.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1889545/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1839854] Re: CloudStack provider cannot determine correct metadata IP with multiple network interfaces

[Brett Holman]

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1839854

Title:
  CloudStack provider cannot determine correct metadata IP with multiple
  network interfaces

Status in cloud-init:
  Fix Released

Bug description:
  [Problem]
  When mutliple network interfaces are present in a CloudStack VM, cloud-init 
randomly chooses the gateway address to fetch the metadata from. This is not a 
problem when all network interfaces offer metadata. However, if a shared 
network interface is attached to the VM the gateway on that interface doesn't 
have the metadata. Cloud-init will timeout waiting for response from the 
gateway and will not apply metadata to the host.

  [How to reproduce]
  - Create VM with 1x Isolated and 1x Shared Network
  - Ensure cloud-init is installed in the VM and CloudStack is configured as a 
metadata provider
  - Boot VM

  [Expected result]
  - VM should boot and apply metadata from cloudstack

  [Observed result]
  - cloud-init sometimes chooses wrong metadata server IP
  - cloud-init delays startup waiting for response
  - metadata isn't applied 
  - cloud-init service fails

  [Notes]
  I noticed that in "cloudinit/sources/DataSourceCloudStack.py" 
get_vr_address() the dhcp lease option is preferred over the default gateway. 
Wouldn't it be smarter to just always use "get_default_gateway()"?
  We used till recently cloud-init 0.7.5 but after the introduction of 
NetworkManager lease support  we started running into this problem. 
(https://github.com/cloud-init/cloud-init/commit/33816e96d8981918f734dab3ee1a967bce85451a#diff-5bc9de2bb7889d66205845400c7cf99bR182)
  Up to this point cloud-init has always used the default_gateway method.
  CentOS 7 has only recently updated cloud-init in it's repos, so we were stuck 
on this old version for a long time.

  Maybe it would be nice to have a configuration option to choose between the 
methods manually?
  Also it would be cool if on a fault cloud-init would choose the next possible 
dhcp lease.

  [Attachment]
  We added some files for debugging as a tar.gz.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1839854/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1799674] Re: tools/build-on-freebsd is outdated and can be dropped

[Brett Holman]

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1799674

Title:
  tools/build-on-freebsd is outdated and can be dropped

Status in cloud-init:
  Fix Released

Bug description:
  to quote the script:

  # Since there is no official FreeBSD port yet, we need some way of building 
and
  # installing cloud-init. This script takes care of building and installing. It
  # will optionally make a first run at the end.

  This comment is outdated. There *is* a package & port.
  It's fairly up-to-date, too!

  (i'm trying to get it *more* up-to-date! ;)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1799674/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1088101] Re: Please add informations in /doc/README,

[Brett Holman]

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1088101

Title:
  Please add informations in /doc/README,

Status in cloud-init:
  Fix Released

Bug description:
  Hello,

  there was a discussion about cloud-init on the « debian-cloud »
  mailing list, and one of the outcome was to suggest to add more
  documentation on how to use cloud-init in /doc/README, which is
  installed as « /usr/share/doc/cloud-init/README » on Debian systems
  and is therefore one of the first files one will read to better learn
  how to use cloud-init.

  https://lists.debian.org/debian-cloud/2012/12/msg00049.html

  In particular, the following information was suggested :

  > The way to use it without EC2 or OpenStack is documented in
  > doc/sources/nocloud/README
  > 
  > Basically, you put meta-data into
  > /var/lib/cloud/seed/nocloud/meta-data. This is described in
  > doc/examples/seed/. This file is where you set things like hostname and
  > install authorized_keys.
  > 
  > Then to do further system configuration a cloud-config stanza goes in
  > /var/lib/cloud/seed/nocloud/user-data
  > 
  > The capabilities of cloud-config are best discovered in
  > doc/examples/cloud-config.txt

  Have a nice Sunday,

  -- 
  Charles Plessy
  Tsurumi, Kanagawa, Japan

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1088101/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2089185] Re: Releasing fails with latest cloud-init on image 20241113

[Brett Holman]

Please gather the logs as described in [1] and report back.

Which image did this last succeed in?

I just linked the upstream bug and set the downstream bug to "invalid".

[1] https://docs.cloud-init.io/en/latest/howto/bugs.html#collect-logs

** Bug watch added: github.com/canonical/cloud-init/issues #5849
   https://github.com/canonical/cloud-init/issues/5849

** Also affects: cloud-init via
   https://github.com/canonical/cloud-init/issues/5849
   Importance: Unknown
   Status: Unknown

** Changed in: cloud-init (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/2089185

Title:
  Releasing fails with latest cloud-init on image 20241113

Status in cloud-init:
  Unknown
Status in MAAS:
  Invalid
Status in cloud-init package in Ubuntu:
  Invalid

Bug description:
  Hello,

  It seems a bug was introduced in the `20241113` Jammy image and now
  when we release a server with disk erasing, after the wipe-disks
  script finishes successfully, cloud-init fails and causes the server
  to go into a release failed state.

  Searching the internet, this issue seems to align with what I'm
  seeing: https://github.com/canonical/cloud-init/issues/5849

  See attached logs, where cloud-init fails with `failed stage modules-
  final`.

  I reviewed the cloud-config the server was getting and noticed the
  following:

  ```
  power_state:
condition: test ! -e /tmp/block-poweroff
delay: now
mode: poweroff
timeout: 3600
  ```

  If my understanding is correct, basically cloud-init finishes running
  the user script then powers off. After sending the power off signal,
  it starts the modules-final section which then is cancelled by the
  shutdown.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2089185/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp