[Yahoo-eng-team] [Bug 1876333] Re: Documentation: Add boot stage of execution to each module documentation
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3669 ** Bug watch added: github.com/canonical/cloud-init/issues #3669 https://github.com/canonical/cloud-init/issues/3669 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1876333 Title: Documentation: Add boot stage of execution to each module documentation Status in cloud-init: Expired Bug description: As a newcomer to cloud-init, the module documentation has been extremely helpful in laying out the options I can utilize. However, I often have to ask myself if i need to do something as a runcmd script rather than utilize a module, since the documentation doesn't clarify what boot stage (or stages as I've come to find out) a particular module is executed in. Proposal: Right after the summary of each module in the documentation, add a "Boot stages:" section. I think this will also help reinforce the concept of the 5 boot stages of cloud-init to newcomers, and that will indirectly make it easier to entice new contributors. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1876333/+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 1872124] Re: Please integrate ubuntu-drivers --gpgpu into Ubuntu Server
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3649 ** Bug watch added: github.com/canonical/cloud-init/issues #3649 https://github.com/canonical/cloud-init/issues/3649 ** Changed in: cloud-init Status: Incomplete => Expired -- 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/1872124 Title: Please integrate ubuntu-drivers --gpgpu into Ubuntu Server Status in cloud-init: Expired Status in MAAS: Incomplete Status in subiquity: Fix Released Status in ubuntu-drivers-common package in Ubuntu: New Status in ubuntu-meta package in Ubuntu: New Bug description: Could subiquity provide an option in the UI to install and execute ubuntu-drivers-common on the target? The use case I'm interested in is an "on-rails" installation of Nvidia drivers for servers being installed for deep learning workloads. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1872124/+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 1872133] Re: No documentation for IPv6 SLAAC
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3650 ** Bug watch added: github.com/canonical/cloud-init/issues #3650 https://github.com/canonical/cloud-init/issues/3650 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1872133 Title: No documentation for IPv6 SLAAC Status in cloud-init: Expired Bug description: Unfortunately there is absolutely no documentation about IPv6 with SLAAC/ auto configuration. DHCP and static is documented, but SLAAC is not. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1872133/+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 1874525] Re: Fetching additional cloud-init from object storage - such as S3
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3658 ** Bug watch added: github.com/canonical/cloud-init/issues #3658 https://github.com/canonical/cloud-init/issues/3658 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1874525 Title: Fetching additional cloud-init from object storage - such as S3 Status in cloud-init: Expired Bug description: Feature request: user-data in some cloud providers is limited to 16kb, even with compression is not enough sometimes. Adding option to fetching/loading cloud-init from remote object storage would greatly solve this problem (For example S3 bucket) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1874525/+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 1874527] Re: Wrong EC2 hostname set if DHCP Options Set has multiple domain-name
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3659 ** Bug watch added: github.com/canonical/cloud-init/issues #3659 https://github.com/canonical/cloud-init/issues/3659 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1874527 Title: Wrong EC2 hostname set if DHCP Options Set has multiple domain-name Status in cloud-init: Expired Bug description: Cloud Provider: AWS. Cloud-init v. 19.3-2.amzn2. Config says system_info: distro: amazon Per https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html the VPC DHCP Options set can have a domain-name value with multiple domain names separated by spaces. However, if using this approach, cloud-init sets an incorrect hostname. It appears to concatenate the unqualified host name to the Options Set host names without spaces, and truncating to a certain number of characters. This is with "set-hostname" and "update-hostname" modules enabled, but no other relevant cloud-init config. For example, if your unqualified hostname is ip-10-30-10-155 and your DHCP Options Set domain-name is "foo.bar.example.com baz.bat.example.com" you might get an incorrect hostname such as "ip-10-30-10-155.foo.bar.example.combaz.bat.ex" This problem appears to be due to misinterpretation of the output of the EC2 metadata service for "local-hostname", which responds with output similar to above, but with spaces retained and no truncating, for example: "ip-10-30-10-155.foo.bar.example.com baz.bat.example.com" The cloud-init log output also mentions this problem, for example you might have logs which look like: Mar 18 00:31:33 cloud-init[3825]: cc_set_hostname.py[DEBUG]: Setting the hostname to ip-10-30-10-155.us-west-2.i.test.abcdefg.example.com i.test.abcdefg.example.com us-west-2.test.abcdefg.example.com test.abcdefg.example.com us-west-2.compute.internal (ip-10-30-10-155) Mar 18 00:31:33 cloud-init[3825]: util.py[DEBUG]: Running command ['hostnamectl', 'set-hostname', 'ip-10-30-10-155.us-west-2.i.test.abcdefg.example.com i.test.abcdefg.example.com us-west-2.test.abcdefg.example.com test.abcdefg.example.com us-west-2.compute.internal'] with allowed return codes [0] (shell=False, capture=True) Mar 18 00:31:33 cloud-init[3825]: __init__.py[DEBUG]: Non-persistently setting the system hostname to ip-10-30-10-155.us-west-2.i.test.abcdefg.example.com i.test.abcdefg.example.com us-west-2.test.abcdefg.example.com test.abcdefg.example.com us-west-2.compute.internal Mar 18 00:31:33 cloud-init[3825]: util.py[DEBUG]: Running command ['hostname', 'ip-10-30-10-155.us-west-2.i.test.abcdefg.example.com i.test.abcdefg.example.com us-we st-2.test.abcdefg.example.com test.abcdefg.example.com us-west-2.compute.internal'] with allowed return codes [0] (shell=False, capture=True) Mar 18 00:31:33 cloud-init[3825]: util.py[WARNING]: Failed to non-persistently adjust the system hostname to ip-10-30-10-155.us-west-2.i.test.abcdefg.example.com i.te st.abcdefg.example.com us-west-2.test.abcdefg.example.com test.abcdefg.example.com us-west-2.compute.internal Mar 18 00:31:33 cloud-init[3825]: util.py[DEBUG]: Failed to non-persistently adjust the system hostname to ip-10-30-10-155.us-west-2.i.test.abcdefg.example.com i.test.abcdefg.example.com us-west-2.test.abcdefg.example.com test.abcdefg.example.com us-west-2.compute.internal Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/cloudinit/distros/__init__.py", line 230, in _apply_hostname util.subp(['hostname', hostname]) File "/usr/lib/python2.7/site-packages/cloudinit/util.py", line 2105, in subp cmd=args) ProcessExecutionError: Unexpected error while running command. Command: ['hostname', 'ip-10-30-10-155.us-west-2.i.test.abcdefg.example.com i.test.abcdefg.example.com us-west-2.test.abcdefg.example.com test.abcdefg.example.com us-west-2.compute.internal'] Exit code: 1 Reason: - Stdout: Stderr: hostname: the specified hostname is invalid To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1874527/+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 1871879] Re: Configuring a user should not configure root's authorized_keys
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3648 ** Bug watch added: github.com/canonical/cloud-init/issues #3648 https://github.com/canonical/cloud-init/issues/3648 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1871879 Title: Configuring a user should not configure root's authorized_keys Status in cloud-init: Expired Bug description: When `ssh_authorized_keys` is configured in user-data keys are unconditionally copied into /root/.ssh/authorized_keys. If `disable_root` is set to true it leaks the actual configured username: "Please login as the user XYZ rather than the user root." With `disable_root` set to false you can login. It would be great if there were a way to actually disable root and not touch it at all. I fully understand that the info message is useful for new users, but it would be great to have a way to leave root alone. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1871879/+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 1869181] Re: [Focal] cloud-init service never get nework actived during MaaS deploy.
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3635 ** Bug watch added: github.com/canonical/cloud-init/issues #3635 https://github.com/canonical/cloud-init/issues/3635 ** Changed in: cloud-init Status: Incomplete => Expired -- 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/1869181 Title: [Focal] cloud-init service never get nework actived during MaaS deploy. Status in cloud-init: Expired Status in OEM Priority Project: New Bug description: MaaS server used to wait for cloud-init on target reporting status. It works well on Bionic desktop but failed on Focal desktop. It might be caused by the ordering of systemd service because the network service always is started after the cloud-init service. Journalctl: 三 26 18:34:18 CANONICALID cloud-init[816]: Cloud-init v. 20.1-10-g71af48df-0ubuntu2 running 'init' at Thu, 26 Mar 2020 10:34:18 +. Up 6.59 seconds. 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: Net device info 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: +-+---+---+---+---+---+ 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: | Device | Up | Address |Mask | Scope | Hw-Address| 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: +-+---+---+---+---+---+ 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: | enx00e04c70045f | False | . | . | . | 00:e0:4c:70:04:5f | 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: |lo | True | 127.0.0.1 | 255.0.0.0 | host | . | 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: |lo | True | ::1/128 | . | host | . | 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: | wlp2s0 | False | . | . | . | 9c:b6:d0:8e:90:81 | 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: +-+---+---+---+---+---+ .[skip] 三 26 18:34:18 CANONICALID cloud-init[816]: 2020-03-26 10:34:18,361 - handlers.py[WARNING]: failed posting event: start: init-network/check-cache: attempting to read from cache [trust] .[skip] 三 26 18:36:25 CANONICALID systemd[1]: Starting Network Manager... To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1869181/+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 1870225] Re: ssh-key or random password
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3640 ** Bug watch added: github.com/canonical/cloud-init/issues #3640 https://github.com/canonical/cloud-init/issues/3640 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1870225 Title: ssh-key or random password Status in cloud-init: Expired Bug description: ssh-key or random password I'd like to setup my user with an ssh key, if there is one in metadata and no password auth / locked account (cannot ssh with passord, cannot login on tty with password). If no ssh key available, I want user with random password, and tty login available, and password based ssh available. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1870225/+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 1870310] Re: Explicit addition of a user's primary_group breaks the user creation
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3641 ** Bug watch added: github.com/canonical/cloud-init/issues #3641 https://github.com/canonical/cloud-init/issues/3641 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1870310 Title: Explicit addition of a user's primary_group breaks the user creation Status in cloud-init: Expired Bug description: $ multipass launch --cloud-init -
[Yahoo-eng-team] [Bug 1869277] Re: write-ssh-key-fingerprints writes to console as 'ec2'
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3636 ** Bug watch added: github.com/canonical/cloud-init/issues #3636 https://github.com/canonical/cloud-init/issues/3636 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1869277 Title: write-ssh-key-fingerprints writes to console as 'ec2' Status in cloud-init: Expired Bug description: The write-ssh-key-fingerprints writes to console as 'ec2' when it should use 'cloud-init' -- original description --- Azure VMs that are deployed sometimes show EC2 related output. This happens intermittently. Output of bug find is here: https://paste.ubuntu.com/p/nrWNYjzsXH/ To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1869277/+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 1871859] Re: cloud-init should write ssh_config.d/sshd_config.d snippets (when supported) instead of modifying config files
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3646 ** Bug watch added: github.com/canonical/cloud-init/issues #3646 https://github.com/canonical/cloud-init/issues/3646 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1871859 Title: cloud-init should write ssh_config.d/sshd_config.d snippets (when supported) instead of modifying config files Status in cloud-init: Expired Bug description: In OpenSSH 8.2[0], support for Include directives in ssh_config and sshd_config was introduced. In Debian/Ubuntu version 1:8.2p1-1 [1], Include directives were added to the config files shipped in the package (and in 1:8.2p1-4, the directories themselves were added). Where available, cloud-init should use these configuration directories for its configuration, instead of modifying ssh_config or sshd_config themselves. [0] https://www.openssh.com/txt/release-8.2 [1] https://launchpad.net/ubuntu/+source/openssh/1:8.2p1-1 [2] https://launchpad.net/ubuntu/+source/openssh/1:8.2p1-4 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1871859/+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 1871858] Re: cloud-init should support parsing ssh_config/sshd_config files with Include directives
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3645 ** Bug watch added: github.com/canonical/cloud-init/issues #3645 https://github.com/canonical/cloud-init/issues/3645 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1871858 Title: cloud-init should support parsing ssh_config/sshd_config files with Include directives Status in cloud-init: Expired Bug description: In OpenSSH 8.2[0], support for Include directives in ssh_config and sshd_config was introduced. In Debian/Ubuntu version 1:8.2p1-1 [1], Include directives were added to the config files shipped in the package (and in 1:8.2p1-4, the directories themselves were added). cloud-init should handle includes in its SSH configuration parsing, so that images mastered with configuration in the .d directories will behave consistently with other images. [0] https://www.openssh.com/txt/release-8.2 [1] https://launchpad.net/ubuntu/+source/openssh/1:8.2p1-1 [2] https://launchpad.net/ubuntu/+source/openssh/1:8.2p1-4 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1871858/+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 1868876] Re: instance-data in templates
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3632
** Bug watch added: github.com/canonical/cloud-init/issues #3632
https://github.com/canonical/cloud-init/issues/3632
** Changed in: cloud-init
Status: Triaged => Expired
--
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/1868876
Title:
instance-data in templates
Status in cloud-init:
Expired
Bug description:
Dear Team,
Could you make it possible to use instance-data variables in the
/etc/cloud/templates/* files like hosts.*.tmpl files?
I've tried to add a line like this:
{{ ds.meta_data.local_ipv4 }} {{fqdn}} {{hostname}}
but it's not working.
I'm using a custom openstack fork.
I'm not attaching logs, because it's not a bug, more like a feature-request.
Of course, cloud-init is great and I can do it with runcmd easily.
Thank you!
Andras
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1868876/+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 1869114] Re: cloud-init cannot create swap files on paths that it mounts
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3633 ** Bug watch added: github.com/canonical/cloud-init/issues #3633 https://github.com/canonical/cloud-init/issues/3633 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1869114 Title: cloud-init cannot create swap files on paths that it mounts Status in cloud-init: Expired Bug description: 1. cloud-init's swap module runs before the mount module, which causes swapfile creation on runtime mounted disks to fail. 2. cloud-init's swap create does not ensure it has a path to the file (if specified with a directory that does not exist yet). Bug exists in all clouds, but the bug was discovered through deploying an Azure VM, mounting the Azure resource disk, and then creating a swapfile within the mounted resource disk. Relevant logs: https://paste.ubuntu.com/p/QdGybC2wyc/ To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1869114/+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 1867933] Re: Invalid write_files format doesn't make the cloud-init fail
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3627 ** Bug watch added: github.com/canonical/cloud-init/issues #3627 https://github.com/canonical/cloud-init/issues/3627 ** Changed in: cloud-init Status: Confirmed => Expired -- 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/1867933 Title: Invalid write_files format doesn't make the cloud-init fail Status in cloud-init: Expired Bug description: If the cloud config file format is not correct (see example below), the write_files module fails, but the cloud-init status is done Cloud-config file: ``` #cloud-config write_files: - content: | line below is badly indented ouch! path: /tmp/cloud-init-file.txt ``` Extract of cloud-init-output.log ``` 2020-03-18 13:54:05,321 - util.py[WARNING]: Failed loading yaml blob. Invalid format at line 6 column 1: "while scanning a simple key in "", line 6, column 1: ouch! ^ could not found expected ':' in "", line 8, column 9: path: /tmp/cloud-init-file.txt ^" 2020-03-18 13:54:05,337 - util.py[WARNING]: Failed loading yaml blob. Invalid format at line 6 column 1: "while scanning a simple key in "", line 6, column 1: ouch! ^ could not found expected ':' in "", line 8, column 9: path: /tmp/cloud-init-file.txt ^" 2020-03-18 13:54:05,337 - util.py[WARNING]: Failed at merging in cloud config part from part-001 ``` cloud-init status: ``` status: done ``` To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1867933/+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 1865352] Re: cloud-init: Add support for certmonger
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3614 ** Bug watch added: github.com/canonical/cloud-init/issues #3614 https://github.com/canonical/cloud-init/issues/3614 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1865352 Title: cloud-init: Add support for certmonger Status in cloud-init: Expired Bug description: This is a request to integrate certmonger with cloud-init, such that certificates can be requested and provisioned as part of the initialisation process. Possible sample configuration: certs: Redwax Interop: type: scep url: http://interop.redwax.eu/test/simple/scep requests: - certificate: /etc/pki/interop/test.example.com.cert key: /etc/pki/interop/test.example.com.key key-type: rsa key-bits: 4096 and so on, corresponding to the following commands: getcert add-scep-ca -c "Redwax Interop" -u http://interop.redwax.eu/test/simple/scep getcert request -f /etc/pki/interop/test.example.com.cert -k /etc/pki/interop/test.example.com.key -c "Redwax Interop" -I test.example.com -D test.example.com -G rsa -g 4096 -u digitalSignature -u keyEncipherment -L challenge To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1865352/+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 1867151] Re: Can't run tests on CentOS 8 (missing py3 dependencies)
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3621 ** Bug watch added: github.com/canonical/cloud-init/issues #3621 https://github.com/canonical/cloud-init/issues/3621 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1867151 Title: Can't run tests on CentOS 8 (missing py3 dependencies) Status in cloud-init: Expired Bug description: The cloud-init test environment can't be set up on CentOS 8 due to missing Python 3 dependencies. The missing libraries are at least the following: - contextlib2 - unittest2 Of these unittest2 is available in the PowerTools repository as python3-unittest2, the other two are not. The PowerTools repository is currently added to the test system by the test helper scripts. For this reason the unit testing and CI testing is currently disabled on CentOS 8. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1867151/+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 1867197] Re: ec2: add support for rendering public IP addresses in network config
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3622
** Bug watch added: github.com/canonical/cloud-init/issues #3622
https://github.com/canonical/cloud-init/issues/3622
** Changed in: cloud-init
Status: Triaged => Expired
--
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/1867197
Title:
ec2: add support for rendering public IP addresses in network config
Status in cloud-init:
Expired
Bug description:
cloud-init 20.1 currently renders only local ip address information in
the network configuration emitted for attached NICs.
Ec2 instances can be launched and configured with multiple public IP
addresses
https://aws.amazon.com/blogs/aws/multiple-ip-addresses-for-
ec2-instances-in-a-virtual-private-cloud/
Ec2 IMDS network data exposes public IPv4 addresses in the following metadata
keys:
* network.interfaces.macs..public-ipv4s = "18.218.219.181"
* and an association of public ip to the private IPs allocated via the key
"ipv4-associations": {
"18.218.219.181": "172.31.44.13"
 },
Cloud-init should render known public ipv4 address configuration on the node
to avoid network round trips for local services that may connect with the VMs
known public IP
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1867197/+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 1860164] Re: cloud-init generates a traceback if a default route already exists during ephemeral network setup
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3595 ** Bug watch added: github.com/canonical/cloud-init/issues #3595 https://github.com/canonical/cloud-init/issues/3595 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1860164 Title: cloud-init generates a traceback if a default route already exists during ephemeral network setup Status in cloud-init: Expired Bug description: If a route already exists when the ephemeral network exists cloud-init will generate the following traceback: 2020-01-16 21:14:22,584 - util.py[DEBUG]: Getting data from failed Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/cloudinit/sources/__init__.py", line 760, in find_source if s.update_metadata([EventType.BOOT_NEW_INSTANCE]): File "/usr/lib/python2.7/site-packages/cloudinit/sources/__init__.py", line 649, in update_metadata result = self.get_data() File "/usr/lib/python2.7/site-packages/cloudinit/sources/__init__.py", line 273, in get_data return_value = self._get_data() File "/usr/lib/python2.7/site-packages/cloudinit/sources/DataSourceOracle.py", line 195, in _get_data with dhcp.EphemeralDHCPv4(net.find_fallback_nic()): File "/usr/lib/python2.7/site-packages/cloudinit/net/dhcp.py", line 57, in __enter__ return self.obtain_lease() File "/usr/lib/python2.7/site-packages/cloudinit/net/dhcp.py", line 109, in obtain_lease ephipv4.__enter__() File "/usr/lib/python2.7/site-packages/cloudinit/net/__init__.py", line 920, in __enter__ self._bringup_static_routes() File "/usr/lib/python2.7/site-packages/cloudinit/net/__init__.py", line 974, in _bringup_static_routes ['dev', self.interface], capture=True) File "/usr/lib/python2.7/site-packages/cloudinit/util.py", line 2083, in subp cmd=args) ProcessExecutionError: Unexpected error while running command. This is a regression from 19.1 on SUSE where exiting routes were simply skipped. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1860164/+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
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3600 ** Bug watch added: github.com/canonical/cloud-init/issues #3600 https://github.com/canonical/cloud-init/issues/3600 ** Changed in: cloud-init Status: Triaged => Expired -- 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: Triaged 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 1861460] Re: cloud-init should parse initramfs rendered netplan if present
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3602 ** Bug watch added: github.com/canonical/cloud-init/issues #3602 https://github.com/canonical/cloud-init/issues/3602 ** Changed in: cloud-init Status: In Progress => Expired -- 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/1861460 Title: cloud-init should parse initramfs rendered netplan if present Status in cloud-init: Expired Status in Ubuntu on IBM z Systems: Fix Released Status in casper package in Ubuntu: Fix Released Bug description: initramfs-tools used to only execute klibc based networking with some resolvconf hooks. In recent releases, it has been greatly improved to use isc-dhcp-client instead of klibc, support vlan= key (like in dracut-network), bring up Z devices using chzdev, and generate netplan yaml from all of the above. Above improvements were driven in part by Oracle Cloud and in part by Subiquity netbooting on Z. Thus these days, instead of trying to reparse klibc files in /run/net-*, cloud-init should simply import /run/netplan/$device.yaml files as the ip=* provided networking information on the command line. I do not currently see cloud-init doing that in e.g. /cloudinit/net/cmdline.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1861460/+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 1861903] Re: Mountpoint containing a space not working
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3603 ** Bug watch added: github.com/canonical/cloud-init/issues #3603 https://github.com/canonical/cloud-init/issues/3603 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1861903 Title: Mountpoint containing a space not working Status in cloud-init: Expired Bug description: If I want to mount a directory containing a space (for example to match a remote share name), it will not work currently with the default cc_mounts plugin. - if I surround the mountpoint with quotes, it will create the destination directory properly, but then /etc/fstab won't contain the quotes and the spaces will cause parsing error in /etc/fstab - If I use the common workaround of replacing spaces with \040, then the directory will contain a literal '\' and then '040', and the mountpoint won't be found because mount interprets the escape sequence properly. My suggestion: when outputting to /etc/fstab, escape spaces (and any other character part of fstab grammar) properly. This way the cloud- init config will just work. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1861903/+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 1863203] Re: [cloud-init] "/etc/resolv.conf" is out of control of netconfig after done cloud-init GOSC on SLES15SP1
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3606 ** Bug watch added: github.com/canonical/cloud-init/issues #3606 https://github.com/canonical/cloud-init/issues/3606 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1863203 Title: [cloud-init] "/etc/resolv.conf" is out of control of netconfig after done cloud-init GOSC on SLES15SP1 Status in cloud-init: Expired Bug description: [cloud-init] "/etc/resolv.conf" is out of control of netconfig after done cloud-init GOSC on SLES15SP1 Before GOSC, "/etc/resolv.conf" is link file "/run/netconfig/resolv.conf", in control by netconfig. After done cloud-init GOSC, this file become real file not link file, total different from "/run/netconfig/resolv.conf". cloud-init version is 19.4. ``` pek2-gosv-16-dhcp83:~ # cloud-init -v /usr/bin/cloud-init 19.4 ``` Before GOSC: ``` pek2-gosv-16-dhcp83:~ # ll /etc/resolv.conf lrwxrwxrwx 1 root root 26 Feb 10 23:33 /etc/resolv.conf -> /run/netconfig/resolv.conf ``` After GOSC: ``` pek2-gosv-16-dhcp83:~ # ll /etc/resolv.conf -rw-r--r-- 1 root root 153 Feb 11 09:46 /etc/resolv.conf pek2-gosv-16-dhcp83:~ # ll /run/netconfig/resolv.conf -rw-r--r-- 1 root root 707 Feb 14 06:10 /run/netconfig/resolv.conf ``` cloud-init.log is attached. Steps: 1. Deploy SLES15SP1 VM 2. Power off VM and Deploy GOSC ``` 2020-02-11 08:46:34,797 - config_file.py[DEBUG]: FOUND CATEGORY = 'NETWORK' 2020-02-11 08:46:34,797 - config_file.py[DEBUG]: ADDED KEY-VAL :: 'NETWORK|NETWORKING' = 'yes' 2020-02-11 08:46:34,797 - config_file.py[DEBUG]: ADDED KEY-VAL :: 'NETWORK|BOOTPROTO' = 'dhcp' 2020-02-11 08:46:34,797 - config_file.py[DEBUG]: ADDED KEY-VAL :: 'NETWORK|HOSTNAME' = 'gosc-dhcp-vm-01' 2020-02-11 08:46:34,797 - config_file.py[DEBUG]: ADDED KEY-VAL :: 'NETWORK|DOMAINNAME' = 'eng.vmware.com' ... ``` 3. Power on VM and check GOSC resolve, expect /etc/resolv.conf is still link to /run/netconfig/resolv.conf and DNS setting is saved into this file. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1863203/+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 1863792] Re: Permission denied: '/srv/citest' when running cloud tests locally
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3608 ** Bug watch added: github.com/canonical/cloud-init/issues #3608 https://github.com/canonical/cloud-init/issues/3608 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1863792 Title: Permission denied: '/srv/citest' when running cloud tests locally Status in cloud-init: Expired Bug description: The default configuration should work for developers, and therefore shouldn't assume write access to a directory that is (a) outside of the cloud-init tree, and (b) generally requires root privs to create in the first place. The specific error: 2020-02-18 18:11:21,652 - /home/daniel/dev/cloud-init/tests/cloud_tests/stage.py:run_stage:102 [ERROR]: stage: collect for platform: nocloud-kvm encountered error: [Errno 13] Permission denied: '/srv/citest' 2020-02-18 18:11:21,653 - /home/daniel/dev/cloud-init/tests/cloud_tests/stage.py:run_stage:104 [ERROR]: traceback: File "/home/daniel/dev/cloud-init/tests/cloud_tests/stage.py", line 97, in run_stage (call_res, call_failed) = call() File "/home/daniel/dev/cloud-init/tests/cloud_tests/collect.py", line 169, in collect_image with component as image: File "/home/daniel/dev/cloud-init/tests/cloud_tests/stage.py", line 27, in __enter__ self.instance = self.get_func() File "/home/daniel/dev/cloud-init/tests/cloud_tests/platforms/__init__.py", line 20, in get_image return platform.get_image(config) File "/home/daniel/dev/cloud-init/tests/cloud_tests/platforms/nocloudkvm/platform.py", line 53, in get_image tmirror.sync(smirror, path) File "/home/daniel/dev/cloud-init/.tox/citest/lib/python3.7/site-packages/simplestreams/mirrors/__init__.py", line 91, in sync return self.sync_index(reader, path, data, content) File "/home/daniel/dev/cloud-init/.tox/citest/lib/python3.7/site-packages/simplestreams/mirrors/__init__.py", line 254, in sync_index self.sync(reader, path=epath) File "/home/daniel/dev/cloud-init/.tox/citest/lib/python3.7/site-packages/simplestreams/mirrors/__init__.py", line 89, in sync return self.sync_products(reader, path, data, content) File "/home/daniel/dev/cloud-init/.tox/citest/lib/python3.7/site-packages/simplestreams/mirrors/__init__.py", line 405, in sync_products self.insert_products(path, target, content) File "/home/daniel/dev/cloud-init/.tox/citest/lib/python3.7/site-packages/simplestreams/mirrors/__init__.py", line 504, in insert_products self.store.insert_content(dpath, util.dump_data(target)) File "/home/daniel/dev/cloud-init/.tox/citest/lib/python3.7/site-packages/simplestreams/objectstores/__init__.py", line 40, in insert_content checksums=checksums, mutable=mutable) File "/home/daniel/dev/cloud-init/.tox/citest/lib/python3.7/site-packages/simplestreams/objectstores/__init__.py", line 110, in insert util.mkdir_p(out_d) File "/home/daniel/dev/cloud-init/.tox/citest/lib/python3.7/site-packages/simplestreams/util.py", line 420, in mkdir_p os.makedirs(path) File "/home/daniel/dev/cloud-init/.tox/citest/lib/python3.7/os.py", line 211, in makedirs makedirs(head, exist_ok=exist_ok) File "/home/daniel/dev/cloud-init/.tox/citest/lib/python3.7/os.py", line 211, in makedirs makedirs(head, exist_ok=exist_ok) File "/home/daniel/dev/cloud-init/.tox/citest/lib/python3.7/os.py", line 221, in makedirs mkdir(name, mode) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1863792/+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 1859720] Re: Document how to override vendor-data
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3593 ** Bug watch added: github.com/canonical/cloud-init/issues #3593 https://github.com/canonical/cloud-init/issues/3593 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1859720 Title: Document how to override vendor-data Status in cloud-init: Expired Bug description: the vendor data documentation: https://cloudinit.readthedocs.io/en/latest/topics/vendordata.html describes that we can override or disable vendor data, but does not explain how. this might be causing some confusion…? related? https://bugs.launchpad.net/cloud-init/+bug/1837530 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1859720/+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 1858865] Re: docs: update datasource rtd documentation for cloudstack
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3532 ** Bug watch added: github.com/canonical/cloud-init/issues #3532 https://github.com/canonical/cloud-init/issues/3532 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858865 Title: docs: update datasource rtd documentation for cloudstack Status in cloud-init: Expired Bug description: Update "read the docs" content at doc/rtd/topics/datasources/cloudstack.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceCloudStack.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858865/+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 1858864] Re: docs: update datasource rtd documentation for cloudsigma
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3531 ** Bug watch added: github.com/canonical/cloud-init/issues #3531 https://github.com/canonical/cloud-init/issues/3531 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858864 Title: docs: update datasource rtd documentation for cloudsigma Status in cloud-init: Expired Bug description: Update "read the docs" content at doc/rtd/topics/datasources/cloudsigma.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceCloudSigma.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858864/+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 1858866] Re: docs: update datasource rtd documentation for configdrive
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3533 ** Bug watch added: github.com/canonical/cloud-init/issues #3533 https://github.com/canonical/cloud-init/issues/3533 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858866 Title: docs: update datasource rtd documentation for configdrive Status in cloud-init: Expired Bug description: Update "read the docs" content at doc/rtd/topics/datasources/configdrive.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceConfigDrive.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858866/+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 1858867] Re: docs: update datasource rtd documentation for digitalocean
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3534 ** Bug watch added: github.com/canonical/cloud-init/issues #3534 https://github.com/canonical/cloud-init/issues/3534 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858867 Title: docs: update datasource rtd documentation for digitalocean Status in cloud-init: Expired Bug description: Update "read the docs" content at doc/rtd/topics/datasources/digitalocean.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceDigitalOcean.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858867/+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 1858868] Re: docs: update datasource rtd documentation for ec2
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3535 ** Bug watch added: github.com/canonical/cloud-init/issues #3535 https://github.com/canonical/cloud-init/issues/3535 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858868 Title: docs: update datasource rtd documentation for ec2 Status in cloud-init: Expired Bug description: Update "read the docs" content at doc/rtd/topics/datasources/ec2.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceEc2.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858868/+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 1858869] Re: docs: update datasource rtd documentation for exoscale
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3536 ** Bug watch added: github.com/canonical/cloud-init/issues #3536 https://github.com/canonical/cloud-init/issues/3536 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858869 Title: docs: update datasource rtd documentation for exoscale Status in cloud-init: Expired Bug description: Update "read the docs" content at doc/rtd/topics/datasources/exoscale.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceExoscale.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858869/+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 1858870] Re: docs: write datasource rtd documentation for hetzner
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3537 ** Bug watch added: github.com/canonical/cloud-init/issues #3537 https://github.com/canonical/cloud-init/issues/3537 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858870 Title: docs: write datasource rtd documentation for hetzner Status in cloud-init: Expired Bug description: Write "read the docs" content at doc/rtd/topics/datasources/hetzner.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceHetzner.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858870/+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 1858871] Re: docs: write datasource rtd documentation for maas
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3538 ** Bug watch added: github.com/canonical/cloud-init/issues #3538 https://github.com/canonical/cloud-init/issues/3538 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858871 Title: docs: write datasource rtd documentation for maas Status in cloud-init: Expired Bug description: Write "read the docs" content at doc/rtd/topics/datasources/maas.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceMAAS.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858871/+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 1858873] Re: docs: update datasource rtd documentation for openstack
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3540 ** Bug watch added: github.com/canonical/cloud-init/issues #3540 https://github.com/canonical/cloud-init/issues/3540 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858873 Title: docs: update datasource rtd documentation for openstack Status in cloud-init: Expired Bug description: Update "read the docs" content at doc/rtd/topics/datasources/openstack.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceOpenStack.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858873/+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 1858872] Re: docs: write datasource rtd documentation for ibmcloud
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3539 ** Bug watch added: github.com/canonical/cloud-init/issues #3539 https://github.com/canonical/cloud-init/issues/3539 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858872 Title: docs: write datasource rtd documentation for ibmcloud Status in cloud-init: Expired Bug description: Write "read the docs" content at doc/rtd/topics/datasources/ibmcloud.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceIBMCloud.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858872/+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 1858874] Re: docs: update datasource rtd documentation for oracle
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3541 ** Bug watch added: github.com/canonical/cloud-init/issues #3541 https://github.com/canonical/cloud-init/issues/3541 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858874 Title: docs: update datasource rtd documentation for oracle Status in cloud-init: Expired Bug description: Update "read the docs" content at doc/rtd/topics/datasources/oracle.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceOracle.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858874/+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 1858875] Re: docs: update datasource rtd documentation for ovf
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3542 ** Bug watch added: github.com/canonical/cloud-init/issues #3542 https://github.com/canonical/cloud-init/issues/3542 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858875 Title: docs: update datasource rtd documentation for ovf Status in cloud-init: Expired Bug description: Update "read the docs" content at doc/rtd/topics/datasources/ovf.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceOVF.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858875/+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 1858876] Re: docs: update datasource rtd documentation for smartos
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3543 ** Bug watch added: github.com/canonical/cloud-init/issues #3543 https://github.com/canonical/cloud-init/issues/3543 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858876 Title: docs: update datasource rtd documentation for smartos Status in cloud-init: Expired Bug description: Update "read the docs" content at doc/rtd/topics/datasources/smartos.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceSmartOS.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858876/+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 1858878] Re: docs: update datasource rtd documentation for opennebula
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3544 ** Bug watch added: github.com/canonical/cloud-init/issues #3544 https://github.com/canonical/cloud-init/issues/3544 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858878 Title: docs: update datasource rtd documentation for opennebula Status in cloud-init: Expired Bug description: Update "read the docs" content at: doc/rtd/topics/datasources/opennebula.rst Ensure it correctly represents behavior and configuration options in cloudinit/sources/DataSourceOpenNebula.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858878/+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 1858842] Re: docs: validate and update datasource GCE rtd doc content
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3527 ** Bug watch added: github.com/canonical/cloud-init/issues #3527 https://github.com/canonical/cloud-init/issues/3527 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858842 Title: docs: validate and update datasource GCE rtd doc content Status in cloud-init: Expired Bug description: Update "read the docs' content at cloud- init/doc/rtd/topics/datasources/gce.rst to ensure it correctly represents behavior and configuration options in cloud- init/cloudinit/sources/DataSourceGCE.py Example format/style should be something like: cloud-init/doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858842/+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 1858862] Re: docs: update datasource rtd documentation for altcloud
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3529 ** Bug watch added: github.com/canonical/cloud-init/issues #3529 https://github.com/canonical/cloud-init/issues/3529 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858862 Title: docs: update datasource rtd documentation for altcloud Status in cloud-init: Expired Bug description: Update "read the docs" content at doc/rtd/topics/datasources/altcloud.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceAltCloud.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858862/+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 1858861] Re: docs: update datasource rtd documentation for aliyun
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3528 ** Bug watch added: github.com/canonical/cloud-init/issues #3528 https://github.com/canonical/cloud-init/issues/3528 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858861 Title: docs: update datasource rtd documentation for aliyun Status in cloud-init: Expired Bug description: Update "read the docs" content at: doc/rtd/topics/datasources/aliyun.rst Ensure it correctly represents behavior and configuration options in cloudinit/sources/DataSourceAliYun.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858861/+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 1858863] Re: docs: update datasource rtd documentation for azure
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3530 ** Bug watch added: github.com/canonical/cloud-init/issues #3530 https://github.com/canonical/cloud-init/issues/3530 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1858863 Title: docs: update datasource rtd documentation for azure Status in cloud-init: Expired Bug description: Update "read the docs" content at doc/rtd/topics/datasources/azure.rst Ensure it correctly represents behavior and configuration options as used in: cloudinit/sources/DataSourceAzure.py Example format/style should be something like: doc/rtd/topics/datasources/ec2.rst To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858863/+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 1858808] Re: On SUSE mixed static and dhcp setups are no properly configured
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3526 ** Bug watch added: github.com/canonical/cloud-init/issues #3526 https://github.com/canonical/cloud-init/issues/3526 ** Changed in: cloud-init Status: In Progress => Expired -- 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/1858808 Title: On SUSE mixed static and dhcp setups are no properly configured Status in cloud-init: Expired Bug description: It should be possible to have a static IPv4 address and a DHCP IPv6 address and vice versa. This does not work on SUSE distributions as the "BOOTPROTO" setting in the generated ifcfg-* file is not correct. The BOOTPROTO setting should be dhcp - if both IPv6 and IPv4 configurations are expected to be supplied by a DHCP server dhcp4 - if IPv4 configuration is expected to be supplied by a DHCP server, IPv6 configuration can be static dhcp6 - IPv6 configuration is expected to be supplied by a DHCP server, IPv4 configuration can be static static - if both IPv6 and IPv4 configurations are defined, or if only one protocol is used and the IP is static To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1858808/+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 1855196] Re: RBXCloud has no dsname defined, so datasource cannot be properly detected.
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3512 ** Bug watch added: github.com/canonical/cloud-init/issues #3512 https://github.com/canonical/cloud-init/issues/3512 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1855196 Title: RBXCloud has no dsname defined, so datasource cannot be properly detected. Status in cloud-init: Expired Bug description: Each cloud-init datasource needs to define a dsname property. This property affects the instance-data.json platform_type presented for an instance (via cloud-init query --all) without this defined, cloud-init query will not properly identify this platform and the cloud may not be able to get selected via dpkg-reconfigure. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1855196/+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 1855432] Re: module cc_apt_configure must make sure gnupg is installed
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3514 ** Bug watch added: github.com/canonical/cloud-init/issues #3514 https://github.com/canonical/cloud-init/issues/3514 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1855432 Title: module cc_apt_configure must make sure gnupg is installed Status in cloud-init: Expired Bug description: when using the module cc_apt_configure we need to make sure that gnupg is installed before using apt-key add to add a certain apt key. The most recent debian 10 cloud image from https://cdimage.debian.org/cdimage/openstack/10.2.0/ is for example not really happy when using the below config: #cloud-config apt: http_proxy: http://10.0.0.2:3128/ https_proxy: http://10.0.0.2:3128/ sources: saltstack: source: "deb http://repo.saltstack.com/py3/debian/10/amd64/latest buster main" key: | -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v2 mQENBFOpvpgBCADkP656H41i8fpplEEB8IeLhugyC2rTEwwSclb8tQNYtUiGdna9 m38kb0OS2DDrEdtdQb2hWCnswxaAkUunb2qq18vd3dBvlnI+C4/xu5ksZZkRj+fW tArNR18V+2jkwcG26m8AxIrT+m4M6/bgnSfHTBtT5adNfVcTHqiT1JtCbQcXmwVw WbqS6v/LhcsBE//SHne4uBCK/GHxZHhQ5jz5h+3vWeV4gvxS3Xu6v1IlIpLDwUts kT1DumfynYnnZmWTGc6SYyIFXTPJLtnoWDb9OBdWgZxXfHEcBsKGha+bXO+m2tHA gNneN9i5f8oNxo5njrL8jkCckOpNpng18BKXABEBAAG0MlNhbHRTdGFjayBQYWNr YWdpbmcgVGVhbSA8cGFja2FnaW5nQHNhbHRzdGFjay5jb20+iQE4BBMBAgAiBQJT qb6YAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAOCKFJ3le/vhkqB/0Q WzELZf4d87WApzolLG+zpsJKtt/ueXL1W1KA7JILhXB1uyvVORt8uA9FjmE083o1 yE66wCya7V8hjNn2lkLXboOUd1UTErlRg1GYbIt++VPscTxHxwpjDGxDB1/fiX2o nK5SEpuj4IeIPJVE/uLNAwZyfX8DArLVJ5h8lknwiHlQLGlnOu9ulEAejwAKt9CU 4oYTszYM4xrbtjB/fR+mPnYh2fBoQO4d/NQiejIEyd9IEEMd/03AJQBuMux62tjA /NwvQ9eqNgLw9NisFNHRWtP4jhAOsshv1WW+zPzu3ozoO+lLHixUIz7fqRk38q8Q 9oNR31KvrkSNrFbA3D89uQENBFOpvpgBCADJ79iH10AfAfpTBEQwa6vzUI3Eltqb 9aZ0xbZV8V/8pnuU7rqM7Z+nJgldibFk4gFG2bHCG1C5aEH/FmcOMvTKDhJSFQUx uhgxttMArXm2c22OSy1hpsnVG68G32Nag/QFEJ++3hNnbyGZpHnPiYgej3FrerQJ zv456wIsxRDMvJ1NZQB3twoCqwapC6FJE2hukSdWB5yCYpWlZJXBKzlYz/gwD/Fr GL578WrLhKw3UvnJmlpqQaDKwmV2s7MsoZogC6wkHE92kGPG2GmoRD3ALjmCvN1E PsIsQGnwpcXsRpYVCoW7e2nW4wUf7IkFZ94yOCmUq6WreWI4NggRcFC5ABEBAAGJ AR8EGAECAAkFAlOpvpgCGwwACgkQDgihSd5Xv74/NggA08kEdBkiWWwJZUZEy7cK WWcgjnRuOHd4rPeT+vQbOWGu6x4bxuVf9aTiYkf7ZjVF2lPn97EXOEGFWPZeZbH4 vdRFH9jMtP+rrLt6+3c9j0M8SIJYwBL1+CNpEC/BuHj/Ra/cmnG5ZNhYebm76h5f T9iPW9fFww36FzFka4VPlvA4oB7ebBtquFg3sdQNU/MmTVV4jPFWXxh4oRDDR+8N 1bcPnbB11b5ary99F/mqr7RgQ+YFF0uKRE3SKa7a+6cIuHEZ7Za+zhPaQlzAOZlx fuBmScum8uQTrEF5+Um5zkwC7EXTdH1co/+/V/fpOtxIg4XO4kcugZefVm5ERfVS MA== =dtMN -END PGP PUBLIC KEY BLOCK- It will then throw the following errors: [ 21.870823] cloud-init[494]: 2019-12-06 11:26:16,967 - cc_apt_configure.py[ERROR]: failed to add apt GPG Key to apt keyring [ 21.875126] cloud-init[494]: Traceback (most recent call last): [ 21.877629] cloud-init[494]: File "/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_configure.py", line 551, in add_apt_key_raw [ 21.881435] cloud-init[494]: util.subp(['apt-key', 'add', '-'], data=key.encode(), target=target) [ 21.884155] cloud-init[494]: File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2027, in subp [ 21.886831] cloud-init[494]: cmd=args) [ 21.888611] cloud-init[494]: cloudinit.util.ProcessExecutionError: Unexpected error while running command. [ 21.891311] cloud-init[494]: Command: ['apt-key', 'add', '-'] [ 21.893090] cloud-init[494]: Exit code: 255 [ 21.894566] cloud-init[494]: Reason: - [ 21.895819] cloud-init[494]: Stdout: [ 21.897109] cloud-init[494]: Stderr: E: gnupg, gnupg2 and gnupg1 do not seem to be installed, but one of them is required for this operation [ 21.899870] cloud-init[494]: 2019-12-06 11:26:16,973 - util.py[WARNING]: Running module apt-configure () failed To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1855432/+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 1857031] Re: cloud-init fails to configure network interfaces running with OpenStack cloud
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3523 ** Bug watch added: github.com/canonical/cloud-init/issues #3523 https://github.com/canonical/cloud-init/issues/3523 ** Changed in: cloud-init Status: Incomplete => Expired -- 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/1857031 Title: cloud-init fails to configure network interfaces running with OpenStack cloud Status in cloud-init: Expired Status in OpenStack Compute (nova): Invalid Bug description: cloud-init 18.5: Node has 3 interfaces: -enp5s0f0 - not connected -enp5s0f1 - connected -ib0 - an HFI port Centos7.6 running on the node. Openstack boots the server with two interfaces enp5s0f1 and ib0 and it is successful but the node is not reachable. On the node, the cloud- init configures the wrong interface enp5s0f0. It is because cloud-init fails to configure network interfaces running with OpenStack cloud if any of the network interfaces don't exist on the node. In this case, ib0 was missing. Please note that when I try to boot the server with only 1 interface enp5s0f1, everything works fine and the node is reachable too. Logs: http://paste.openstack.org/show/787707/ network-data and nics: http://paste.openstack.org/show/787797/ (note that enp5s0f1 is manually configured) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1857031/+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 1854994] Re: git push to launchpad branch results in git push produces "remote error: Unexpected Zope exception"
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3509 ** Bug watch added: github.com/canonical/cloud-init/issues #3509 https://github.com/canonical/cloud-init/issues/3509 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1854994 Title: git push to launchpad branch results in git push produces "remote error: Unexpected Zope exception" Status in cloud-init: Expired Bug description: I've been trying to follow the steps highlighted here: https://cloudinit.readthedocs.io/en/19.3/topics/hacking.html to push a branch of cloud-init to by launchpad account, in order to link it to my github account. Basically running: git clone https://git.launchpad.net/cloud-init cd cloud-init git remote add USER ssh://u...@git.launchpad.net/~USER/cloud-init git push USER master With the last command timing out with "remote error: Unexpected Zope exception". Both git 2.13 and git 2.17 produced the same outcome. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1854994/+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 1853441] Re: sed expression in tools/tox-venv is not POSIX compatible
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3501
** Bug watch added: github.com/canonical/cloud-init/issues #3501
https://github.com/canonical/cloud-init/issues/3501
** Changed in: cloud-init
Status: Triaged => Expired
--
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/1853441
Title:
sed expression in tools/tox-venv is not POSIX compatible
Status in cloud-init:
Expired
Bug description:
When running tools/tox-venv py3 on FreeBSD, I get the following Error:
sed: 2: ":x; /\\$/ { N; s/\\\n[ ...": unused label 'x; /\\$/ { N;
s/\\\n[ ]*//; tx };'
This suggests to me, that the expression
sed -e ':x; /\\$/ { N; s/\\\n[ ]*//; tx };' "${tox_ini}" |
is not POSIX compatible.
Looking at GNU sed's documentation, I see the first issue with making
this expression POSIX compliant will be that `N` behaves intentionally
different on GNU sed than on POSIX:
https://www.gnu.org/software/sed/manual/html_node/Reporting-
Bugs.html#Reporting-Bugs
So the solution here might be simply to require GNU sed, and put it's
path/name into an environment variable that can be overriden from the
outside.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1853441/+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 1850310] Re: Debian 10/9/8 DNS configuration bug
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3486 ** Bug watch added: github.com/canonical/cloud-init/issues #3486 https://github.com/canonical/cloud-init/issues/3486 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1850310 Title: Debian 10/9/8 DNS configuration bug Status in cloud-init: Expired Bug description: I use cloud-init with NoCloud data source for configuring my VM's and got strange bug with DNS configuration on official Debian images like https://cdimage.debian.org/cdimage/openstack/current-10/debian-10-openstack- amd64.qcow2. My network config: ``` version: 2 ethernets: eth0: set-name: eth0 match: macaddress: addresses: [ ] gateway4: nameservers: addresses: [8.8.8.8,8.8.4.4] ``` After creating new VM I got next configuration in /etc/network/interfaces.d/50-cloud-init.cfg which is seems ok: ``` auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 10.52.240.11/16 dns-nameservers 8.8.8.8 8.8.4.4 gateway 10.52.1.1 ``` But /etc/resolv.conf contains: ``` nameserver 127.0.0.1 ``` Which leads to the fact that I can’t resolve any domain name, for example: ``` # ping google.com ping: google.com: Temporary failure in name resolution ``` To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1850310/+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 1848471] Re: No infiniband support in netplan renderer
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3474 ** Bug watch added: github.com/canonical/cloud-init/issues #3474 https://github.com/canonical/cloud-init/issues/3474 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1848471 Title: No infiniband support in netplan renderer Status in cloud-init: Expired Status in MAAS: Invalid Status in netplan: Fix Released Status in netplan.io package in Ubuntu: Fix Released Bug description: Infiniband support has been added to both the sysconfig and eni renderers (at time of writing, eni support is unmerged from https://code.launchpad.net/~darren-birkett/cloud-init/+git/cloud- init/+merge/373759). We need to add support to the netplan renderer too, but at this time netplan itself does not support the long form HWADDR that IB devices have. Once that is added, we should add support for infiniband devices in netplan too. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1848471/+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 1847583] Re: netplan configuration not re-generated
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3463
** Bug watch added: github.com/canonical/cloud-init/issues #3463
https://github.com/canonical/cloud-init/issues/3463
** Changed in: cloud-init
Status: Triaged => Expired
--
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/1847583
Title:
netplan configuration not re-generated
Status in cloud-init:
Expired
Bug description:
via https://bugs.launchpad.net/cloud-init/+bug/1846535/comments/40
steps to reproduce: (ec2/gcp/azure all have the same issue)
* start a ubuntu 18.04 instance
* update cloud-init to `19.2-36-g059d049c-0ubuntu2~18.04.1`
cloud-init-output.log
```
Cloud-init v. 19.2-36-g059d049c-0ubuntu1~18.04.1 running 'init-local' at Thu,
10 Oct 2019 08:33:00 +. Up 11.53 seconds.
Cloud-init v. 19.2-36-g059d049c-0ubuntu1~18.04.1 running 'init' at Thu, 10
Oct 2019 08:33:03 +. Up 14.77 seconds.
ci-info: ++Net device
info++
ci-info:
++--++---++---+
ci-info: | Device | Up | Address | Mask | Scope
| Hw-Address|
ci-info:
++--++---++---+
ci-info: | ens5 | True | 172.31.18.122| 255.255.240.0 |
global | 02:a8:af:c9:34:90 |
ci-info: | ens5 | True | fe80::a8:afff:fec9:3490/64 | . | link
| 02:a8:af:c9:34:90 |
ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | host
| . |
ci-info: | lo | True | ::1/128 | . | host
| . |
ci-info:
++--++---++---+
ci-info: ++Route IPv4
info++
ci-info:
+---+-+-+-+---+---+
ci-info: | Route | Destination | Gateway | Genmask | Interface |
Flags |
ci-info:
+---+-+-+-+---+---+
ci-info: | 0 | 0.0.0.0 | 172.31.16.1 | 0.0.0.0 |ens5 |
UG |
ci-info: | 1 | 172.31.16.0 | 0.0.0.0 | 255.255.240.0 |ens5 |
U |
ci-info: | 2 | 172.31.16.1 | 0.0.0.0 | 255.255.255.255 |ens5 |
UH |
ci-info:
+---+-+-+-+---+---+
ci-info: +++Route IPv6 info+++
ci-info: +---+-+-+---+---+
ci-info: | Route | Destination | Gateway | Interface | Flags |
ci-info: +---+-+-+---+---+
ci-info: | 1 | fe80::/64 |:: |ens5 | U |
ci-info: | 3 |local|:: |ens5 | U |
ci-info: | 4 | ff00::/8 |:: |ens5 | U |
ci-info: +---+-+-+---+---+
Generating public/private rsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
root@ip-172-31-18-122:~# networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 ens5 ether routableconfigured
2 links listed.
root@ip-172-31-18-122:~# cat /etc/netplan/50-cloud-init.yaml
# 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}
network:
version: 2
ethernets:
ens5:
dhcp4: true
dhcp6: true
match:
macaddress: 02:a8:af:c9:34:90
set-name: ens5
```
* update packages and install kernel 5.3.5
* create a image of the now running instance
* start a instance from the image
* unable to connect
* stop the instance
* mount the disk to another running instance
mounting the disk to another instance, one can see that the netplan
configuration was not updated
```
Cloud-init v. 19.2-36-g059d049c-0ubuntu1~18.04.1 running 'modules:config' at
Thu, 10 Oct 2019 08:53:35 +. Up 24.40 seconds.
Cloud-init v. 19.2-36-g059d049c-0ubuntu1~18.04.1 running 'modules:final' at
Thu, 10 Oct 2019 08:53:36 +. Up 25.32 seconds.
Cloud-init v. 19.2-36-g059d049c-0ubuntu1~18.04.1 finished at Thu, 10 Oct 2019
08:53:36 +. Datasource DataSourceEc2Local. Up 25.43 seconds
Cloud-init v. 19.2-36-g059d049c-0ubuntu2~18.04.1 running 'init-local' at Thu,
10 Oct 2019 09:15:51
[Yahoo-eng-team] [Bug 1845252] Re: Azure data source assumes network is driven via dhcpclient
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3451
** Bug watch added: github.com/canonical/cloud-init/issues #3451
https://github.com/canonical/cloud-init/issues/3451
** Changed in: cloud-init
Status: Triaged => Expired
--
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/1845252
Title:
Azure data source assumes network is driven via dhcpclient
Status in cloud-init:
Expired
Bug description:
The Azure data source assumes that the network is set up by
dhcpclient. During cloud-init initialization the following traceback
is generated:
Traceback (most recent call last):
File
"/usr/lib/python3.6/site-packages/cloudinit/sources/DataSourceAzure.py", line
668, in _negotiate
fabric_data = metadata_func()
File "/usr/lib/python3.6/site-packages/cloudinit/sources/helpers/azure.py",
line 36, in impl
return func(*args, **kwargs)
File "/usr/lib/python3.6/site-packages/cloudinit/sources/helpers/azure.py",
line 458, in get_metadata_from_fabric
return shim.register_with_azure_and_fetch_data(pubkey_info=pubkey_info)
File "/usr/lib/python3.6/site-packages/cloudinit/sources/helpers/azure.py",
line 36, in impl
return func(*args, **kwargs)
File "/usr/lib/python3.6/site-packages/cloudinit/sources/helpers/azure.py",
line 393, in register_with_azure_and_fetch_data
'http://{0}/machine/?comp=goalstate'.format(self.endpoint))
File "/usr/lib/python3.6/site-packages/cloudinit/sources/helpers/azure.py",
line 272, in endpoint
self.dhcpoptions)
File "/usr/lib/python3.6/site-packages/cloudinit/sources/helpers/azure.py",
line 36, in impl
return func(*args, **kwargs)
File "/usr/lib/python3.6/site-packages/cloudinit/sources/helpers/azure.py",
line 374, in find_endpoint
fallback_lease_file)
File "/usr/lib/python3.6/site-packages/cloudinit/sources/helpers/azure.py",
line 36, in impl
return func(*args, **kwargs)
File "/usr/lib/python3.6/site-packages/cloudinit/sources/helpers/azure.py",
line 300, in _get_value_from_leases_file
content = util.load_file(fallback_lease_file)
File "/usr/lib/python3.6/site-packages/cloudinit/util.py", line 1359, in
load_file
with open(fname, 'rb') as ifh:
FileNotFoundError: [Errno 2] No such file or directory:
'/var/lib/dhcp/dhclient.eth0.leases'
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1845252/+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 1845401] Re: unit tests escapes on mac os
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3452 ** Bug watch added: github.com/canonical/cloud-init/issues #3452 https://github.com/canonical/cloud-init/issues/3452 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1845401 Title: unit tests escapes on mac os Status in cloud-init: Expired Bug description: https://pastebin.ubuntu.com/p/VP8zzPFkWh/ I've been developing integration tests for Azure and when running the tests on mac book pro a ton of tests escape. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1845401/+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 1841631] Re: cloud-init.service has no timeout
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3438 ** Bug watch added: github.com/canonical/cloud-init/issues #3438 https://github.com/canonical/cloud-init/issues/3438 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1841631 Title: cloud-init.service has no timeout Status in cloud-init: Expired Bug description: cloud-init's systemd service file (cloud-init.service) currently has not timeout; it explicitly sets: TimeoutSec=0 which, while not explicitly documented in systemd-service(5), appears to disable the timeout logic. This may cause the boot process to get stuck, while the system could possibly reach a useful state even if cloud-init failed. We hit this on a headless server: cloud-init got stuck and this prevented systemd to reach the point where systemd-getty-generator would have spawned a getty on the serial line, allowing the server to be accessed remotely. As a result we've got locked out of the server, which had to re rebooted in single-user mode. A cloud-init timeout would have prevented this. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1841631/+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 1842752] Re: Additional traceback in logs when using DataSourceOpenStackLocal on Oracle
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3441 ** Bug watch added: github.com/canonical/cloud-init/issues #3441 https://github.com/canonical/cloud-init/issues/3441 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1842752 Title: Additional traceback in logs when using DataSourceOpenStackLocal on Oracle Status in cloud-init: Expired Bug description: With the introduction of DHCP classless static route parsing in our ephemeral DHCP code, we've started seeing an additional traceback on Oracle during DataSourceOpenStackLocal: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 760, in find_source if s.update_metadata([EventType.BOOT_NEW_INSTANCE]): File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 649, in update_metadata result = self.get_data() File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 273, in get_data return_value = self._get_data() File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceOpenStack.py", line 130, in _get_data with EphemeralDHCPv4(self.fallback_interface): File "/usr/lib/python3/dist-packages/cloudinit/net/dhcp.py", line 57, in __enter__ return self.obtain_lease() File "/usr/lib/python3/dist-packages/cloudinit/net/dhcp.py", line 106, in obtain_lease ephipv4.__enter__() File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 773, in __enter__ self._bringup_static_routes() File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 827, in _bringup_static_routes ['dev', self.interface], capture=True) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2069, in subp cmd=args) cloudinit.util.ProcessExecutionError: Unexpected error while running command. Command: ['ip', '-4', 'route', 'add', '0.0.0.0/0', 'via', '10.0.0.1', 'dev', 'ens3'] Exit code: 2 Reason: - Stdout: Stderr: RTNETLINK answers: File exists This happens because the routes that are being applied have already been applied during iSCSI root configuration in the initramfs. There is no functional regression as a result; DataSourceOpenstack runs during the network phase and performs instance configuration as expected. (This is Low priority because it has limited impact, and we will soon be transitioning to use DataSourceOracle in Ubuntu, which does not exhibit this issue.) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1842752/+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 1843602] Re: cloud-init collect logs needs to defer to distro for debug data
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3447
** Bug watch added: github.com/canonical/cloud-init/issues #3447
https://github.com/canonical/cloud-init/issues/3447
** Changed in: cloud-init
Status: Triaged => Expired
--
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/1843602
Title:
cloud-init collect logs needs to defer to distro for debug data
Status in cloud-init:
Expired
Bug description:
While triaging a bug in sles'based distro using cloud-init, the
collect-logs output had a few issues:
1) the user did not have systemd journal privs
Unexpected error while running command.
Command: ['journalctl', '--boot=0', '-o', 'short-precise']
Exit code: 1
Reason: -
Stdout:
Stderr: Hint: You are currently not seeing messages from other users and the
system.
Users in the 'systemd-journal' group can see all messages. Pass
-q to
turn off this notice.
No journal files were opened due to insufficient permissions.
2) we tried to collect dpkg-version on a non debian distro
Unexpected error while running command.
Command: ['dpkg-query', '--show', '-f=${Version}\n', 'cloud-init']
Exit code: -
Reason: [Errno 2] No such file or directory
Stdout: -
Stderr: -
3) version file is empty
4) dmesg as non-root user fails
Unexpected error while running command.
Command: ['dmesg']
Exit code: 1
Reason: -
Stdout:
Stderr: dmesg: read kernel buffer failed: Operation not permitted
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1843602/+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 1843686] Re: Gentoo generates broken network config
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3449
** Bug watch added: github.com/canonical/cloud-init/issues #3449
https://github.com/canonical/cloud-init/issues/3449
** Changed in: cloud-init
Status: Triaged => Expired
--
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/1843686
Title:
Gentoo generates broken network config
Status in cloud-init:
Expired
Bug description:
As the title says, Gentoo generates an unusable network config. In
includes 'mac_eth0' although no such thing was specified. Also, it
adds the unnecessary 'netmask' keyword in the config.
The network-config (/var/lib/cloud/seed/nocloud-net/network-config):
#cloud-config
version: 1
config:
- type: physical
name: eth0
subnets:
- type: static
address: 1.2.3.4/24
gateway: 1.2.3.1
dns_nameservers:
- 1.2.3.10
The broken result (/etc/conf.d/net.eth0):
config_eth0="1.2.3.4/24 netmask None"
mac_eth0="None"
routes_eth0="default via 1.2.3.1"
dns_servers_eth0="('1.2.3.10')"
A correctly working config would be:
config_eth0="1.2.3.4/24"
routes_eth0="default via 1.2.3.1"
dns_servers_eth0="('1.2.3.10')"
I'd be great if this could be fixed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1843686/+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 1840269] Re: The kernel cmd parameter "cloud-init=disabled" is not considered
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3430 ** Bug watch added: github.com/canonical/cloud-init/issues #3430 https://github.com/canonical/cloud-init/issues/3430 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1840269 Title: The kernel cmd parameter "cloud-init=disabled" is not considered Status in cloud-init: Expired Bug description: cloud-init v.19.2 doesn't consider the "cloud-init=disabled" kernel command line parameter in CentOS7 The output of 'cloud-init collect-logs' is attached. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1840269/+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 1838221] Re: OVF property description references Scott Moser's private HTTP server
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3414 ** Bug watch added: github.com/canonical/cloud-init/issues #3414 https://github.com/canonical/cloud-init/issues/3414 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1838221 Title: OVF property description references Scott Moser's private HTTP server Status in cloud-images: New Status in cloud-init: Expired Status in Canonical Juju: Confirmed Status in livecd-rootfs package in Ubuntu: New Bug description: The OVF file[0] that ends up on cloud-images.ubuntu.com within the OVA[1] as an official build references Scott Moser's private web server as a recommended source of seed data. The references That server is HTTP-only and Scott is no longer at Canonical. Here are the URLs that are referred to: http://smoser.brickies.net/ubuntu/uec-seed/meta-data http://smoser.brickies.net/ubuntu/uec-seed/user-data [0] https://git.launchpad.net/cloud-init/tree/doc/sources/ovf/example/ubuntu-server.ovf#n34 [1] https://cloud-images.ubuntu.com To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1838221/+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 1838092] Re: Add documentation for ds-identify configuration
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3413 ** Bug watch added: github.com/canonical/cloud-init/issues #3413 https://github.com/canonical/cloud-init/issues/3413 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1838092 Title: Add documentation for ds-identify configuration Status in cloud-init: Expired Bug description: When working through bug 1837927, I had to go read the header (and actual source code) of ds-identify to determine what the correct configuration to apply was. We should include the ds-identify configuration options in the regular cloud-init documentation. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1838092/+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 1838564] Re: cloud-init's initramfs handling should support dracut
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3415 ** Bug watch added: github.com/canonical/cloud-init/issues #3415 https://github.com/canonical/cloud-init/issues/3415 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1838564 Title: cloud-init's initramfs handling should support dracut Status in cloud-init: Expired Bug description: Currently, cloud-init has support for generating network configuration from the /run/net-* files that klibc writes out if it performs network configuration in the initramfs. To better support iSCSI root for distributions that use dracut for their initramfs, we should implement support for handling its network configuration data. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1838564/+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 1839061] Re: Wrong access permissions of authorized keys directory when using root-owned location
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3417 ** Bug watch added: github.com/canonical/cloud-init/issues #3417 https://github.com/canonical/cloud-init/issues/3417 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1839061 Title: Wrong access permissions of authorized keys directory when using root- owned location Status in cloud-init: Expired Bug description: When using a central, root-owned directory to store ssh keys, cloud- init changes the permissions of the key directory which renders the keys unusable. I'm using a similar approach as described here: https://www.ssh.com/ssh/key/ MOVING SSH KEYS TO A ROOT-OWNED LOCATION but I'm using the config AuthorizedKeysFile /etc/ssh/keys/%u In the original image, the permissions of the keys directory /etc/ssh/keys are 0755 - owned by root:root. It contains all the keys of the users. All keys have 0644 permissions and are also owned by root:root. (The background: Users are not allowed to change their ssh keys.) After the machine boots and cloud-init finishes, the permissions of the key directory /etc/ssh/keys is 0700 and it is impossible to use key-authentication, because sshd cannot access the key files. IMHO the reason for this is, that cloud-init changes the permission of the keys directory https://git.launchpad.net/cloud-init/tree/cloudinit/ssh_util.py#n259 util.ensure_dir(os.path.dirname(auth_key_fn), mode=0o700) which is wrong in this use case. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1839061/+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 1839249] Re: Can't set user skeleton in cloudinit
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3420 ** Bug watch added: github.com/canonical/cloud-init/issues #3420 https://github.com/canonical/cloud-init/issues/3420 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1839249 Title: Can't set user skeleton in cloudinit Status in cloud-init: Expired Bug description: Cloud-init doesn't allow us to set a path to /etc/skel or to disable using skeleton files (if we want a clean home directory). This should be added. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1839249/+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 1839537] Re: cloud-init's initramfs handling should generate v2 network-config
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3423 ** Bug watch added: github.com/canonical/cloud-init/issues #3423 https://github.com/canonical/cloud-init/issues/3423 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1839537 Title: cloud-init's initramfs handling should generate v2 network-config Status in cloud-init: Expired Bug description: There's no reason for it to continue rendering the old version when we support v2. (Once [0] lands, this will also require modifications to the Oracle data source, which merges its own network configuration into the one generated from the initramfs.) [0] https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/371053 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1839537/+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 1839659] Re: cloud-init should stop accepting a plethora of values for true/false configuration
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3425
** Bug watch added: github.com/canonical/cloud-init/issues #3425
https://github.com/canonical/cloud-init/issues/3425
** Changed in: cloud-init
Status: Confirmed => Expired
--
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/1839659
Title:
cloud-init should stop accepting a plethora of values for true/false
configuration
Status in cloud-init:
Expired
Bug description:
YAML has native support for boolean values, and YAML has been around
long enough that it's reasonable to expect people to know how to write
it.
We should phase out accepting multiple string values ("yes", "1",
"true", "on" for True; "no", "0", "false", "off" for False) in places
where we do in favour of YAML boolean values.
A proposed implementation plan:
* Start emitting a warning about such values in the string-handling paths of
util.{is_true,is_false} ASAP
* Some time in the future (perhaps in the lead-up to Ubuntu's 22.04 LTS?),
after we have been emitting these warnings for a good long while, switch the
behaviour of new versions of cloud-init[0] to only accept bools
What do we think?
[0] For Ubuntu, specifically, we should also _not_ change the behaviour of
existing releases when we backport these new versions of cloud-init.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1839659/+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 1839899] Re: cloud-init will not run user-data scripts when /var filesystem is mounted with the noexec flag
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3429 ** Bug watch added: github.com/canonical/cloud-init/issues #3429 https://github.com/canonical/cloud-init/issues/3429 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1839899 Title: cloud-init will not run user-data scripts when /var filesystem is mounted with the noexec flag Status in cloud-init: Expired Bug description: Cloud Vendor: Amazon AWS Platform: RHEL7.6 Cloud-Init: cloud-init-18.5-3.el7.x86_64 Kernel: 3.10.0-1062.el7.x86_64 SELinux: selinux-policy-targeted-3.13.1-252.el7.1.noarch -- We have identified that having the "noexec" flag set on the /var filesystem causes cloud-init to fail running user-data scripts. This is a security requirement mandated by STIG policies that we're purposefully trying to meet for Federal systems. The affected code is in: /usr/lib/python2.7/site-packages/cloudinit/util.py Under the function: runparts() The system checks for access to the executable using the following line: if os.path.isfile(exe_path) and os.access(exe_path, os.X_OK): ## ^ While the file is executable, the "noexec" flag on the filesystem causes os.access() to report False, which cancels the execution of the user-data script. To reproduce the problem: - Create new filesystem - Move /var files to new filesystem - Add /var to fstab with the "noexec" option - Mount new /var filesystem - Run cloud-init init - Run cloud-init modules -m final - Observe that the cloud-init scripts do not run Note that the files in /var/lib/cloud/instances/*/scripts/ are executable (mode 0755 or 0700) And that when trying to execute the file, you will get Error 13: Permission denied. -- Possible fixes: - Search for marker on the first line of the file (#!) and add the requested shell as exe_prefix (as stated above) - Move /var/lib/cloud (or a portion thereof) to a different filesystem path and symlink it to original path We have tested the second workaround and it seems to help: # cloud-init clean # rm -Rf /var/lib/cloud # mkdir -p /etc/cloud/runtime # ln -s /etc/cloud/runtime /var/lib/cloud # restorecon -rv /var/lib/cloud After this, user-data scripts appear to execute. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1839899/+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 1837106] Re: "socket.getaddrinfo" of "metadata.google.internal" fails on GCE
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3410 ** Bug watch added: github.com/canonical/cloud-init/issues #3410 https://github.com/canonical/cloud-init/issues/3410 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1837106 Title: "socket.getaddrinfo" of "metadata.google.internal" fails on GCE Status in cloud-init: Expired Bug description: When booting an Ubuntu 18.04 based image on GCE, we see the following messages in the log: 2019-05-30 00:05:27,818 - util.py[DEBUG]: Resolving URL: http://metadata.google.internal/computeMetadata/v1/ took 0.001 seconds 2019-05-30 00:05:27,818 - DataSourceGCE.py[DEBUG]: http://metadata.google.internal/computeMetadata/v1/ is not resolvable 2019-05-30 00:05:27,818 - util.py[DEBUG]: Crawl of GCE metadata service took 0.013 seconds 2019-05-30 00:05:27,818 - DataSourceGCE.py[WARNING]: address "http://metadata.google.internal/computeMetadata/v1/"; is not resolvable Further, the contents of "/run/cloud-init/instance-data.json" doesn't have any meaningful data. What I've found is that, read_md() in DataSourceGCE.py will call util.is_resolvable_url() on the address "http://metadata.google.internal/computeMetadata/v1/";, which results is calling socket.getaddrinfo() for "metadata.google.internal", and it's this socket.getaddrinfo() call that fails. This failure appears to be due to the fact that "cloud-init.service" does not ensure it waits for DNS (i.e. "systemd-resolved.service") to be working before it runs. I say this because: 1. If I add "After=systemd-resolved.service" to the "cloud- init.service" definition, this failures goes away. 2. If I run "cloud-init init" after the system has booted up (i.e. after enough time has passed, such that DNS is working), the failure doesn't occur. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1837106/+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 1835008] Re: network_v2 does not set mtu on eni config
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3401 ** Bug watch added: github.com/canonical/cloud-init/issues #3401 https://github.com/canonical/cloud-init/issues/3401 ** Changed in: cloud-init Status: Confirmed => Expired -- 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/1835008 Title: network_v2 does not set mtu on eni config Status in cloud-init: Expired Status in curtin: Invalid Status in MAAS: Invalid Bug description: The MTU is not set on the bond, nor vlans on the bond, nor the bridges attached to the vlans on a network_v2 configuration. It's only set on the underlying interfaces (eth0, eth1) This does not happen if given a network_v1 configuration. (I'm deploying ubuntu xenial via MAAS 2.6.0, setting force_v1_network_yaml=true is my current workaround.) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1835008/+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 1835205] Re: OVF datasource should check if instant id is still on VMware Platform
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3402 ** Bug watch added: github.com/canonical/cloud-init/issues #3402 https://github.com/canonical/cloud-init/issues/3402 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1835205 Title: OVF datasource should check if instant id is still on VMware Platform Status in cloud-init: Expired Bug description: Currently DatasourceOVF does not check the instance id to determine if current instance is a new instance or not, so that every booting, cloud-init will go through entire datasource list. This leads an issue: When a VM's network is customized to static IP by cloud-init DatasourceOVF and then the VM is rebooted, the VM's network will be changed to DHCP after rebooting since this time no customization config file will be found. cloud-init uses DatasourceNone which change network to "default" configuration. The expected behaviors are: 1. cloud-init checks the instance id to know if this instance is "iid-vmware-xx" which means it's a VMware VM. If yes, it should always use datasourceOVF. 2. When there has customization config file, datasourceOVF parse the configures and enable nics as usual. 3. When there is no customization config file, datasourceOVF wait for it until timeout and then cloud-init does NOT apply other datasources. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1835205/+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 1834371] Re: On GCE, ds.metadata.instance_data cannot be used for templating
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3398 ** Bug watch added: github.com/canonical/cloud-init/issues #3398 https://github.com/canonical/cloud-init/issues/3398 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1834371 Title: On GCE, ds.metadata.instance_data cannot be used for templating Status in cloud-init: Expired Bug description: When running on GCE, the templating engine has a ds.metadata.instance_data attribute available to it. However, that attribute is a string representation of a dictionary (of GCE-specific metadata), rather than a dictionary. This means that the contents of instance_data cannot readily be used in templating. This is a feature request for instance_data to be presented as a dict rather than as an opaque string. [Original Report] I have a use-case where I need to query the metadata that was passed on creating the instance and use those values as variables in my cloud-config. However, ds.meta_data.instance_data is a string, hence making it not query-able from cloud-config. Just removing the enclosing quotes and the escaping around the quotes within the actual dictionary itself makes the instance_data field easily query-able. Please consider making the instance_data field a query-able field? Environment Information : Operating System : Ubuntu 18.04.2 LTS Cloud Init : 19.1-1-gbaa47854-0ubuntu1~18.04.1 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834371/+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 1834065] Re: cloud-init v19.1 fails to read user-data if a VM on CloudSigma doesn't have a ssh public key in VM properties/SSH keys
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3396
** Bug watch added: github.com/canonical/cloud-init/issues #3396
https://github.com/canonical/cloud-init/issues/3396
** Changed in: cloud-init
Status: Triaged => Expired
--
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/1834065
Title:
cloud-init v19.1 fails to read user-data if a VM on CloudSigma doesn't
have a ssh public key in VM properties/SSH keys
Status in cloud-init:
Expired
Bug description:
I'm using python 3 to access CloudSigma resources.
There are two python libraries that can be used to access CloudSigma,
libcloud and pycloudsigma.
Neither have functions to deal with VM instance ssh public keys. There are
REST API paths
/api/2.0/keypairs/ and /api/2.0/pubkeys/ but they are not in either of the
libraries' code)
I can't add the ssh_public_key to the VM metadata because it's a reserved
word.
"! Reserved meta keys are: Description, ssh_public_key, optimize_for."
If I try to add it, it just disappears in the web dashboard.
The only choice for me seems to be using CloudSigma's web dashboard to attach
the ssh public key
to the VM instance and that's not what I would like to do.
rharper on irc suggested to patch DataSourceCloudSigma.py to change
self.ssh_public_key = server_meta['ssh_public_key']to
self.ssh_public_key = server_meta.get('ssh_public_key', '')
and it seems to work.
I've included the cloud-init collect-logs tar package.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834065/+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 1834676] Re: Overriding default user to root doesn't work if ssh_pwauth is set to true
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3400
** Bug watch added: github.com/canonical/cloud-init/issues #3400
https://github.com/canonical/cloud-init/issues/3400
** Changed in: cloud-init
Status: Triaged => Expired
--
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/1834676
Title:
Overriding default user to root doesn't work if ssh_pwauth is set to
true
Status in cloud-init:
Expired
Bug description:
We were trying to change the default user from ubuntu to root and at
the same time allowing password authentication, which did not work. By
adding the "user: root" declaration the user is changed but
"ssh_pwauth: true" seems to be only anticipating that the user is not
changed to root since:
ssh_pwauth only sets PasswordAuthentication to yes in the sshd_config
but not PermitRootLogin.
I am not sure if this is done on purpose or if this is an actual bug.
Example Config:
#cloud-config
user: root
chpasswd: {expire: false}
password: metoo
disable_root: false
ssh_pwauth: true
If someone is stumbling over this via Google, here is a config with a
workaround:
# override default_user from ubuntu -> root and allow ssh password logins as
root
#cloud-config
user: root
chpasswd: {expire: false}
password: metoo
disable_root: false
ssh_pwauth: true
runcmd:
- echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
- systemctl restart ssh
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834676/+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 1833446] Re: 5 second delay failing to communicate with OpenStack HTTP endpoint during boot on Oracle Cloud Infrastructure
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3392 ** Bug watch added: github.com/canonical/cloud-init/issues #3392 https://github.com/canonical/cloud-init/issues/3392 ** Changed in: cloud-init Status: Confirmed => Expired -- 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/1833446 Title: 5 second delay failing to communicate with OpenStack HTTP endpoint during boot on Oracle Cloud Infrastructure Status in cloud-init: Expired Bug description: The eventual traceback: 2019-06-19 16:27:02,468 - util.py[DEBUG]: Failed fetching meta-data/ from url http://169.254.169.254/latest/meta-data/ Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/ec2_utils.py", line 178, in _get_instance_metadata response = caller(md_url) File "/usr/lib/python3/dist-packages/cloudinit/url_helper.py", line 107, in read_file_or_url exception_cb=exception_cb) File "/usr/lib/python3/dist-packages/cloudinit/url_helper.py", line 306, in readurl raise excps[-1] cloudinit.url_helper.UrlError: 404 Client Error: Not Found for url: http://169.254.169.254/latest/meta-data/ (I can confirm several minutes after instance launch that I still see the same 404 error.) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1833446/+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 1833731] Re: cloud-init analyze output not formatted cleanly on Azure
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3394 ** Bug watch added: github.com/canonical/cloud-init/issues #3394 https://github.com/canonical/cloud-init/issues/3394 ** Changed in: cloud-init Status: Confirmed => Expired -- 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/1833731 Title: cloud-init analyze output not formatted cleanly on Azure Status in cloud-init: Expired Bug description: Azure added additional reporting trace points, the result is that analyze/blame output doesn't look well formatted. -- Boot Record 01 -- The total time elapsed since completing an event is printed after the "@" character. The time the event takes is printed after the "+" character. Starting stage: init-local |`->no cache found @00.00500s +00.0s Starting stage: init-local/search-Azure Starting stage: azure-ds/_get_data |`->found azure asset tag @00.05000s +00.01100s Starting stage: azure-ds/crawl_metadata |`->list_possible_azure_ds_devs @00.06200s +00.25000s |`->load_azure_ds_dir @00.31300s +00.0s Starting stage: azure-ds/load_azure_ds_dir Starting stage: azure-ds/read_azure_ovf |`->load_azure_ovf_pubkeys @00.31700s +00.0s |`->_extract_preprovisioned_vm_setting @00.31700s +00.00100s Finished stage: (azure-ds/read_azure_ovf) 00.00400 seconds Finished stage: (azure-ds/load_azure_ds_dir) 00.00500 seconds Starting stage: azure-ds/get_metadata_from_imds |`->_get_metadata_from_imds @00.49100s +00.01000s Finished stage: (azure-ds/get_metadata_from_imds) 00.19000 seconds |`->_get_random_seed @00.52100s +00.00100s Finished stage: (azure-ds/crawl_metadata) 00.47100 seconds |`->maybe_remove_ubuntu_network_config_scripts @00.53200s +00.00100s |`->write_files @00.53300s +00.00300s Finished stage: (azure-ds/_get_data) 00.48600 seconds Finished stage: (init-local/search-Azure) 00.48900 seconds |`->network config from imds @00.59600s +00.0s Finished stage: (init-local) 00.73800 seconds Starting stage: init-network |`->restored from cache with run check: DataSourceAzure [seed=/var/lib/waagent] @03.12900s +00.03300s |`->network config from imds @03.21700s +00.00100s Starting stage: init-network/setup-datasource Starting stage: azure-ds/setup Starting stage: azure-ds/_negotiate Starting stage: azure-ds/bounce_network_with_azure_hostname |`->temporary_hostname @03.23000s +00.0s Finished stage: (azure-ds/bounce_network_with_azure_hostname) 00.00300 seconds Starting stage: azure-ds/get_metadata_from_fabric Starting stage: azure-ds/register_with_azure_and_fetch_data |`->generate_certificate @03.23500s +00.10500s Starting stage: azure-ds/find_endpoint |`->_networkd_get_value_from_leases @03.34000s +00.00200s Finished stage: (azure-ds/find_endpoint) 00.00200 seconds Starting stage: azure-ds/parse_certificates |`->_decrypt_certs_from_xml @03.36100s +00.01000s Starting stage: azure-ds/_get_ssh_key_from_cert |`->_run_x509_action @03.37200s +00.00600s Finished stage: (azure-ds/_get_ssh_key_from_cert) 00.04900 seconds Starting stage: azure-ds/_get_fingerprint_from_cert |`->_run_x509_action @03.42100s +00.00600s Finished stage: (azure-ds/_get_fingerprint_from_cert) 00.00600 seconds Finished stage: (azure-ds/parse_certificates) 00.06700 seconds |`->_report_ready @03.42800s +00.00700s Finished stage: (azure-ds/register_with_azure_and_fetch_data) 00.20200 seconds Finished stage: (azure-ds/get_metadata_from_fabric) 00.20200 seconds Finished stage: (azure-ds/_negotiate) 00.20800 seconds Finished stage: (azure-ds/setup) 00.20800 seconds Finished stage: (init-network/setup-datasource) 00.20800 seconds |`->reading and applying user-data @03.44500s +00.00300s |`->reading and applying vendor-data @03.44900s +00.0s Starting stage: init-network/activate-datasource Starting stage: azure-ds/activate Starting stage: azure-ds/address_ephemeral_resize |`->wait for ephemeral disk @03.48600s +00.00100s |`->can_dev_be_reformatted @03.48700s +00.00100s Finished stage: (azure-ds/address_ephemeral_resize) 00.00200 seconds Finished stage: (azure-ds/activate) 00.00200 seconds Finished stage: (init-network/activate-datasource) 00.00400 seconds |`->config-migrator ran successfully @03.54000s +00.00400s |`->config-seed_random ran successfully @03.54600s +00.00200s |`->config-bootcmd ran successfully @03.54900s +00.0s |`->config-write-files ran successfully @03.55000s +00.0s |`->config-growpart ran successfully @03.55100s +00.10400s |`->config-resizefs ran successfully @03.65600s +00.04900s |`->config-disk_setup ran successfully @03.70600s +03.42300s |`->config-mounts ran successfully @07.13000s +00.22300s |`->config-set_hostname ran successfully @07.35400s +00.00200s |`->config-update_hostname ran su
[Yahoo-eng-team] [Bug 1833460] Re: cloud_tests on lxd snap error exporting image
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3393
** Bug watch added: github.com/canonical/cloud-init/issues #3393
https://github.com/canonical/cloud-init/issues/3393
** Changed in: cloud-init
Status: Triaged => Expired
--
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/1833460
Title:
cloud_tests on lxd snap error exporting image
Status in cloud-init:
Expired
Bug description:
Attempting a cloud_test run on lxd platform had this issue.
(diglett) cloud-init % tox -r -e citest -- run --verbose --platform=lxd
--os-name centos70 --rpm ~/cloud-init-19.1+44.g12efb6d3-1.el7.noarch.rpm
--result /tmp/centos7-result.yaml
GLOB sdist-make: /srv/tmp/rharper/cloud-init/setup.py
citest create: /srv/tmp/rharper/cloud-init/.tox/citest
citest installdeps: -r/srv/tmp/rharper/cloud-init/integration-requirements.txt
citest inst:
/srv/tmp/rharper/cloud-init/.tox/.tmp/package/1/cloud-init-19.1.zip
citest installed:
asn1crypto==0.24.0,attrs==19.1.0,bcrypt==3.1.6,boto3==1.5.9,botocore==1.8.50,certifi==2019.6.16,cffi==1.12.3,chardet==3.0.4,cloud-init==19.1,configobj==5.0.6,cryptography==2.7,docutils==0.14,idna==2.8,Jinja2==2.10.1,jmespath==0.9.4,jsonpatch==1.23,jsonpointer==2.0,jsonschema==3.0.1,linecache2==1.0.0,MarkupSafe==1.1.1,oauthlib==3.0.1,paramiko==2.4.1,pbr==5.3.0,pkg-resources==0.0.0,pyasn1==0.4.5,pycparser==2.19,pylxd==2.2.7,PyNaCl==1.3.0,pyrsistent==0.15.2,python-dateutil==2.8.0,python-simplestreams==0.1.0,PyYAML==5.1.1,requests==2.22.0,requests-toolbelt==0.9.1,requests-unixsocket==0.1.5,s3transfer==0.1.13,six==1.12.0,traceback2==1.4.0,unittest2==1.1.0,urllib3==1.25.3,ws4py==0.5.1
citest run-test-pre: PYTHONHASHSEED='2218838469'
citest runtests: commands[0] |
/srv/tmp/rharper/cloud-init/.tox/citest/bin/python -m tests.cloud_tests run
--verbose --platform=lxd --os-name centos70 --rpm
/home/rharper/cloud-init-19.1+44.g12efb6d3-1.el7.noarch.rpm --result
/tmp/centos7-result.yaml
2019-06-19 19:18:44,550 - tests.cloud_tests - DEBUG - running with args:
Namespace(data_dir=None, deb=None, feature_override={}, os_name=['centos70'],
platform=['lxd'], ppa=None, preserve_data=False, preserve_instance=False,
quiet=False, repo=None, result='/tmp/centos7-result.yaml',
rpm='/home/rharper/cloud-init-19.1+44.g12efb6d3-1.el7.noarch.rpm', script=None,
subcmd='run',
test_config=['/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/bugs/lp1511485.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/bugs/lp1611074.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/bugs/lp1628337.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/add_apt_repositories.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/alter_completion_message.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/configure_instance_trusted_ca_certificates.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/exa
mples/configure_instances_ssh_keys.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/including_user_groups.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/install_arbitrary_packages.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/install_run_chef_recipes.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/run_apt_upgrade.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/run_commands.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/run_commands_first_boot.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/setup_run_puppet.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/examples/writing_out_arbitrary_files.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/main/command_output_simple.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_conf.yaml',
'/srv/tmp/rharper
/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_disable_suites.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_primary.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_proxy.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_security.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_sources_key.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_sources_keyserver.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_sources_list.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_configure_sources_ppa.yaml',
'/srv/tmp/rharper/cloud-init/tests/cloud_tests/testcases/modules/apt_pipelining_disable.yaml',
'/srv/tmp
[Yahoo-eng-team] [Bug 1833755] Re: Feature Request: re-configure networking at runtime based upon potential DataSource changes
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3395 ** Bug watch added: github.com/canonical/cloud-init/issues #3395 https://github.com/canonical/cloud-init/issues/3395 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1833755 Title: Feature Request: re-configure networking at runtime based upon potential DataSource changes Status in cloud-init: Expired Bug description: Use Case: In our cloud, the networking configuration can be modified by end-users (e.g. enabling IPv6, or a private network) after first boot. We do not currently have a means to leverage cloud-init to *only* reconfigure the network of a VM when the datasource's contents for a VM have changed. Would it be possible to add something like this? In principle, this might only allow for laying down a new configuration onto the VM, it does not need to apply the configuration (that's the OS' responsibility via reboot or otherwise). To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1833755/+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 1832645] Re: fs_setup/disk_setup: option to wait for the device to exist before continuing
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3386 ** Bug watch added: github.com/canonical/cloud-init/issues #3386 https://github.com/canonical/cloud-init/issues/3386 ** Changed in: cloud-init Status: In Progress => Expired -- 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/1832645 Title: fs_setup/disk_setup: option to wait for the device to exist before continuing Status in cloud-init: Expired Bug description: When using the AWS::EC2::Volume and AWS::EC2::VolumeAttachment options to add a volume to an AWS::EC2::Instance on AWS EC2, the volume is not immediately available on the instance. This causes fs_setup and disk_setup to fail. What would prevent this failure is a "wait" option on both fs_setup and disk_setup, which if true, will cause cloud-init to wait until the device exists (caused by AWS catching up and attaching the device) before continuing. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1832645/+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 1823381] Re: Enable log rotation
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3365 ** Bug watch added: github.com/canonical/cloud-init/issues #3365 https://github.com/canonical/cloud-init/issues/3365 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1823381 Title: Enable log rotation Status in cloud-init: Expired Bug description: As reported on the Debian cloud mailing list [1] we should consider enabling or including a log rotation script. [1] https://lists.debian.org/debian-cloud/2019/04/msg00022.html To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1823381/+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 1828236] Re: ds-identify does not identify openstack Open Telecom Cloud BMS
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3378 ** Bug watch added: github.com/canonical/cloud-init/issues #3378 https://github.com/canonical/cloud-init/issues/3378 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1828236 Title: ds-identify does not identify openstack Open Telecom Cloud BMS Status in cloud-init: Expired Bug description: relating to cloud-init bugs #1669675 #1756471 The OpenStack detection fails on BMS (Bare Metal) hosts in Open Telekom Cloud. cloud-init version 18.5 detection fails cloud-init Version 18.2 still works /usr/lib/python3/dist-packages/cloudinit/sources/DataSourceOpenStack.py searches for (...) # OpenStack DMI constants DMI_PRODUCT_NOVA = 'OpenStack Nova' DMI_PRODUCT_COMPUTE = 'OpenStack Compute' VALID_DMI_PRODUCT_NAMES = [DMI_PRODUCT_NOVA, DMI_PRODUCT_COMPUTE] DMI_ASSET_TAG_OPENTELEKOM = 'OpenTelekomCloud' VALID_DMI_ASSET_TAGS = [DMI_ASSET_TAG_OPENTELEKOM] (...) BMS server in OTC have none of theses tags set. Manual edit DataSourceOpenStack.py only for testing to accept our host, all is working fine. How we can get back OTC BMS hosts detected as valid OpenStack hosts in cloud-init? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1828236/+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 1827204] Re: Doesn't run unattended-upgrades on first boot by default
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3376 ** Bug watch added: github.com/canonical/cloud-init/issues #3376 https://github.com/canonical/cloud-init/issues/3376 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1827204 Title: Doesn't run unattended-upgrades on first boot by default Status in cloud-init: Expired Bug description: Use case: I bake an Ubuntu cloud image for a reproducible deployment, leaving most things as default except the specific bits I need. Since I know that unattended-upgrades deals with security updates automatically by default, I don't worry about this, and expect it to be OK to put an instance based on this baked image in production, even months later. Expected behaviour: on deployment of the image and completion of cloud-init the instance is ready and my automated deployment system can take over to put the instance into production without any further unusual disruption. Actual behaviour: the next nightly unattended-upgrades run is a mammoth one and causes significant downtime as a consequence, far more than a regular nightly run, on the instance I only just freshly put into production. See bug 1819033 for an example. Suggestion: cloud-init could detect if unattended-upgrades is scheduled to run, and if it is, run it on first boot, by default, to catch up before the instance gets put into production. I further suggest that this should be default behaviour. Note: "package_upgrade: true" isn't quite sufficient because it installs all updates, not just security updates, so isn't exactly equivalent. The user could run unattended-upgrades directly using run- once in a bootcmd or something to get closer. But it seems to me that this entire scenario is a trap. The user shouldn't need to know to do arrange this. We should do the sensible thing by default. One downside is that when experimenting or developing the instance will take longer to boot. I don't think this should be much of a problem though, since it will only affect old images. It also seems reasonable to me that an old image (assuming it is enabled for unattended-upgrades in the security pocket) is brought up to date for security before being put into production, rather than after a delay, and cloud-init seems to be the right place for that to happen. I'm filing this bug to provide a place for further discussion: my proposed solution may not be the correct one. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1827204/+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 1828611] Re: disk_setup could deal with non-deterministic device naming on EC2 nitro instances
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3380 ** Bug watch added: github.com/canonical/cloud-init/issues #3380 https://github.com/canonical/cloud-init/issues/3380 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1828611 Title: disk_setup could deal with non-deterministic device naming on EC2 nitro instances Status in cloud-init: Expired Bug description: Cloud Provider: Amazon Web Services As is documented in [1], instances on the nitro type hypervisor don't attach the NVME disks in deterministic order, yielding a different order of disks, example [2]. This makes it somewhat difficult to format and partition volumes since you don't know the volume ids beforehand when creating an instance (in an Autoscaling group for example). My current thinking is that maybe a sort of special device name (much like swap / ephemeralX) coul be used to locate a device, for example ebs:root for the root drive - which is easy to detect, ebs:size=12G[0] for the first volume found with 12GiB size. With an appropriate instance profile and boto3 more elaborate selectors are conceivable (for example based on tags). Further complicating things is that the metadata endpoint doesn't expose the correct device names, opting instead for fantasy names (sda1 for the root volume, sdX for other volumes). My Workaround for a 2 volume instance: Try and format both devices, then mount the disk by label: #cloud-config fs_setup: - label: mylabel device: /dev/nvme0n1 filesystem: xfs partition: none overwrite: false - label: mylabel device: /dev/nvme1n1 filesystem: xfs partition: none overwrite: false mounts: - ["/dev/disk/by-label/mylabel", "/mnt/label", "xfs", "defaults"] [1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/nvme-ebs-volumes.html [2] https://gist.github.com/nilsmeyer/eddcfa4b7fc5b04ebc0be9eaa3c7b7dd To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1828611/+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 1818197] Re: ubuntu-18.04-server-cloudimg-arm64.img often fails to set the cloud-localds password under QEMU
** Changed in: cloud-images
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/1818197
Title:
ubuntu-18.04-server-cloudimg-arm64.img often fails to set the cloud-
localds password under QEMU
Status in cloud-images:
Invalid
Status in cloud-init:
Expired
Bug description:
On an Ubuntu 18.10 host, QEMU 2.12.0, I try to run the cloudimage with
the script shown at the end of this description.
Result: many times, I end up on the user / password prompt, but the
password I chose with cloud-localds was not set.
It is not deterministic, but it happens very often. Sometimes password
worked. And very rarely, it shows a stack trace on the terminal, but
most times just fails silently.
The test script:
```
set -eux
# Parameters.
id=ubuntu-18.04-server-cloudimg-arm64
img="${id}.img"
img_snapshot="${id}.img.snapshot.qcow2"
flash0="${id}-flash0.img"
flash1="${id}-flash1.img"
user_data="${id}-user-data"
user_data_img="${user_data}.img"
# Install dependencies.
pkgs='cloud-image-utils qemu-system-arm qemu-efi'
if ! dpkg -s $pkgs >/dev/null 2>&1; then
sudo apt-get install $pkgs
fi
# Get the image.
if [ ! -f "$img" ]; then
wget "https://cloud-images.ubuntu.com/releases/18.04/release/${img}";
fi
# Create snapshot.
if [ ! -f "$img_snapshot" ]; then
qemu-img \
create \
-b "$img" \
-f qcow2 \
"$img_snapshot" \
1T \
;
fi
# Set the password.
if [ ! -f "$user_data" ]; then
cat >"$user_data"
[Yahoo-eng-team] [Bug 1820360] Re: seed location requires trailing slash
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3355 ** Bug watch added: github.com/canonical/cloud-init/issues #3355 https://github.com/canonical/cloud-init/issues/3355 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1820360 Title: seed location requires trailing slash Status in cloud-init: Expired Bug description: Hello, I'm trying to bootstrap the Raspberry Pi Arm64 image from http://cdimage.ubuntu.com/ubuntu/releases/bionic/release/ using cloud-init. In order to customize the seed I tried to specify the following kernel cmdline in cmdline.txt: $ cat cmdline.txt # corresponds to kernel cmdline net.ifnames=0 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait ds=nocloud;s=/boot/firmware/seed [this is the location in which raspberry mounts the boot partition] In /boot/firmware/seed (VFAT partition) these are the contents: $ cat /boot/firmware/seed/meta-data instance_id: cloud-image $ cat /boot/firmware/seed/user-data #cloud-config # vim: syntax=yaml # ssh_pwauth: True hostname: rpi3plus locale: "en_US.UTF-8" timezone: "Europe/Rome" users: - name: devster gecos: Daniele Riccucci ssh_authorized_keys: - ssh-ed25519 lock_passwd: false passwd: package_update: true package_upgrade: true package_reboot_if_required: true Cloud-init ran, however it couldn't find the specified location as it tried to access /boot/firmware/seedmeta-data and /boot/firmware/seeduser-data I unfortunately don't have the logs anymore. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1820360/+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 1820609] Re: collect-logs should attempt to capture cloud-init version using more than dpkg
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3357 ** Bug watch added: github.com/canonical/cloud-init/issues #3357 https://github.com/canonical/cloud-init/issues/3357 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1820609 Title: collect-logs should attempt to capture cloud-init version using more than dpkg Status in cloud-init: Expired Bug description: dpkg is only present on Debian derivatives; we should attempt to use other package management tools during `cloud-init collect-logs` to improve our chances of getting a useful version number in the collected tarball. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1820609/+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 1822615] Re: cloud-tests tree_run/bddeb fail to build deb
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3362
** Bug watch added: github.com/canonical/cloud-init/issues #3362
https://github.com/canonical/cloud-init/issues/3362
** Changed in: cloud-init
Status: Triaged => Expired
--
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/1822615
Title:
cloud-tests tree_run/bddeb fail to build deb
Status in cloud-init:
Expired
Bug description:
While looking to verify an apt_pipelining test-case fix I ran this:
% tox -e citest -- tree_run --verbose --os-name bionic --test
modules/apt_pipelining_disable --test modules/apt_pipelining_os
--result /tmp/result.yaml
During which, it would fail like this:
2019-03-31 16:13:11,743 - tests.cloud_tests - ERROR - stage part: build deb
on system encountered error: Unexpected error while running command.
Command: /root/packages/bddeb -d
Exit code: 1
Reason: -
==
ERROR:
cloudinit.cmd.tests.test_query.TestQuery.test_handle_args_dumps_all_instance_data
--
Traceback (most recent call last):
File
"/run/cloud-init/tmp/tmp2v5cncbz/cloud-init-18.5-57-g6c258412/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
"/run/cloud-init/tmp/tmp2v5cncbz/cloud-init-18.5-57-g6c258412/cloudinit/cmd/query.py",
line 124, in handle_args
instance_data['userdata'] = util.load_file(user_data_fn)
File
"/run/cloud-init/tmp/tmp2v5cncbz/cloud-init-18.5-57-g6c258412/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
"/run/cloud-init/tmp/tmp2v5cncbz/cloud-init-18.5-57-g6c258412/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
"/run/cloud-init/tmp/tmp2v5cncbz/cloud-init-18.5-57-g6c258412/cloudinit/cmd/query.py",
line 124, in handle_args
instance_data['userdata'] = util.load_file(user_data_fn)
File
"/run/cloud-init/tmp/tmp2v5cncbz/cloud-init-18.5-57-g6c258412/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_sorts_nested_keys_when_varname
--
Traceback (most recent call last):
File
"/run/cloud-init/tmp/tmp2v5cncbz/cloud-init-18.5-57-g6c258412/cloudinit/cmd/tests/test_query.py",
line 239, in test_handle_args_list_keys_sorts_nested_keys_when_varname
self.assertEqual(0, query.handle_args('anyname', args))
File
"/run/cloud-init/tmp/tmp2v5cncbz/cloud-init-18.5-57-g6c258412/cloudinit/cmd/query.py",
line 124, in handle_args
instance_data['userdata'] = util.load_file(user_data_fn)
File
"/run/cloud-init/tmp/tmp2v5cncbz/cloud-init-18.5-57-g6c258412/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_sorts_top_level_keys_when_no_varname
--
Traceback (most recent call last):
File
"/run/cloud-init/tmp/tmp2v5cncbz/cloud-init-18.5-57-g6c258412/cloudinit/cmd/tests/test_query.py",
line 224, in test_handle_ar
[Yahoo-eng-team] [Bug 1818661] Re: ipv6 static routes dropped when rendering opensuse files
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3347
** Bug watch added: github.com/canonical/cloud-init/issues #3347
https://github.com/canonical/cloud-init/issues/3347
** Changed in: cloud-init
Status: Triaged => Expired
--
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/1818661
Title:
ipv6 static routes dropped when rendering opensuse files
Status in cloud-init:
Expired
Bug description:
Ipv6 static routes seem dropped during opensuse file generation
Information to quickly reproduce:
source .tox/py3/bin/activate
nosetests -s
tests/unittests/test_net.py:TestOpenSuseSysConfigRendering.test_bond_config
-> this unittest is currently ok but here is what seems weird:
The related cloud init config tested in this unit test is (quoted from
master:tests/unittests/test_net.py, slightly amended: I put the routes
where I think they should be, but the rendered files are the same in
the upstream master case anyway):
"""
version: 1
config:
- type: physical
name: bond0s0
mac_address: "aa:bb:cc:dd:e8:00"
- type: physical
name: bond0s1
mac_address: "aa:bb:cc:dd:e8:01"
- type: bond
name: bond0
mac_address: "aa:bb:cc:dd:e8:ff"
mtu: 9000
bond_interfaces:
- bond0s0
- bond0s1
params:
bond-mode: active-backup
bond_miimon: 100
bond-xmit-hash-policy: "layer3+4"
subnets:
- type: static
address: 192.168.0.2/24
gateway: 192.168.0.1
routes:
- gateway: 192.168.0.3
netmask: 255.255.255.0
network: 10.1.3.0
- type: static
address: 192.168.1.2/24
- type: static
address: 2001:1::1/92
routes:
- gateway: 2001:67c:1562:1
network: 2001:67c:1
netmask: ::0
- gateway: 3001:67c:1562:1
network: 3001:67c:1
netmask: ::0
metric: 1
"""
Rendered files:
"""
/etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="aa:bb:cc:dd:e8:00", NAME="bond0s0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="aa:bb:cc:dd:e8:01", NAME="bond0s1"
/etc/sysconfig/network/ifcfg-bond0s1
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=none
DEVICE=bond0s1
HWADDR=aa:bb:cc:dd:e8:01
MASTER=bond0
NM_CONTROLLED=no
ONBOOT=yes
SLAVE=yes
STARTMODE=auto
TYPE=Ethernet
USERCTL=no
/etc/sysconfig/network/ifcfg-bond0
# Created by cloud-init on instance boot automatically, do not edit.
#
BONDING_MASTER=yes
BONDING_OPTS="mode=active-backup xmit_hash_policy=layer3+4 miimon=100"
BONDING_SLAVE0=bond0s0
BONDING_SLAVE1=bond0s1
BOOTPROTO=none
DEFROUTE=yes
DEVICE=bond0
GATEWAY=192.168.0.1
IPADDR=192.168.0.2
IPADDR1=192.168.1.2
IPV6ADDR=2001:1::1/92
IPV6INIT=yes
MACADDR=aa:bb:cc:dd:e8:ff
MTU=9000
NETMASK=255.255.255.0
NETMASK1=255.255.255.0
NM_CONTROLLED=no
ONBOOT=yes
STARTMODE=auto
TYPE=Bond
USERCTL=no
/etc/sysconfig/network/ifroute-bond0
# Created by cloud-init on instance boot automatically, do not edit.
#
ADDRESS0=10.1.3.0
GATEWAY0=192.168.0.3
NETMASK0=255.255.255.0
/etc/sysconfig/network/ifcfg-bond0s0
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=none
DEVICE=bond0s0
HWADDR=aa:bb:cc:dd:e8:00
MASTER=bond0
NM_CONTROLLED=no
ONBOOT=yes
SLAVE=yes
STARTMODE=auto
TYPE=Ethernet
USERCTL=no
"""
So we can see that static ipv6 routes are nowhere to be found in
rendered files. Unfortunately, I have no SUSE distribution at hand to
tell precisely what the good behaviour should be but this looks like
the routes got lost during processing
And the reason of this drop:
The destination file path is the same for ipv4 and ipv6 routes, for opensuse
opensuse.py:
'route_templates': {
'ipv4': '%(base)s/network/ifroute-%(name)s',
'ipv6': '%(base)s/network/ifroute-%(name)s',
}
but from sysconfig.py:
def _render_sysconfig
[...]
when rendering routes:
if cpath not in contents:
contents[cpath] = iface_cfg.routes.to_string(proto)
So ipv6 routes get skipped (ipv4 has already taken the ifroute slot in
contents dict)
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1818661/+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 1819966] Re: support NTPSERVERARGS in /etc/sysconfig/network
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3353 ** Bug watch added: github.com/canonical/cloud-init/issues #3353 https://github.com/canonical/cloud-init/issues/3353 ** Changed in: cloud-init Status: Confirmed => Expired -- 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/1819966 Title: support NTPSERVERARGS in /etc/sysconfig/network Status in cloud-init: Expired Bug description: I'm not sure what's changed but in previous versions of cloud-init, it was not owning/writing contents to /etc/sysconfig/network. I DHCP my ntp endpoints and provide ntp options via NTPSERVERARGS. Example: echo 'NTPSERVERARGS="minpoll 3 maxpoll 4"' >> /etc/sysconfig/network $ grep server /etc/ntp.conf server 10.155.55.1 minpoll 3 maxpoll 4 # added by /sbin/dhclient-script On boot now /etc/sysconfig/network only has: $ cat /etc/sysconfig/network # Created by cloud-init on instance boot automatically, do not edit. # NETWORKING=yes So how can i prevent cloud-init from modifying it, or have it write the additional option (NTPSERVERARGS) that i need? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1819966/+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 1818197] Re: ubuntu-18.04-server-cloudimg-arm64.img often fails to set the cloud-localds password under QEMU
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3343
** Bug watch added: github.com/canonical/cloud-init/issues #3343
https://github.com/canonical/cloud-init/issues/3343
** Changed in: cloud-init
Status: Incomplete => Expired
--
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/1818197
Title:
ubuntu-18.04-server-cloudimg-arm64.img often fails to set the cloud-
localds password under QEMU
Status in cloud-images:
New
Status in cloud-init:
Expired
Bug description:
On an Ubuntu 18.10 host, QEMU 2.12.0, I try to run the cloudimage with
the script shown at the end of this description.
Result: many times, I end up on the user / password prompt, but the
password I chose with cloud-localds was not set.
It is not deterministic, but it happens very often. Sometimes password
worked. And very rarely, it shows a stack trace on the terminal, but
most times just fails silently.
The test script:
```
set -eux
# Parameters.
id=ubuntu-18.04-server-cloudimg-arm64
img="${id}.img"
img_snapshot="${id}.img.snapshot.qcow2"
flash0="${id}-flash0.img"
flash1="${id}-flash1.img"
user_data="${id}-user-data"
user_data_img="${user_data}.img"
# Install dependencies.
pkgs='cloud-image-utils qemu-system-arm qemu-efi'
if ! dpkg -s $pkgs >/dev/null 2>&1; then
sudo apt-get install $pkgs
fi
# Get the image.
if [ ! -f "$img" ]; then
wget "https://cloud-images.ubuntu.com/releases/18.04/release/${img}";
fi
# Create snapshot.
if [ ! -f "$img_snapshot" ]; then
qemu-img \
create \
-b "$img" \
-f qcow2 \
"$img_snapshot" \
1T \
;
fi
# Set the password.
if [ ! -f "$user_data" ]; then
cat >"$user_data"
[Yahoo-eng-team] [Bug 1681005] Re: install hooks fail because enable-os-upgrade/refresh-update ignored
** Changed in: cloud-images 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/1681005 Title: install hooks fail because enable-os-upgrade/refresh-update ignored Status in cloud-images: Invalid Status in cloud-init: Expired Status in Canonical Juju: Invalid Bug description: As seen at http://reports.vapour.ws/releases/issue/5553b279749a56508ba88b45 There is a dramatic rise in hook failures since March 24. This is because juju is not running apt-get update or upgrade. Joyent dominates, but rackspace and GCE have had spots of failures. The unit logs show apt fails to find packages. Joyent tends to have stale images so Juju CI tests always run with os-enable-refresh-update to have the correct list of packages. Today I deployed the landscape bundle in joyent and repeated the postgresql install hook failures. The log confirm an apt issue E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/l/linux/linux-libc- dev_4.4.0-71.92_amd64.deb 404 Not Found [IP: 91.189.88.149 80] juju model-config shows apt should have been updated and the host upgraded enable-os-refresh-updatedefault true enable-os-upgrade default true But /var/log/apt/history.log and /var/log/apt/term.log show apt has not been touched since the image was made in March. I left the model untouched for 3 hours. It remained in error. I ran juju ssh 2 -- sudo apt-get update 3 minutes later the unit was installed. This bug is in 2.1 and 2.2 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1681005/+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 1816393] Re: collect-logs should capture /etc/cloud and /var/lib/cloud artifacts
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3335 ** Bug watch added: github.com/canonical/cloud-init/issues #3335 https://github.com/canonical/cloud-init/issues/3335 ** Changed in: cloud-init Status: Confirmed => Expired -- 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/1816393 Title: collect-logs should capture /etc/cloud and /var/lib/cloud artifacts Status in cloud-init: Expired Bug description: Collect-logs should surface all artifacts that could contain data affected the current boot - /etc/cloud/ files - /var/lib/cloud files including parsed instance-data.json To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1816393/+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 1817230] Re: SUSE network configuration for IPv6 static addresses
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3339 ** Bug watch added: github.com/canonical/cloud-init/issues #3339 https://github.com/canonical/cloud-init/issues/3339 ** Changed in: cloud-init Status: In Progress => Expired -- 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/1817230 Title: SUSE network configuration for IPv6 static addresses Status in cloud-init: Expired Bug description: The sysconfig renderer uses IPV6ADDR IPV6ADDR_SECONDARIES but this is not part of the set of names understood on SUSE distros it should be IPADDR6 IPADDR6_? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1817230/+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 1813399] Re: [improvement] no easy way to add packages required by apt before apt stage
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3320 ** Bug watch added: github.com/canonical/cloud-init/issues #3320 https://github.com/canonical/cloud-init/issues/3320 ** Changed in: cloud-init Status: Confirmed => Expired -- 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/1813399 Title: [improvement] no easy way to add packages required by apt before apt stage Status in cloud-init: Expired Bug description: I am running cloud-init on a libvirt/virsh with this image: https://cdimage.debian.org/cdimage/openstack/archive/9.6.5-20190122/debian-9.6.5-20190122-openstack- amd64.qcow2 This is not really a bug, because I believe it is rather a packaging problem of many distros. So please close this asap if you do not feel responsible ;) This is why I also posted this problem on the debian-cloud mailing list, but maybe this can be fixed also in cloud-init. If apt-transport-https or dirmngr are not installed (they are no dependencies of cloud-init). apt: sources: docker: source: 'deb [arch=amd64] https://download.docker.com/linux/debian stretch stable' keyserver: keyserver.ubuntu.com keyid: 0EBFCD88 you will run into problems like: [ 14.011339] cloud-init[469]: E: The method driver /usr/lib/apt/methods/https could not be found. [ 14.013524] cloud-init[469]: Cloud-init v. 0.7.9 running 'modules:config' at Wed, 23 Jan 2019 16:28:06 +. Up 10.01 seconds. [ 14.016921] cloud-init[469]: 2019-01-23 16:28:10,921 - util.py[WARNING]: Running module apt-configure () failed and [ 14.460293] cloud-init[448]: Command: ['gpg', '--keyserver', 'keyserver.ubuntu.com', '--recv', '0EBFCD88'] [ 14.463206] cloud-init[448]: Stderr: gpg: failed to start the dirmngr '/usr/bin/dirmngr': No such file or directory Unfortunatedly I could not find a way to call anything to add those packages before apt is run so that I had to patch the images. One solution would be to allow multistage apt install in one way or the other (I know it adds complexity), so that one could install the relevant packages before the package list is modified and updated. Actually checking if a line contains https or a keyid and installing the appropriate dependencies could also work. Probably it would be much easier to fix the package dependency on cloud-init itself for the relevant distros. The downside of this is that it adds a bunch of packages as further dependencies, so I guess distros are not really willing to do that... Thanks in advance, Till PS: I can live with having written some scripts patching the images after download... To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1813399/+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 1813812] Re: expecting metadata server is reachable on the lexical first interface
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3322 ** Bug watch added: github.com/canonical/cloud-init/issues #3322 https://github.com/canonical/cloud-init/issues/3322 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1813812 Title: expecting metadata server is reachable on the lexical first interface Status in cloud-init: Expired Bug description: In OpenStack it is possible to configure a network setup such that the metadata server is accessible via a "secondary" NIC, for example eth1. In such a setup cloud-init fails to locate the proper NIC to access the metadata server. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1813812/+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 1814296] Re: ubuntu-core: snappy supported or not?
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3325 ** Bug watch added: github.com/canonical/cloud-init/issues #3325 https://github.com/canonical/cloud-init/issues/3325 ** Changed in: cloud-init Status: In Progress => Expired -- 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/1814296 Title: ubuntu-core: snappy supported or not? Status in cloud-init: Expired Bug description: This is confusing: Running Cloud-init v. 18.4 Using snappy module, getting warning: "snappy module will be dropped in 18.3 release" Do we travel back in time? Actual log: [ 67.530402] cloud-init[2118]: Cloud-init v. 18.4-0ubuntu1~16.04.2 running 'modules:config' at Fri, 01 Feb 2019 14:43:30 +. Up 66.77 seconds. [ 70.191507] cloud-init[2169]: Cloud-init v. 18.4-0ubuntu1~16.04.2 running 'modules:final' at Fri, 01 Feb 2019 14:43:33 +. Up 69.54 seconds. [ 70.192446] cloud-init[2169]: 2019-02-01 14:43:34,232 - cc_snappy.py[WARNING]: DEPRECATION: snappy module will be dropped in 18.3 release. Use snap module instead [ 70.443315] cloud-init[2169]: 2019-02-01 14:43:34,483 - util.py[WARNING]: Running module ssh-authkey-fingerprints () failed To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1814296/+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 1809180] Re: Support network-config for the nocloud-net datasource
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3305 ** Bug watch added: github.com/canonical/cloud-init/issues #3305 https://github.com/canonical/cloud-init/issues/3305 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1809180 Title: Support network-config for the nocloud-net datasource Status in cloud-init: Expired Bug description: Currently the nocloud-net datasource does not read the network-config from the provide URL. It would be nice if this was supported so that the network can be configured after the fallback network has been established. This way you can boot the image in a different environment without having to run cloud-init a second time. Example network-config: version: 2 ethernets: all-en: match: name: "en*" dhcp4: true To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1809180/+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 1809197] Re: motd notice for failed cloud-init run
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3306 ** Bug watch added: github.com/canonical/cloud-init/issues #3306 https://github.com/canonical/cloud-init/issues/3306 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1809197 Title: motd notice for failed cloud-init run Status in cloud-init: Expired Bug description: If cloud-init errors during a run, emit an motd banner explaining the cloud-init failure to alert to potentially inconsistent configuration. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1809197/+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 1809139] Re: Support collect-logs from a non-/ root
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3304 ** Bug watch added: github.com/canonical/cloud-init/issues #3304 https://github.com/canonical/cloud-init/issues/3304 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1809139 Title: Support collect-logs from a non-/ root Status in cloud-init: Expired Bug description: When debugging instance launch failures, one trick we use is to mount the disk of the failed instance to another instance, and investigate the logs there. Most of the time, we can use chroot to run `cloud- init collect-logs` in the failed instance's root. However, if we are attempting to debug across architectures (most recently, debugging arm64 AWS boot failures either locally or on an amd64 AWS instance), then using chroot becomes decidedly non-trivial. Could we add an option to specify the root in which collect-logs operates, to make collecting this data easier in these cases? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1809139/+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 1809277] Re: nocloud-net doesn't read included network-config file if using seedfrom=URL
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3307 ** Bug watch added: github.com/canonical/cloud-init/issues #3307 https://github.com/canonical/cloud-init/issues/3307 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1809277 Title: nocloud-net doesn't read included network-config file if using seedfrom=URL Status in cloud-init: Expired Bug description: Currently nocloud-net does not process network-config file if included in the seed provided via a URL. This is by-design, however, now that several datasources have this model of using an ephemeral DHCP process to fetch user/metadata, which includes network-configuration and then apply that; nocloud-net could transition to this model. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1809277/+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 1810859] Re: ds-identify runs too early
Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3309 ** Bug watch added: github.com/canonical/cloud-init/issues #3309 https://github.com/canonical/cloud-init/issues/3309 ** Changed in: cloud-init Status: Triaged => Expired -- 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/1810859 Title: ds-identify runs too early Status in cloud-init: Expired Bug description: ds-identify is executed from a systemd generator [1]. Based on my understanding of the intention of both this creates a non resolvable timing conflict. Generators run very early in the boot process. The cloud-init generator runs ds-identify which in turn runs "blkid" to find filesystems with specific labels, "cidata" for the nocloud data source. However, it is possible to construct an environment where the filesystem with the "cidata" label is on an attached device and the generator runs prior to the attached device being known to the kernel and thus the return of blkid cannot reflect the proper status, meaning the "cidata" label cannot be found and thus the "nocloud" data source is not properly identified. This implies that the cloud- init.target unit will be disabled. Observed in a test environment with qemu and the data source on a separate virtual device. According to [1] we shouldn't add any sync points such as "udevadm settle", thus I am not certain how this could be resolved. Also given that we cannot control the timing of the execution of the generator it appears that this is going to be difficult to get under control. Would it make sense to give ds-identify the option to simply exit and leave things alone? In the present setup the generator target runs ds-identify which in turn will disable cloud-init.target if no data source can be identified. However, the Python code usually runs late enough that things that are no available in early boot are found and data sources are identified properly. If users that know they run in a specific environment could set a "ds=no-check" flag on the kernel command line then the timing issue could be prevented. I realize for the nocloud case a user can set "ds=nocloud" on the kernel command line to work around the timing issue described herein. Also a "ds=no-check" would circumvent the basic intention of the generator to allow cloud-init to be installed anywhere and simply detect quickly an environment where cloud-init Python code should not be executed and thus safe boot time. My point is that, IMHO, timing issues in general cannot be avoided by ds-identify due to the nature of when systemd executes the generators. Thus giving users the general ability to disable ds-identify maybe useful. I am happy if I can be proven incorrect and the timing issue can be resolved. [1] https://www.freedesktop.org/wiki/Software/systemd/Generators/ To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1810859/+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
