[Yahoo-eng-team] [Bug 1922801] [NEW] Write an integration test for GH: #780
Public bug reported: The code in https://github.com/canonical/cloud-init/pull/780 is in need of an integration test. Let's use this as a place to hash out the design of it and any framework changes, instead of the comments of a soon-to-be-landed PR. ** Affects: cloud-init Importance: Wishlist Assignee: Thomas Stringer (trstringer) Status: Triaged -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1922801 Title: Write an integration test for GH: #780 Status in cloud-init: Triaged Bug description: The code in https://github.com/canonical/cloud-init/pull/780 is in need of an integration test. Let's use this as a place to hash out the design of it and any framework changes, instead of the comments of a soon-to-be-landed PR. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1922801/+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 1922742] [NEW] Failed: can't get Volume Group information from /dev/sda1
Public bug reported:
When running tests in LXD VMs (LXD containers don't perform disk setup,
as they don't have their own disks), I see:
2021-04-06 14:31:24,084 - helpers.py[DEBUG]: Running config-growpart using lock
()
2021-04-06 14:31:24,084 - cc_growpart.py[DEBUG]: No 'growpart' entry in cfg.
Using default: {'mode': 'auto', 'devices': ['/'], 'ignore_growroot_disabled':
False}
2021-04-06 14:31:24,084 - subp.py[DEBUG]: Running command ['growpart',
'--help'] with allowed return codes [0] (shell=False, capture=True)
2021-04-06 14:31:24,092 - util.py[DEBUG]: Reading from /proc/503/mountinfo
(quiet=False)
2021-04-06 14:31:24,092 - util.py[DEBUG]: Read 3726 bytes from
/proc/503/mountinfo
2021-04-06 14:31:24,093 - subp.py[DEBUG]: Running command ['lvm', 'lvs',
'/dev/sda1', '--options=vgname', '--noheadings'] with allowed return codes [0]
(shell=False, capture=True)
2021-04-06 14:31:24,138 - util.py[WARNING]: Failed: can't get Volume Group
information from /dev/sda1
2021-04-06 14:31:24,138 - util.py[DEBUG]: Failed: can't get Volume Group
information from /dev/sda1
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line
125, in get_pvs_for_lv
(out, _err) = subp.subp(["lvm", "lvs", devpath, "--options=vgname",
File "/usr/lib/python3/dist-packages/cloudinit/subp.py", line 293, in subp
raise ProcessExecutionError(stdout=out, stderr=err,
cloudinit.subp.ProcessExecutionError: Unexpected error while running command.
Command: ['lvm', 'lvs', '/dev/sda1', '--options=vgname', '--noheadings']
Exit code: 5
Reason: -
Stdout:
Stderr: Volume group "sda1" not found
Cannot process volume group sda1
2021-04-06 14:31:24,140 - util.py[DEBUG]: resize_devices took 0.048 seconds
2021-04-06 14:31:24,140 - handlers.py[DEBUG]: finish:
init-network/config-growpart: FAIL: running config-growpart with frequency
always
2021-04-06 14:31:24,140 - util.py[WARNING]: Running module growpart () failed
2021-04-06 14:31:24,142 - util.py[DEBUG]: Running module growpart () failed
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line
125, in get_pvs_for_lv
(out, _err) = subp.subp(["lvm", "lvs", devpath, "--options=vgname",
File "/usr/lib/python3/dist-packages/cloudinit/subp.py", line 293, in subp
raise ProcessExecutionError(stdout=out, stderr=err,
cloudinit.subp.ProcessExecutionError: Unexpected error while running command.
Command: ['lvm', 'lvs', '/dev/sda1', '--options=vgname', '--noheadings']
Exit code: 5
Reason: -
Stdout:
Stderr: Volume group "sda1" not found
Cannot process volume group sda1
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 884, in
_run_modules
ran, _r = cc.run(run_name, mod.handle, func_args,
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 185, in run
results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line
434, in handle
resized = util.log_time(logfunc=log.debug, msg="resize_devices",
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2348, in
log_time
ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line
358, in resize_devices
disk, ptnum = device_part_info(blockdev, is_lvm)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line
273, in device_part_info
lvm_rpath = get_pvs_for_lv(devpath)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line
132, in get_pvs_for_lv
raise ResizeFailedException(e) from e
cloudinit.config.cc_growpart.ResizeFailedException: Unexpected error while
running command.
Command: ['lvm', 'lvs', '/dev/sda1', '--options=vgname', '--noheadings']
Exit code: 5
Reason: -
Stdout:
Stderr: Volume group "sda1" not found
Cannot process volume group sda1
** Affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1922742
Title:
Failed: can't get Volume Group information from /dev/sda1
Status in cloud-init:
New
Bug description:
When running tests in LXD VMs (LXD containers don't perform disk
setup, as they don't have their own disks), I see:
2021-04-06 14:31:24,084 - helpers.py[DEBUG]: Running config-growpart using
lock ()
2021-04-06 14:31:24,084 - cc_growpart.py[DEBUG]: No 'growpart' entry in cfg.
Using default: {'mode': 'auto', 'devices': ['/'], 'ignore_growroot_disabled':
False}
2021-04-06 14:31:24,084 - subp.py[DEBUG]: Running command ['growpart',
'--help'] with
[Yahoo-eng-team] [Bug 1922739] [NEW] AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw'
Public bug reported: On a test LXD VM instance, I see: 2021-04-06 14:05:11,296 - util.py[WARNING]: failed stage init 2021-04-06 14:05:11,302 - util.py[DEBUG]: failed stage init Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 652, in status_wrapper ret = functor(name, args) File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 376, in main_init init.update() File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 371, in update self._store_raw_vendordata(self.datasource.get_vendordata2_raw(), File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 506, in get_vendordata2_raw return self.vendordata2_raw AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw' ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1922739 Title: AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw' Status in cloud-init: New Bug description: On a test LXD VM instance, I see: 2021-04-06 14:05:11,296 - util.py[WARNING]: failed stage init 2021-04-06 14:05:11,302 - util.py[DEBUG]: failed stage init Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 652, in status_wrapper ret = functor(name, args) File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 376, in main_init init.update() File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 371, in update self._store_raw_vendordata(self.datasource.get_vendordata2_raw(), File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 506, in get_vendordata2_raw return self.vendordata2_raw AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw' To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1922739/+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 1921124] [NEW] Randomly-set credentials not available within the instance
Public bug reported: As part of the fix for bug 1918303 in [0], we stopped emitting randomly- generated passwords to /var/log/cloud-init-output.log. This functionality _is_ used by some cloud-init consumers, most notably subiquity. We should reintroduce saving these passwords somewhere in the instance, securely, so that these use cases are not regressed. [0] https://github.com/canonical/cloud- init/commit/b794d426b9ab43ea9d6371477466070d86e10668 ** Affects: cloud-init Importance: Undecided Assignee: Dan Watkins (oddbloke) Status: In Progress ** Changed in: cloud-init Assignee: (unassigned) => Dan Watkins (oddbloke) ** Changed in: cloud-init Status: New => In Progress -- 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/1921124 Title: Randomly-set credentials not available within the instance Status in cloud-init: In Progress Bug description: As part of the fix for bug 1918303 in [0], we stopped emitting randomly-generated passwords to /var/log/cloud-init-output.log. This functionality _is_ used by some cloud-init consumers, most notably subiquity. We should reintroduce saving these passwords somewhere in the instance, securely, so that these use cases are not regressed. [0] https://github.com/canonical/cloud- init/commit/b794d426b9ab43ea9d6371477466070d86e10668 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1921124/+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 1905493] Re: cloud-init status --wait hangs indefinitely in a nested lxd container
Yep, that's what I've found; cloud-init is just waiting for its later stages to run, which are blocked by snapd.seeded.service exiting. ** Changed in: cloud-init Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1905493 Title: cloud-init status --wait hangs indefinitely in a nested lxd container Status in cloud-init: Invalid Status in snapd: Confirmed Status in dbus package in Ubuntu: New Status in systemd package in Ubuntu: Invalid Bug description: When booting a nested lxd container inside another lxd container (just a normal container, not a VM) (i.e. just L2), using cloud-init -status --wait, the "." is just printed off infinitely and never returns. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1905493/+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 1829410] Re: vendor_data2 not supported
*** This bug is a duplicate of bug 1841104 *** https://bugs.launchpad.net/bugs/1841104 Marked as a duplicate: the good news is that we've released a fix for this! ** This bug has been marked a duplicate of bug 1841104 Openstack's vendor_data2.json is not handled -- 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/1829410 Title: vendor_data2 not supported Status in cloud-init: Triaged Bug description: For the OpenStack datasource, I see some references to vendor_data2.json but it is not accessible via cloud.datasource.vendordata_pure or cloud.datasource.vendordata_raw or any other variable. Can full support be added for vendor_data2? It seems like it is supported, but looks like it is never requested or parsed. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1829410/+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 1829411] Re: vendor_data2 not supported
*** This bug is a duplicate of bug 1841104 *** https://bugs.launchpad.net/bugs/1841104 ** This bug is no longer a duplicate of bug 1829410 vendor_data2 not supported ** This bug has been marked a duplicate of bug 1841104 Openstack's vendor_data2.json is not handled -- 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/1829411 Title: vendor_data2 not supported Status in cloud-init: New Bug description: For the OpenStack datasource, I see some references to vendor_data2.json but it is not accessible via cloud.datasource.vendordata_pure or cloud.datasource.vendordata_raw or any other variable. Can full support be added for vendor_data2? It seems like it is supported, but looks like it is never requested or parsed. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1829411/+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 1917322] [NEW] cloudinit.net.get_devicelist includes "bonding_masters" if present
Public bug reported: $ ls -l /sys/class/net/ total 0 lrwxrwxrwx 1 root root0 Feb 26 21:51 bond0 -> ../../devices/virtual/net/bond0 -rw-r--r-- 1 root root 4096 Feb 26 21:51 bonding_masters lrwxrwxrwx 1 root root0 Feb 26 21:51 enp5s0 -> ../../devices/pci:00/:00:01.4/:05:00.0/virtio12/net/enp5s0 lrwxrwxrwx 1 root root0 Feb 26 21:51 lo -> ../../devices/virtual/net/lo lrwxrwxrwx 1 root root0 Feb 26 21:51 ovs-br -> ../../devices/virtual/net/ovs-br lrwxrwxrwx 1 root root0 Feb 26 21:51 ovs-br.100 -> ../../devices/virtual/net/ovs-br.100 lrwxrwxrwx 1 root root0 Feb 26 21:51 ovs-system -> ../../devices/virtual/net/ovs-system $ python3 -c "from cloudinit.net import get_devicelist; print(get_devicelist())" ['bonding_masters', 'enp5s0', 'bond0', 'ovs-system', 'ovs-br.100', 'lo', 'ovs-br'] ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1917322 Title: cloudinit.net.get_devicelist includes "bonding_masters" if present Status in cloud-init: New Bug description: $ ls -l /sys/class/net/ total 0 lrwxrwxrwx 1 root root0 Feb 26 21:51 bond0 -> ../../devices/virtual/net/bond0 -rw-r--r-- 1 root root 4096 Feb 26 21:51 bonding_masters lrwxrwxrwx 1 root root0 Feb 26 21:51 enp5s0 -> ../../devices/pci:00/:00:01.4/:05:00.0/virtio12/net/enp5s0 lrwxrwxrwx 1 root root0 Feb 26 21:51 lo -> ../../devices/virtual/net/lo lrwxrwxrwx 1 root root0 Feb 26 21:51 ovs-br -> ../../devices/virtual/net/ovs-br lrwxrwxrwx 1 root root0 Feb 26 21:51 ovs-br.100 -> ../../devices/virtual/net/ovs-br.100 lrwxrwxrwx 1 root root0 Feb 26 21:51 ovs-system -> ../../devices/virtual/net/ovs-system $ python3 -c "from cloudinit.net import get_devicelist; print(get_devicelist())" ['bonding_masters', 'enp5s0', 'bond0', 'ovs-system', 'ovs-br.100', 'lo', 'ovs-br'] To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1917322/+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 1901011] Re: Azure temporary disk not present for instance type
This bug is believed to be fixed in cloud-init in version 21.1. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1901011
Title:
Azure temporary disk not present for instance type
Status in cloud-init:
Fix Released
Bug description:
Cloud Provider: Azure
Instance type: Dsv4
The new Dv4, Dsv4, Ev4, and Esv4 instance types don't come with a
temporary disk at /dev/disk/cloud/azure_resource
So when I create/reboot one of these new instances I get longer reboot times
as cloud-init is waiting 2 minutes for this disk path to appear.
Looks like the function that looks for the disk is here -
https://git.launchpad.net/cloud-init/tree/cloudinit/sources/DataSourceAzure.py?id=93cebe009d116230850c770227e9ead5c490c0d0#n888
Log snippet:
```
2020-10-21 12:34:43,120 - handlers.py[DEBUG]: start:
init-network/activate-datasource: activating datasource
2020-10-21 12:34:43,120 - handlers.py[DEBUG]: start: azure-ds/activate:
activate
2020-10-21 12:34:43,120 - handlers.py[DEBUG]: start:
azure-ds/address_ephemeral_resize: address_ephemeral_resize
2020-10-21 12:34:43,120 - handlers.py[DEBUG]: start:
azure-ds/wait-for-ephemeral-disk: wait for ephemeral disk
2020-10-21 12:34:43,121 - util.py[DEBUG]: Azure ephemeral disk: Waiting up to
120 seconds for the following files: ['/dev/disk/cloud/azure_resource']
2020-10-21 12:36:43,160 - util.py[DEBUG]: Azure ephemeral disk: Still missing
files after 120 seconds: {'/dev/disk/cloud/azure_resource'}
2020-10-21 12:36:43,161 - DataSourceAzure.py[WARNING]: ephemeral device
'/dev/disk/cloud/azure_resource' did not appear after 120 seconds.
2020-10-21 12:36:43,161 - handlers.py[DEBUG]: finish:
azure-ds/wait-for-ephemeral-disk: SUCCESS: wait for ephemeral disk
2020-10-21 12:36:43,161 - handlers.py[DEBUG]: finish:
azure-ds/address_ephemeral_resize: SUCCESS: address_ephemeral_resize
```
I've looked in the instance metadata between a Dsv4 and Dsv3 and there
is nothing to indicate if this temporary disk will be present.
More than happy to make a patch to look for the instance type and skip
the call if its not needed.
Additional info:
Azure temporary disk VM list -
https://docs.microsoft.com/en-us/azure/virtual-machines/azure-vms-no-temp-disk#what-are-the-differences-between-these-new-vm-sizes-and-the-general-purpose-dv3dsv3-or-the-memory-optimized-ev3esv3-vm-sizes-that-i-am-used-to
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1901011/+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 1915460] Re: no way to suppress host key info on console
This bug is believed to be fixed in cloud-init in version 21.1. If this is still a problem for you, please make a comment and set the state back to New Thank you. ** Changed in: cloud-init Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1915460 Title: no way to suppress host key info on console Status in cloud-init: Fix Released Bug description: cc_keys_to_console does not have any way to prevent the keys being written to the console (beyond deleting write-ssh-key-fingerprints, which while actually ok for my use case is gross). I propose adding a "no_keys_to_console" config option, defaulting to False, that suppresses the output (modelled on what cc_ssh_authkey_fingerprints does). To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1915460/+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 1835584] Re: cloud-init might incorrectly consider reboot as new-instance during kernel upgrade or downgrade
This bug is believed to be fixed in cloud-init in version 21.1. If this is still a problem for you, please make a comment and set the state back to New Thank you. ** Changed in: cloud-init Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1835584 Title: cloud-init might incorrectly consider reboot as new-instance during kernel upgrade or downgrade Status in cloud-init: Fix Released Bug description: Between 4.14 kernel and 4.15 kernel this below commit changed the product uuid of a VM from uppercase to lowercase. Data Sources that use this number to represent instance-id (e.g., Azure) will go through new-instance code path at reboot following a kernel upgrade/downgrade (that is affected by the change). This is problematic for customers who provision with password on Azure because the password is not saved on disk new-instance provisioning will disables password access to VM in that case Commit: https://github.com/torvalds/linux/commit/712ff25450bd01366301eef81c33e865d901e7b7#diff-f2bd14bc67b5e2da67116bca971bbd0b Repro Steps: Deploy a 18.04-LTS latest VM on Azure (kernel version is 4.18.0-1023-Azure as of July 5th 2019). Downgrade the kernel to 4.14.119 (using the .deb packages here https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14.119/) Configure grub to boot into the 4.14 kernel. Observe in cloud-init log that new instance first boot is happening In my VM I can see the product uuid changed the casing 4.18 kernel: $ cat /sys/devices/virtual/dmi/id/product_uuid 1fd1b593-e79e-724c-9b33-d8634642d5f5 $ ls /var/lib/cloud/instances 1fd1b593-e79e-724c-9b33-d8634642d5f5 After downgrade: $ cat /sys/devices/virtual/dmi/id/product_uuid 1FD1B593-E79E-724C-9B33-D8634642D5F5 $ ls /var/lib/cloud/instances 1FD1B593-E79E-724C-9B33-D8634642D5F5 1fd1b593-e79e-724c-9b33-d8634642d5f5 DataSourceAzure.py is already using instance_id_matches_system_uuid, which converts the uuid to lowercase, to compare instance-id def check_instance_id(self, sys_cfg): # quickly (local check only) if self.instance_id is still valid return sources.instance_id_matches_system_uuid(self.get_instance_id()) However, the issue lies in stages.py's is_new_instance() method, which does not convert uuid to lowercase before comparison, which results in is_new_instance returning True when it should be False. This affects methods like apply_network_config, setup, activate, etc... To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1835584/+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 1841104] Re: Openstack's vendor_data2.json is not handled
This bug is believed to be fixed in cloud-init in version 21.1. If this is still a problem for you, please make a comment and set the state back to New Thank you. ** Changed in: cloud-init Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1841104 Title: Openstack's vendor_data2.json is not handled Status in cloud-init: Fix Released Bug description: Starting with Newton, Openstack adds a vendor_data2.json in the metadata (based on the DynamicJSON vendor data provider). However, cloud-init seems to not execute that. According to the code (https://git.launchpad.net/cloud-init/tree/cloudinit/sources/helpers/openstack.py#n247), only the "vendor_data.json" is taken into account. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1841104/+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 1916540] Re: Release 21.1
This bug is believed to be fixed in cloud-init in version 21.1. If this is still a problem for you, please make a comment and set the state back to New Thank you. ** Changed in: cloud-init Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1916540 Title: Release 21.1 Status in cloud-init: Fix Released Bug description: This bug tracks cloud-init's upstream release of 21.1. == Release Notes == Cloud-init release 21.1 is now available The 21.1 release: * spanned about 3 months * had 24 contributors from 25 domains * fixed 10 Launchpad issues Highlights: - New datasource for UpCloud - Introduced support for reading Openstack dynamic vendor0-data - Add support for VMWare's raw data feature - Add support for Azure VMs without ephemeral resource disks == Changelog == - Azure: Support for VMs without ephemeral resource disks. (#800) [Johnson Shi] (LP: #1901011) - cc_keys_to_console: add option to disable key emission (#811) [Michael Hudson-Doyle] (LP: #1915460) - integration_tests: introduce lxd_use_exec mark (#802) - azure: case-insensitive UUID to avoid new IID during kernel upgrade (#798) (LP: #1835584) - stale.yml: don't ask submitters to reopen PRs (#816) - integration_tests: fix use of SSH agent within tox (#815) - integration_tests: add UPGRADE CloudInitSource (#812) - integration_tests: use unique MAC addresses for tests (#813) - Update .gitignore (#814) - Port apt cloud_tests to integration tests (#808) - integration_tests: fix test_gh626 on LXD VMs (#809) - Fix attempting to decode binary data in test_seed_random_data test (#806) - Remove wait argument from tests with session_cloud calls (#805) - Datasource for UpCloud (#743) [Antti Myyrä] - test_gh668: fix failure on LXD VMs (#801) - openstack: read the dynamic metadata group vendor_data2.json (#777) [Andrew Bogott] (LP: #1841104) - includedir in suoders can be prefixed by "arroba" (#783) [Jordi Massaguer Pla] - [VMware] change default max wait time to 15s (#774) [xiaofengw-vmware] - Revert integration test associated with reverted #586 (#784) - Add jordimassaguerpla as contributor (#787) [Jordi Massaguer Pla] - Add Rick Harding to CLA signers (#792) [Rick Harding] - HACKING.rst: add clarifying note to LP CLA process section (#789) - Stop linting cloud_tests (#791) - cloud-tests: update cryptography requirement (#790) [Joshua Powers] - Remove 'remove-raise-on-failure' calls from integration_tests (#788) - Use more cloud defaults in integration tests (#757) - Adding self to cla signers (#776) [Andrew Bogott] - doc: avoid two warnings (#781) [Dan Kenigsberg] - Use proper spelling for Red Hat (#778) [Dan Kenigsberg] - Add antonyc to .github-cla-signers (#747) [Anton Chaporgin] - integration_tests: log image serial if available (#772) - Revert "ssh_util: handle non-default AuthorizedKeysFile config (#586)" (#775) - Release 20.4.1 (LP: #1911680) - Revert "ssh_util: handle non-default AuthorizedKeysFile config (#586)" - [VMware] Support cloudinit raw data feature (#691) [xiaofengw-vmware] - net: Fix static routes to host in eni renderer (#668) [Pavel Abalikhin] - .travis.yml: don't run cloud_tests in CI (#756) - test_upgrade: add some missing commas (#769) - cc_seed_random: update documentation and fix integration test (#771) (LP: #1911227) - Fix test gh-632 test to only run on NoCloud (#770) (LP: #1911230) - archlinux: fix package upgrade command handling (#768) [Bao Trinh] - integration_tests: add integration test for LP: #1910835 (#761) - Fix regression with handling of IMDS ssh keys (#760) [Thomas Stringer] - integration_tests: log cloud-init version in SUT (#758) - Add ajmyyra as contributor (#742) [Antti Myyrä] - net_convert: add some missing help text (#755) - Missing IPV6_AUTOCONF=no to render sysconfig dhcp6 stateful on RHEL (#753) [Eduardo Otubo] - doc: document missing IPv6 subnet types (#744) [Antti Myyrä] - Add example configuration for datasource `AliYun` (#751) [Xiaoyu Zhong] - integration_tests: add SSH key selection settings (#754) - fix a typo in man page cloud-init.1 (#752) [Amy Chen] - network-config-format-v2.rst: add Netplan Passthrough section (#750) - stale: re-enable post holidays (#749) - integration_tests: port ca_certs tests from cloud_tests (#732) - Azure: Add telemetry for poll IMDS (#741) [Johnson Shi] - doc: move testing section from HACKING to its own doc (#739) - No longer allow integration test failures on travis (#738) - stale: fix error in definition (#740) - integration_tests: set log-cli-level to INFO by default (#737) - PULL_REQUEST_TEMPLATE.md: use backticks around commit message (#736) - stale: disable check
[Yahoo-eng-team] [Bug 1916540] [NEW] Release 21.1
Public bug reported: This bug tracks cloud-init's upstream release of 21.1. == Release Notes == Cloud-init release 21.1 is now available The 21.1 release: * spanned about 3 months * had 24 contributors from 25 domains * fixed 10 Launchpad issues Highlights: - New datasource for UpCloud - Introduced support for reading Openstack dynamic vendor0-data - Add support for VMWare's raw data feature - Add support for Azure VMs without ephemeral resource disks == Changelog == - Azure: Support for VMs without ephemeral resource disks. (#800) [Johnson Shi] (LP: #1901011) - cc_keys_to_console: add option to disable key emission (#811) [Michael Hudson-Doyle] (LP: #1915460) - integration_tests: introduce lxd_use_exec mark (#802) - azure: case-insensitive UUID to avoid new IID during kernel upgrade (#798) (LP: #1835584) - stale.yml: don't ask submitters to reopen PRs (#816) - integration_tests: fix use of SSH agent within tox (#815) - integration_tests: add UPGRADE CloudInitSource (#812) - integration_tests: use unique MAC addresses for tests (#813) - Update .gitignore (#814) - Port apt cloud_tests to integration tests (#808) - integration_tests: fix test_gh626 on LXD VMs (#809) - Fix attempting to decode binary data in test_seed_random_data test (#806) - Remove wait argument from tests with session_cloud calls (#805) - Datasource for UpCloud (#743) [Antti Myyrä] - test_gh668: fix failure on LXD VMs (#801) - openstack: read the dynamic metadata group vendor_data2.json (#777) [Andrew Bogott] (LP: #1841104) - includedir in suoders can be prefixed by "arroba" (#783) [Jordi Massaguer Pla] - [VMware] change default max wait time to 15s (#774) [xiaofengw-vmware] - Revert integration test associated with reverted #586 (#784) - Add jordimassaguerpla as contributor (#787) [Jordi Massaguer Pla] - Add Rick Harding to CLA signers (#792) [Rick Harding] - HACKING.rst: add clarifying note to LP CLA process section (#789) - Stop linting cloud_tests (#791) - cloud-tests: update cryptography requirement (#790) [Joshua Powers] - Remove 'remove-raise-on-failure' calls from integration_tests (#788) - Use more cloud defaults in integration tests (#757) - Adding self to cla signers (#776) [Andrew Bogott] - doc: avoid two warnings (#781) [Dan Kenigsberg] - Use proper spelling for Red Hat (#778) [Dan Kenigsberg] - Add antonyc to .github-cla-signers (#747) [Anton Chaporgin] - integration_tests: log image serial if available (#772) - Revert "ssh_util: handle non-default AuthorizedKeysFile config (#586)" (#775) - Release 20.4.1 (LP: #1911680) - Revert "ssh_util: handle non-default AuthorizedKeysFile config (#586)" - [VMware] Support cloudinit raw data feature (#691) [xiaofengw-vmware] - net: Fix static routes to host in eni renderer (#668) [Pavel Abalikhin] - .travis.yml: don't run cloud_tests in CI (#756) - test_upgrade: add some missing commas (#769) - cc_seed_random: update documentation and fix integration test (#771) (LP: #1911227) - Fix test gh-632 test to only run on NoCloud (#770) (LP: #1911230) - archlinux: fix package upgrade command handling (#768) [Bao Trinh] - integration_tests: add integration test for LP: #1910835 (#761) - Fix regression with handling of IMDS ssh keys (#760) [Thomas Stringer] - integration_tests: log cloud-init version in SUT (#758) - Add ajmyyra as contributor (#742) [Antti Myyrä] - net_convert: add some missing help text (#755) - Missing IPV6_AUTOCONF=no to render sysconfig dhcp6 stateful on RHEL (#753) [Eduardo Otubo] - doc: document missing IPv6 subnet types (#744) [Antti Myyrä] - Add example configuration for datasource `AliYun` (#751) [Xiaoyu Zhong] - integration_tests: add SSH key selection settings (#754) - fix a typo in man page cloud-init.1 (#752) [Amy Chen] - network-config-format-v2.rst: add Netplan Passthrough section (#750) - stale: re-enable post holidays (#749) - integration_tests: port ca_certs tests from cloud_tests (#732) - Azure: Add telemetry for poll IMDS (#741) [Johnson Shi] - doc: move testing section from HACKING to its own doc (#739) - No longer allow integration test failures on travis (#738) - stale: fix error in definition (#740) - integration_tests: set log-cli-level to INFO by default (#737) - PULL_REQUEST_TEMPLATE.md: use backticks around commit message (#736) - stale: disable check for holiday break (#735) - integration_tests: log the path we collect logs into (#733) - .travis.yml: add (most) supported Python versions to CI (#734) - integration_tests: fix IN_PLACE CLOUD_INIT_SOURCE (#731) - cc_ca_certs: add RHEL support (#633) [cawamata] - Azure: only generate config for NICs with addresses (#709) [Thomas Stringer] - doc: fix CloudStack configuration example (#707) [Olivier Lemasle] - integration_tests: restrict test_lxd_bridge appropriately (#730) - Add integration tests for CLI functionality (#729) - Integration test for gh-626 (#728) - Some test_upgrade fixes (#726) -
[Yahoo-eng-team] [Bug 1915077] Re: genisoimage may be going away
** Also affects: cloud-utils (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1915077 Title: genisoimage may be going away Status in cloud-init: New Status in cloud-utils package in Ubuntu: New Bug description: It seems that cdrkit, which is where genisoimage comes from, is dead upstream and is likely to be removed from debian: https://lists.debian.org/debian-cloud/2021/02/msg00011.html Plenty of cloud-init docs and tutorials refer to genisoimage to create seed ISOs, it may be time to find something else. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1915077/+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 1377308] Re: booting cloud image without initramfs broken
Drive-by mark as Incomplete, as the way initramfses and cloud images interact has changed substantially since 2014. ** Changed in: cloud-init (Ubuntu Trusty) Status: Triaged => Won't Fix ** Changed in: cloud-init (Ubuntu) Status: Triaged => Incomplete ** Changed in: cloud-init Status: Triaged => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1377308 Title: booting cloud image without initramfs broken Status in cloud-init: Incomplete Status in cloud-init package in Ubuntu: Incomplete Status in cloud-init source package in Trusty: Won't Fix Bug description: Booting without a initramfs was broken by the cloud-init change for bug 1353008 (http://pad.lv/1353008). This affects arm guests where a bootloader is not used that would load kernel and initramfs. There are 2 workarounds: a.) remove the offensive code sudo mount-image-callback ubuntu.img -- \ sh -c 'f="$MOUNTPOINT/etc/init/cloud-init-local.conf"; sed -e "/^start on/s/ and mounted .*//" -i.dist $f && diff -u $f.dist $f' b.) register and boot with an initramfs This is done by i.) getting the initramfs out of the image: sudo mount-image-callback ubuntu.img -- \ sh -c 'cp $MOUNTPOINT/boot/initrd* . && chmod ugo+r initrd*' ii.) upload the initramfs to glance glance image-create --name=ubuntu-ramdisk --public \ --container-format ari --disk-format ari < initrd* record the ramdisk id iii.) register with --property ramdisk_id=$RAMDISK_ID normally for "ami" style images on arm, the user had been uploading with --property kernel_id=. now, you need to upload with: glance image-create --name="$NAME" \ --public --container-format ami --disk-format ami \ --property "kernel_id=$KERNEL_ID" \ --property "ramdisk_id=$RAMDISK_ID" \ < ubuntu.img c.) register 'kernel command line' to include 'rw'. glance image-create --property kernel_args="root=/dev/vda rw" Related bugs: * bug 1031065:cloud-init-nonet runs 'start networking' explicitly * bug 643289: [mountall] idmapd does not starts to work after system reboot * bug 1353008:[cloud-init] MAAS Provider: LXC did not get DHCP address, stuck in "pending" ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: cloud-init 0.7.5-0ubuntu1.2 ProcVersionSignature: User Name 3.13.0-36.63-generic 3.13.11.6 Uname: Linux 3.13.0-36-generic aarch64 ApportVersion: 2.14.1-0ubuntu3.4 Architecture: arm64 Date: Thu Jan 1 00:02:09 1970 Ec2AMI: ami-0007 Ec2AMIManifest: FIXME Ec2AvailabilityZone: nova Ec2InstanceType: m1.5GB Ec2Kernel: aki-0005 Ec2Ramdisk: ari-0003 PackageArchitecture: all ProcEnviron: TERM=screen PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: cloud-init UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.init.cloud.init.local.conf: 2014-10-03T19:49:16.813801 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1377308/+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 1908287] Re: cloud-init exits early on ec2 after reboot
Correct, I think this is a pycloudlib issue.
** Changed in: cloud-init
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1908287
Title:
cloud-init exits early on ec2 after reboot
Status in cloud-init:
Invalid
Bug description:
Possibly duplicate of or related to bug #1890528 .
When rebooting an ec2 instance after a "cloud-init clean --logs",
"cloud-init status --wait --long" will exit early with non-0 status,
but a later subsequent run of "cloud-init status --wait --long" will
wait and return cleanly.
To reproduce, create an example test file at
tests/integration_tests/test_example.py:
```
def test_ec2(client):
client.execute('cloud-init clean --logs')
client.restart(raise_on_cloudinit_failure=True)
```
Run with:
```
export CLOUD_INIT_PLATFORM=ec2
export CLOUD_INIT_CLOUD_INIT_SOURCE=NONE
pytest -s tests/integration_tests/test_example.py
```
Relevant output from failure:
```
def _wait_for_cloudinit(self, *, raise_on_failure: bool):
"""Wait until cloud-init has finished.
:param raise_on_failure:
When `True`, if the process waiting for cloud-init exits non-zero
then this method will raise an `OSError`.
"""
self._log.debug('_wait_for_cloudinit to complete')
result = self.execute("cloud-init status --help")
has_wait = "--wait" in result.stdout
if has_wait:
cmd = ["cloud-init", "status", "--wait", "--long"]
else:
# runlevel 'N 2' supports distros without recent cloud-init
# (e.g. trusty).
runlevel_result = (
'[ "$(runlevel)" = "N 2" ] && '
"[ -f /run/cloud-init/result.json ]"
)
cmd = (
"i=0; while [ $i -lt {} ] && i=$(($i+1)); do {} && exit 0;"
" sleep 1; done; exit 1".format(
self.boot_timeout, runlevel_result
)
)
result = self.execute(cmd, description='waiting for start')
if raise_on_failure and result.failed:
raise OSError(
'cloud-init failed to start: out: %s error: %s' % (
>result.stdout, result.stderr
)
)
E OSError: cloud-init failed to start: out: error:
../pycloudlib/pycloudlib/instance.py:427: OSError
```
I see no indication in the logs of any problem or failure.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1908287/+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 1911227] Re: cc_seed_random: unexpectedly appends cloud's random_seed to specified seed data
The PR has landed, as this is a doc and test change, we don't need to wait for a release to mark this Fix Released. ** Changed in: cloud-init Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1911227 Title: cc_seed_random: unexpectedly appends cloud's random_seed to specified seed data Status in cloud-init: Fix Released Bug description: The test_seed_random_data test specifies this user-data: #cloud-config random_seed: data: 'MYUb34023nD:LFDK10913jk;dfnk:Df' encoding: raw file: /root/seed and asserts that that is the exact content of /root/seed. If we're using a datasource which sets random_seed in its metadata (i.e. Azure and OpenStack, at least), this test fails: cc_seed_random will _append_ the cloud's random_seed to the given data before writing it out. To be clear, the bug here is that this is unexpected: we do not document this behaviour. I can't think of a compelling case for not behaving in this way: more entropy is good, and we have write_files if users really do want to write out exact content to a path. The TestSeedRandomData.test_seed_random_data integration test assumes the "exact writing" behaviour, so will also need to be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1911227/+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 1910408] Re: Cubic appends characters to /etc/os-release and /etc/lsb-release breaking the new automated installation method for Ubuntu
Sounds like there's nothing for cloud-init here; thanks all! ** Changed in: cloud-init Status: New => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1910408 Title: Cubic appends characters to /etc/os-release and /etc/lsb-release breaking the new automated installation method for Ubuntu Status in cloud-init: Won't Fix Status in Cubic: Fix Released Bug description: During the automated installation of an iso, if cloud-init uses the DataSourceNoCloud, then it will check for block devices and read the /etc/os-release and /etc/lsb-release files, parsing them for distribution specific information. However, Cubic appends its own information onto the PRETTY_NAME and DISTRIB_DESCRIPTION lines for those two files, causing cloud-init to break, and any automated provisioning to fail. This can be fixed in cloud-init by using proper os.path.join, or os.sep, etc., but this is unlikely to happen soon. Cubic should provided better documentation about any cute characters it writes into the distribution. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1910408/+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 1910835] Re: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
** Changed in: cloud-init
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1910835
Title:
Azure IMDS publicKeys contain \r\n which prevents ssh access to vms
using cloud-generated ssh keys.
Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Fix Released
Status in cloud-init source package in Bionic:
Fix Released
Status in cloud-init source package in Focal:
Fix Released
Status in cloud-init source package in Groovy:
Fix Released
Status in cloud-init source package in Hirsute:
Fix Released
Bug description:
== Begin SRU Template ==
[Impact]
The previous version of cloud-init used OpenSSL to process the SSH keys
provided by the Azure platform. cloud-init 20.4 replaced that code with a more
efficient implementation, but one which did not use OpenSSL: this meant that
users passing certificates to instances, or users generating SSH keys in
Azure's web UI (which inserts \r\n sequences into the public key content), were
regressed: their certificates and malformed SSH keys were no longer handled, so
they could fail to gain access to newly-launched instances.
This release is only a single functional cherry-pick which solely
affects Azure platform. It is a critical bug we wish to release as
soon as possible
* Azure: cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
The functional changeset here introduces a raise KeyError exception
which forces cloud-init to revert to previous released logic of the
previous cloud-init public release 20.3.
[Test Case]
As this is a single commit backport, the cloud-init SRU exception need
not apply. An upstream integration test has been written for this
issue (https://github.com/canonical/cloud-
init/blob/master/tests/integration_tests/bugs/test_lp1910835.py).
A full run of the upstream test suite on Azure will therefore
regression test the update generally and test this issue specifically:
a log of a test run for each suite will be attached.
[Regression Potential]
The proposed change only modifies code paths used on Azure,
specifically to revert to a previous behaviour: users unaffected by
the bug should see no change (their keys will get to their instance
via a different route), and users affected by the bug would have been
unable to access their instances before (so cannot be relying on this
behaviour in a way which we could break by fixing it).
[Discussion]
This should only affect public Azure VM launched which use Azure to
--generate-ssh-keys either from the dashboard or from the `az cli`
Any other cloud-platform is not affected by this change.
== End SRU Template ==
* cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
== Original Description ==
cloud-init 20.4 or later will incorrectly add Azure publicKeys to
.ssh/authorized_keys preventing ssh access for cloud-generated keys.
To reproduce: launch an ubuntu VM from the portal.azure.com choosing
to generate new ssh key.
When the instance is launched you can see that the ssh-rsa content
provided in the metadata publicKeys value contains CRLF characters
(\r\n) thus splitting the content of the pubkey onto multiple lines
when it is rendered into .ssh/authorized_keys.
the solution is either for IMDS to stop adding the CRLF characters or
cloud-init to strip them out.
Here is the IMDS value provided to cloud-init
cloud-init query --format '{{ds.meta_data.imds.compute.publicKeys}}'
[{'keyData': 'ssh-rsa
B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d\r\nk/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R\r\n9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW\r\nlkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq\r\n4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7\r\n6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu\r\niKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht\r\n6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9\r\nS2mLJ6Peu/HDwd88E8Wqiv3eAsjcaCRH3QiQVaU=
generated-by-azure\r\n', 'path': '/home/ubuntu/.ssh/authorized_keys'}]
cloud-init renders this directly to .ssh/authorized_keys without
processing the string, resulting in an invalid keyline:
ssh-rsa B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d
k/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R^M
9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW^M
lkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq^M
4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7^M
6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu^M
[Yahoo-eng-team] [Bug 1911230] Re: `test_datasource_rbx_no_stacktrace` incorrectly runs on all clouds
Fixed in https://github.com/canonical/cloud-init/pull/770 (and as this is a testing change, no need to wait for a release to Fix Released it). ** Changed in: cloud-init Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1911230 Title: `test_datasource_rbx_no_stacktrace` incorrectly runs on all clouds Status in cloud-init: Fix Released Bug description: It makes assumptions about the platform it's testing on, so should be limited to platforms where we expect it to work. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1911230/+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 1911227] [NEW] cc_seed_random: unexpectedly appends cloud's random_seed to specified seed data
Public bug reported: The test_seed_random_data test specifies this user-data: #cloud-config random_seed: data: 'MYUb34023nD:LFDK10913jk;dfnk:Df' encoding: raw file: /root/seed and asserts that that is the exact content of /root/seed. If we're using a datasource which sets random_seed in its metadata (i.e. Azure and OpenStack, at least), this test fails: cc_seed_random will _append_ the cloud's random_seed to the given data before writing it out. To be clear, the bug here is that this is unexpected: we do not document this behaviour. I can't think of a compelling case for not behaving in this way: more entropy is good, and we have write_files if users really do want to write out exact content to a path. The TestSeedRandomData.test_seed_random_data integration test assumes the "exact writing" behaviour, so will also need to be updated. ** Affects: cloud-init Importance: Medium Assignee: Dan Watkins (oddbloke) Status: Triaged ** Tags: docs ** Changed in: cloud-init Status: New => Triaged ** Changed in: cloud-init Importance: Undecided => Medium ** Summary changed: - cc_seed_random: unexpectedly appends cloud's random_seed to specified seed + cc_seed_random: unexpectedly appends cloud's random_seed to specified seed data ** Description changed: The test_seed_random_data test specifies this user-data: #cloud-config random_seed: - data: 'MYUb34023nD:LFDK10913jk;dfnk:Df' - encoding: raw - file: /root/seed + data: 'MYUb34023nD:LFDK10913jk;dfnk:Df' + encoding: raw + file: /root/seed and asserts that that is the exact content of /root/seed. If we're using a datasource which sets random_seed in its metadata (i.e. Azure and OpenStack, at least), this test fails: cc_seed_random will _append_ the cloud's random_seed to the given data before writing it out. To be clear, the bug here is that this is unexpected: we do not document this behaviour. I can't think of a compelling case for not behaving in this way: more entropy is good, and we have write_files if users really do want to write out exact content to a path. + + The TestSeedRandomData.test_seed_random_data integration test assumes + the "exact writing" behaviour, so will also need to be updated. -- 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/1911227 Title: cc_seed_random: unexpectedly appends cloud's random_seed to specified seed data Status in cloud-init: Triaged Bug description: The test_seed_random_data test specifies this user-data: #cloud-config random_seed: data: 'MYUb34023nD:LFDK10913jk;dfnk:Df' encoding: raw file: /root/seed and asserts that that is the exact content of /root/seed. If we're using a datasource which sets random_seed in its metadata (i.e. Azure and OpenStack, at least), this test fails: cc_seed_random will _append_ the cloud's random_seed to the given data before writing it out. To be clear, the bug here is that this is unexpected: we do not document this behaviour. I can't think of a compelling case for not behaving in this way: more entropy is good, and we have write_files if users really do want to write out exact content to a path. The TestSeedRandomData.test_seed_random_data integration test assumes the "exact writing" behaviour, so will also need to be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1911227/+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 1911230] [NEW] `test_datasource_rbx_no_stacktrace` incorrectly runs on all clouds
Public bug reported: It makes assumptions about the platform it's testing on, so should be limited to platforms where we expect it to work. ** Affects: cloud-init Importance: Medium Assignee: James Falcon (falcojr) Status: In Progress -- 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/1911230 Title: `test_datasource_rbx_no_stacktrace` incorrectly runs on all clouds Status in cloud-init: In Progress Bug description: It makes assumptions about the platform it's testing on, so should be limited to platforms where we expect it to work. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1911230/+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 1896532] Re: Ec2Datasource fails in environments without IMDSv2
Thanks for the update, David! I'll move this to Invalid, as there is now no work required on our end. (If you don't think that's correct, please do let us know, of course!) ** Changed in: cloud-init Status: Triaged => 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/1896532 Title: Ec2Datasource fails in environments without IMDSv2 Status in cloud-init: Invalid Bug description: On AWS regions that do not have IMDSv2 available, cloud-init fails to read user-data via the Ec2Datasource. This bug was introduced in the following change: https://bugs.launchpad.net/cloud-init/+bug/1866290 The change in that bug incorrectly assumes that a status code of 403 means the IMDS is disabled entirely. > The Ec2 IMDSv2 latest/api/token route can be set as disabled and return a 403 indefinitely for an instance. In reality, there are some regions where IMDSv2 is currently unsupported. In those regions, a 403 is still returned, but IMDSv1 is enabled and working. The end result is that cloud-init versions later than 20.1-9-g1f860e5a-0ubuntu1 are unable to retrieve user-data from the IMDS in affected regions. I am unable to attach the requested log because the region where I observed this behavior is physically disconnected from the internet. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1896532/+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 1691489] Re: fstab entries written by cloud-config may not be mounted
** Changed in: cloud-init Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1691489 Title: fstab entries written by cloud-config may not be mounted Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Confirmed Status in cloud-init source package in Xenial: Confirmed Status in cloud-init source package in Yakkety: Won't Fix Status in cloud-init source package in Zesty: Won't Fix Status in cloud-init source package in Artful: Won't Fix Bug description: === Begin SRU Template === [Impact] There is a race condition on a re-deployment of cloud-init on Azure where /mnt will not get properly formatted or mounted. This is due to "dirty" entries in /etc/fstab that cause a device to be busy when cloud-init goes to format it. This shows itself usually as 'mkfs' complaining that the device is busy. The cause is that systemd starts an fsck and collides with cloud-init re-formatting the disk. The problem can be seen other places but seemed to be most reproducible and originally found on Azure. [Test Case] 1.) Launch a Azure vm, ideally size L32S. 2.) Log in and verify the system properly mounted /mnt. 3.) Re-deploy the vm through the web ui and try again. [Regression Potential] Worst case scenario, these changes unnecessarily slow down boot and do not fix the problem. [Regression] This SRU change caused bug 1717477. [Other Info] Upstream commit at https://git.launchpad.net/cloud-init/commit/?id=1f5489c258 === End SRU Template === As reported in bug 1686514, sometimes /mnt will not get mounted when re-delpoying or stopping-then-starting a Azure vm of L32S. This is probably a more generic issue, I suspect shown due to the speed of disks on these systems. Related bugs: * bug 1686514: Azure: cloud-init does not handle reformatting GPT partition ephemeral disks * bug 1717477: cloud-init generates ordering cycle via After=cloud-init in systemd-fsck To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1691489/+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 1905493] Re: cloud-init status --wait hangs indefinitely in a nested lxd container
Hi Ian, I've just launched such a container and I see a bunch of non-cloud-init errors in the log and when I examine `systemctl list-jobs`, I see that the two running jobs are systemd-logind.service and snapd.seeded.service: root@certain-cod:~# systemctl list-jobs JOB UNIT TYPE STATE 114 cloud-final.service start waiting 125 snapd.autoimport.service start waiting 143 systemd-update-utmp-runlevel.service start waiting 116 cloud-config.service start waiting 1 graphical.target start waiting 691 systemd-logind.service start running 99 unattended-upgrades.service start waiting 110 cloud-init.targetstart waiting 115 snapd.seeded.service start running 2 multi-user.targetstart waiting 10 jobs listed. Examining the journal, I see that systemd-logind.service is in a restart loop: root@certain-cod:~# journalctl -u systemd-logind.service | grep Failed\ w Dec 01 22:37:43 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. Dec 01 22:39:13 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. Dec 01 22:40:44 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. Dec 01 22:42:14 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. Dec 01 22:43:44 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. Dec 01 22:45:14 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. Dec 01 22:46:45 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. Dec 01 22:48:15 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. Dec 01 22:49:45 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. This is blocking boot before cloud-init's later stages run, so as it is correctly indicating that it hasn't yet completed, I'm marking this Invalid for cloud-init. I'll add a systemd task instead, as that looks to be the source of the issue. Cheers, Dan ** Changed in: cloud-init Status: New => Invalid ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1905493 Title: cloud-init status --wait hangs indefinitely in a nested lxd container Status in cloud-init: Invalid Status in systemd package in Ubuntu: New Bug description: When booting a nested lxd container inside another lxd container (just a normal container, not a VM) (i.e. just L2), using cloud-init -status --wait, the "." is just printed off infinitely and never returns. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1905493/+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 1812676] Re: cloud-init-per mishandles commands with dashes
** Changed in: cloud-init Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1812676 Title: cloud-init-per mishandles commands with dashes Status in cloud-init: Fix Released Bug description: It was found that when there is a dash in cloud-init-per command name and cloud-init-per is executed through cloud-init's bootcmd, e.g: bootcmd: - cloud-init-per instance mycmd-bootcmd /usr/bin/mycmd the command is executed on each boot. However, running the same cloud-init-per command manually after boot doesn't reveal the issue. Turns out the issue comes from 'migrator' cloud-init module which renames all files in /var/lib/cloud/instance/sem/ replacing dashes with underscores. As migrator runs before bootcmd it renames /var/lib/cloud/instance/sem/bootper.mycmd-bootcmd.instance to /var/lib/cloud/instance/sem/bootper.mycmd_bootcmd.instance so cloud-init-per doesn't see it and thinks that the comment was never ran before. On next boot the sequence repeats. There are multiple ways to resolve the issue. This patch takes the following approach: 'canonicalize' sem names by replacing dashes with underscores (this is consistent with post-'migrator' contents of /var/lib/cloud/instance/sem/). We, however, need to be careful: in case someone had a command with dashes before and he had migrator module enables we need to see the old sem file (or the command will run again and this can be as bad as formatting a partition!) so we add a small 'migrator' part to cloud-init-per script itself checking for legacy sem names. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1812676/+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 1894887] [NEW] cloud-init's cc_lxd module fails to create a lxd bridge when running against lxd 4.0.3
Public bug reported: Between 3.0.3 (the lxd version in bionic) and 4.0.3 (the lxd version in focal), lxd has addressed an internal accounting bug regarding network interfaces and profiles. Specifically, this means that after `lxd init --auto --storage-backend dir` on each system, we see different output for `lxc network show lxdbr0`. On 3.0.3, it includes this line: used_by: [] whereas on 4.0.3, it includes: used_by: - /1.0/profiles/default It's important to note that on _both_ versions, `lxc profile show default` indicates that `lxdbr0` is used by the default profile; the change is that lxd now accurately tracks this fact when examining `lxdbr0`. This change also means that `lxdbr0` cannot be removed immediately: you first have to remove it from the default profile. Currently, cloud-init removes it without attempting to remove it from the default profile first. Removal fails (and is ignored, which may be a separate bug), so when we go to create the network, lxd gives us: "Error: The network already exists" ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1894887 Title: cloud-init's cc_lxd module fails to create a lxd bridge when running against lxd 4.0.3 Status in cloud-init: New Bug description: Between 3.0.3 (the lxd version in bionic) and 4.0.3 (the lxd version in focal), lxd has addressed an internal accounting bug regarding network interfaces and profiles. Specifically, this means that after `lxd init --auto --storage-backend dir` on each system, we see different output for `lxc network show lxdbr0`. On 3.0.3, it includes this line: used_by: [] whereas on 4.0.3, it includes: used_by: - /1.0/profiles/default It's important to note that on _both_ versions, `lxc profile show default` indicates that `lxdbr0` is used by the default profile; the change is that lxd now accurately tracks this fact when examining `lxdbr0`. This change also means that `lxdbr0` cannot be removed immediately: you first have to remove it from the default profile. Currently, cloud-init removes it without attempting to remove it from the default profile first. Removal fails (and is ignored, which may be a separate bug), so when we go to create the network, lxd gives us: "Error: The network already exists" To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1894887/+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 1531880] Re: Failed to start Initial cloud-init job (pre-networking)
Hey folks, I believe that this has been fixed in cloud-init 20.3 (specifically this commit: https://github.com/canonical/cloud- init/commit/0755cff078d5931e1d8e151bdcb84afb92bc0f02) so I'm going to move this to Fix Released. If you are seeing this error on an earlier version of cloud-init, it generally indicates that cloud-init failed on a _previous_ boot (because before that fix, a failed boot meant it would incorrectly create a directory where a symlink should have been, leading to the `IsADirectoryError` when the old not-actually-a-symlink is `rm`d on subsequent boots). If you can identify the cause of this earlier failure, please feel free to file a bug for it! Thanks, Dan ** Changed in: cloud-init Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1531880 Title: Failed to start Initial cloud-init job (pre-networking) Status in cloud-init: Fix Released Bug description: Linux Ubuntu-Gnome-Server 4.2.0-22-generic #27-Ubuntu SMP Thu Dec 17 22:57:08 UTC 2015 x86_64 Cloud-init 0.7.7 systemctl -l status cloud-init-local ● cloud-init-local.service - Initial cloud-init job (pre-networking) Loaded: loaded (/lib/systemd/system/cloud-init-local.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Thu 2016-01-07 15:34:33 CET; 6min ago Process: 961 ExecStart=/usr/bin/cloud-init init --local (code=exited, status=1/FAILURE) Main PID: 961 (code=exited, status=1/FAILURE) Jan 07 15:34:33 Ubuntu-Gnome-Server cloud-init[961]: File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1547, in del_file Jan 07 15:34:33 Ubuntu-Gnome-Server cloud-init[961]: raise e Jan 07 15:34:33 Ubuntu-Gnome-Server cloud-init[961]: File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1544, in del_file Jan 07 15:34:33 Ubuntu-Gnome-Server cloud-init[961]: os.unlink(path) Jan 07 15:34:33 Ubuntu-Gnome-Server cloud-init[961]: IsADirectoryError: [Errno 21] Is a directory: '/var/lib/cloud/instance' Jan 07 15:34:33 Ubuntu-Gnome-Server cloud-init[961]: Jan 07 15:34:33 Ubuntu-Gnome-Server systemd[1]: cloud-init-local.service: Main process exited, code=exited, status=1/FAILURE Jan 07 15:34:33 Ubuntu-Gnome-Server systemd[1]: Failed to start Initial cloud-init job (pre-networking). Jan 07 15:34:33 Ubuntu-Gnome-Server systemd[1]: cloud-init-local.service: Unit entered failed state. Jan 07 15:34:33 Ubuntu-Gnome-Server systemd[1]: cloud-init-local.service: Failed with result 'exit-code'. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1531880/+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 1885327] [NEW] util.mount_cb will create an unused temporary directory if the passed `device` is already mounted
Public bug reported: The tmpdir creation happens before (and around, as a contextmanager) the determination of whether or not a mount will be needed. This could be improved. ** Affects: cloud-init Importance: Wishlist Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1885327 Title: util.mount_cb will create an unused temporary directory if the passed `device` is already mounted Status in cloud-init: New Bug description: The tmpdir creation happens before (and around, as a contextmanager) the determination of whether or not a mount will be needed. This could be improved. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1885327/+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 1884979] [NEW] util.mount_cb only supports passing through a single (positional) argument to the wrapped function
Public bug reported: This makes it difficult to use with a function that needs to take more than a single positional parameter, or any keyword arguments; you have to partially apply the function before calling mount_cb. I propose adding `args` and `kwargs` parameters, which will be passed to the callback function using *args and **kwargs. (For bonus points, refactor all current callsites to pass `args` so we can drop the `data` argument entirely.) ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884979 Title: util.mount_cb only supports passing through a single (positional) argument to the wrapped function Status in cloud-init: New Bug description: This makes it difficult to use with a function that needs to take more than a single positional parameter, or any keyword arguments; you have to partially apply the function before calling mount_cb. I propose adding `args` and `kwargs` parameters, which will be passed to the callback function using *args and **kwargs. (For bonus points, refactor all current callsites to pass `args` so we can drop the `data` argument entirely.) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884979/+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 1884618] Re: cloudinit.net refactor: is_connected
This function is actually unused, so we're dropping it in https://github.com/canonical/cloud-init/pull/453. ** Changed in: cloud-init Status: Triaged => 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/1884618 Title: cloudinit.net refactor: is_connected Status in cloud-init: Invalid Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884618/+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 1884620] Re: cloudinit.net refactor: is_present
This function is actually unused, so we're dropping it in https://github.com/canonical/cloud-init/pull/453. ** Changed in: cloud-init Status: Triaged => 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/1884620 Title: cloudinit.net refactor: is_present Status in cloud-init: Invalid Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884620/+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 1884624] Re: cloudinit.net refactor: is_wireless
This function is actually unused, so we're dropping it in https://github.com/canonical/cloud-init/pull/453. ** Changed in: cloud-init Status: Triaged => 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/1884624 Title: cloudinit.net refactor: is_wireless Status in cloud-init: Invalid Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884624/+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 1884606] [NEW] cloudinit.net refactor: find_fallback_nic
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884606 Title: cloudinit.net refactor: find_fallback_nic Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884606/+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 1884603] [NEW] cloudinit.net refactor: device_devid
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884603 Title: cloudinit.net refactor: device_devid Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884603/+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 1884617] [NEW] cloudinit.net refactor: is_bridge
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884617 Title: cloudinit.net refactor: is_bridge Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884617/+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 1884613] [NEW] cloudinit.net refactor: get_interfaces_by_mac
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884613 Title: cloudinit.net refactor: get_interfaces_by_mac Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884613/+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 1884604] [NEW] cloudinit.net refactor: device_driver
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884604 Title: cloudinit.net refactor: device_driver Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884604/+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 1884609] [NEW] cloudinit.net refactor: get_ib_hwaddrs_by_interface
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884609 Title: cloudinit.net refactor: get_ib_hwaddrs_by_interface Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884609/+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 1884610] [NEW] cloudinit.net refactor: get_ib_interface_hwaddr
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884610 Title: cloudinit.net refactor: get_ib_interface_hwaddr Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884610/+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 1884616] [NEW] cloudinit.net refactor: is_bond
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884616 Title: cloudinit.net refactor: is_bond Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884616/+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 1884605] [NEW] cloudinit.net refactor: extract_physdevs
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884605 Title: cloudinit.net refactor: extract_physdevs Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884605/+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 1884607] [NEW] cloudinit.net refactor: generate_fallback_config
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884607 Title: cloudinit.net refactor: generate_fallback_config Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884607/+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 1884608] [NEW] cloudinit.net refactor: get_devicelist
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884608 Title: cloudinit.net refactor: get_devicelist Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884608/+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 1884615] [NEW] cloudinit.net refactor: interface_has_own_mac
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884615 Title: cloudinit.net refactor: interface_has_own_mac Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884615/+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 1884611] [NEW] cloudinit.net refactor: get_interface_mac
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884611 Title: cloudinit.net refactor: get_interface_mac Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884611/+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 1884612] [NEW] cloudinit.net refactor: get_interfaces
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884612 Title: cloudinit.net refactor: get_interfaces Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884612/+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 1884614] [NEW] cloudinit.net refactor: get_master
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884614 Title: cloudinit.net refactor: get_master Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884614/+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 1884600] [NEW] cloudinit.net refactor: _get_current_rename_info
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884600 Title: cloudinit.net refactor: _get_current_rename_info Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884600/+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 1884601] [NEW] cloudinit.net refactor: _rename_interfaces
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884601 Title: cloudinit.net refactor: _rename_interfaces Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884601/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1884602] [NEW] cloudinit.net refactor: apply_network_config_names
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884602 Title: cloudinit.net refactor: apply_network_config_names Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884602/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1884624] [NEW] cloudinit.net refactor: is_wireless
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884624 Title: cloudinit.net refactor: is_wireless Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884624/+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 1884620] [NEW] cloudinit.net refactor: is_present
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884620 Title: cloudinit.net refactor: is_present Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884620/+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 1884623] [NEW] cloudinit.net refactor: is_vlan
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884623 Title: cloudinit.net refactor: is_vlan Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884623/+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 1884618] [NEW] cloudinit.net refactor: is_connected
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884618 Title: cloudinit.net refactor: is_connected Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884618/+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 1884619] [NEW] cloudinit.net refactor: is_physical
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884619 Title: cloudinit.net refactor: is_physical Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884619/+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 1884626] [NEW] cloudinit.net refactor: wait_for_physdevs
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884626 Title: cloudinit.net refactor: wait_for_physdevs Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884626/+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 1884621] [NEW] cloudinit.net refactor: is_renamed
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884621 Title: cloudinit.net refactor: is_renamed Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884621/+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 1884625] [NEW] cloudinit.net refactor: master_is_bridge_or_bond
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884625 Title: cloudinit.net refactor: master_is_bridge_or_bond Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884625/+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 1884622] [NEW] cloudinit.net refactor: is_up
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884622 Title: cloudinit.net refactor: is_up Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884622/+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 1884627] [NEW] cloudinit.net refactor: get_dev_features
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884627 Title: cloudinit.net refactor: get_dev_features Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884627/+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 1884628] [NEW] cloudinit.net refactor: has_netfail_standby_feature
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884628 Title: cloudinit.net refactor: has_netfail_standby_feature Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884628/+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 1884632] [NEW] cloudinit.net refactor: is_netfail_standby
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884632 Title: cloudinit.net refactor: is_netfail_standby Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884632/+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 1884629] [NEW] cloudinit.net refactor: is_netfailover
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884629 Title: cloudinit.net refactor: is_netfailover Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884629/+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 1884630] [NEW] cloudinit.net refactor: is_netfail_master
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884630 Title: cloudinit.net refactor: is_netfail_master Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884630/+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 1884631] [NEW] cloudinit.net refactor: is_netfail_primary
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- 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/1884631 Title: cloudinit.net refactor: is_netfail_primary Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884631/+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 1884599] [NEW] cloudinit.net refactor: TEST BUG
Public bug reported: This bug report is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the named function. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Invalid ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Changed in: cloud-init Status: Triaged => 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/1884599 Title: cloudinit.net refactor: TEST BUG Status in cloud-init: Invalid Bug description: This bug report is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the named function. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884599/+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 1883666] Re: readdocs: MAAS datasource section is empty and link is broken
As this is a doc bug and the fix is available on ReadTheDocs, I'm going to mark this Fix Released. ** Changed in: cloud-init Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1883666 Title: readdocs: MAAS datasource section is empty and link is broken Status in cloud-init: Fix Released Bug description: When looking for information about the MAAS datasource, I landed on [1]. That page is marked as TODO and the link should be updated to [3] or [4]. The closest to finding what the MAAS datasource does is the source code at [2]. 1. https://cloudinit.readthedocs.io/en/latest/topics/datasources/maas.html 2. https://github.com/canonical/cloud-init/blob/4261ae538563d262bc76b8c55f7cc0c8abb14b00/cloudinit/sources/DataSourceMAAS.py 3. https://maas.io/ 4. https://maas.io/docs To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1883666/+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 1883903] [NEW] cc_final_message will create /var/lib/cloud/instance as a directory if the symlink does not exist
Public bug reported: cc_final_message calls util.write_file, which calls ensure_dir; if nothing has caused the symlink to be created, then this means that /var/lib/cloud/instance will be a directory, and future boots will fail because they fail to remove it (because it's a directory, so can't just be `rm`d.) (We're seeing this in bug 1883661; I don't think it's the root cause, hence this separate bug.) ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1883903 Title: cc_final_message will create /var/lib/cloud/instance as a directory if the symlink does not exist Status in cloud-init: New Bug description: cc_final_message calls util.write_file, which calls ensure_dir; if nothing has caused the symlink to be created, then this means that /var/lib/cloud/instance will be a directory, and future boots will fail because they fail to remove it (because it's a directory, so can't just be `rm`d.) (We're seeing this in bug 1883661; I don't think it's the root cause, hence this separate bug.) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1883903/+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 1124384] Re: Configuration reload clears event that others jobs may be waiting on
** No longer affects: cloud-init -- 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/1124384 Title: Configuration reload clears event that others jobs may be waiting on Status in cloud-init package in Ubuntu: Fix Released Status in upstart package in Ubuntu: Fix Released Status in cloud-init source package in Raring: Won't Fix Status in upstart source package in Raring: Won't Fix Status in cloud-init source package in Saucy: Fix Released Status in upstart source package in Saucy: Fix Released Bug description: [Impact] * The status of blocked events was not preserved, when upstart performed stateful re-execution or configuration reload. Thus jobs with complex start/stop conditions (one or more "and" clauses), with at least one event emitted before re-exec/reload, may not execute when remaining conditions are finally satisfied. * Above may prevent certain system to function correctly, and in the cases similar to cloud-init instances may even cause failure to boot. * The fix includes incriminating reference counts on blocked events, whilst job configuration is reloaded and fully serialising all upstart objects, including blocked events, during stateful re-execution. * Since previous versions of upstart, do not serialise blocked events the upgrade needs special casing. On upgrade upstart will perform stateful re-execution, unless runlevel 2 has been already reached. Instead upstart, will re-executed at system shutdown. This should allow upgrading upstart during early boot of cloud-init instances. But do note, that old instance of upstart will still be running as init and the running machine will still be affected by the bug described here. [Test Case] * Create a sample job /etc/init/foo.conf similar to this: start on (event1 and event2) task exec date * Test reload configuration works correctly: $ sudo status foo foo stop/waiting $ sudo initctl emit -n event1 $ sudo initctl reload-configuration $ sudo initctl emit -n event2 $ sudo tail /var/log/upstart/foo.log At the end one should see a timestamp appended in the foo.log. * Test stateful re-exec works correctly: $ sudo initctl emit -n event1 $ sudo telinit u $ sudo initctl emit -n event2 $ sudo tail /var/log/upstart/foo.log * Start an ubuntu-cloud image (in lxc or cloud) with apt-get update & upgrade enabled going from upstart version without this fix included to a one that does have it. Cloud-final should finish and boot- finished under /var/lib/cloud/instances/*/boot-finished. Please note this test should be performed in isolation from dbus security update that does partial stateful re-exec at the moment. [Regression Potential] * The bug fix introduced here is fairly large (approx 1.5k line diff) but comes with comprehensive set of test-suites to verify the two bug fixes as well as all possible combinations of stateful re-execution serialisation formats. Majority of code changes are for additional [de]serialisation, which follow existing well tested code pattern. And changes to reference counting have been carefully reviewed and tested by multiple developers. * While the bug report indicates a severe problem, it was not noticed until recently, as the system must be under heavy race conditions to become affected by this bug. Since systems reaching stable state, with little or no blocked events left, would not normally be affected. * Overall regression potential is deemed low. [Original Bug Report] Under bug 1080841 we made cloud-init invoke 'initctl reload- configuration' after it wrote a upstart job. This was necessary because inotify is not supported on all filesystems (overlayfs being the one of most current interst). This seems to be causing upstart some pain, and resulting in cloud- final (and 'rc') not being run. Easy user-data to reproduce the problem is: #cloud-config-archive - content: | #cloud-boothook #!/bin/sh touch /run/cloud-init-upstart-reload # hack, see trunk commit 783 - content: | #!/bin/sh echo " $(date -R): user-script run ===" | tee /run/user-script.log - content: | #upstart-job description "a test upstart job" start on stopped rc RUNLEVEL=[2345] console output task script echo " $(date -R): upstart job run ===" | tee /run/upstart-job.log end script You should (and do on quantal) end up with 2 files written to /run. I've verified that the same behavior is true on quantal. If you change cloud-init to notify upstart about a job immediately after it writes it, then quantal's upstart gets confused also. Related bugs: * bug 1080841: should reload configuration if an upstart job is
[Yahoo-eng-team] [Bug 1879103] Re: Unattended installation user data conflict
OK, it sounds like cloud-init is behaving as we expect it to, so I'm going to mark our task as Invalid. Do comment (and change status to New, if you can) if you think that's incorrect. ** Changed in: cloud-init Status: Confirmed => 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/1879103 Title: Unattended installation user data conflict Status in cloud-init: Invalid Status in subiquity: Fix Committed Bug description: When passing user-data to the 20.04 unattended installation through an iso described at https://wiki.ubuntu.com/FoundationsTeam/AutomatedServerInstalls/QuickStart, user creation doesn't happen. This is because /dev/sr1 takes priority over /var/lib/cloud/seed/nocloud-net/. The simple workaround for anyone experiencing this issue is to add the following to their user-data script: late-commands: - "eject /dev/sr1" I experienced this using Hyper-V. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1879103/+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 1883122] [NEW] `cloud-init status` should distinguish between "permanently disabled" and "disabled for this boot"
Public bug reported: Using ds-identify and a systemd generator, cloud-init can detect that it should disable itself for a particular boot when there is nothing for it to do. However, if on the next boot a datasource becomes applicable (e.g. a NoCloud/ConfigDrive device is presented to the system) then cloud-init will _not_ be disabled, because ds-identify will detect an applicable datasource. If users want a stronger guarantee that cloud-init will not run, then they can touch /etc/cloud/cloud-init.disabled, or add cloud- init=disabled to their grub configured kernel command line. When they do so, cloud-init will _never_ run, regardless of the applicability of datasources. In both of these cases, `cloud-init status` reports "disabled". This means that users who want to confirm that cloud-init will never run in the future given its current configuration have to check all the potential ways that cloud-init might be permanently disabled (/etc/..., kernel cmdline, maybe other options that I haven't documented here, maybe new options in the future) themselves. We should distinguish between these two modalities of "disabled" for users in our status output. ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1883122 Title: `cloud-init status` should distinguish between "permanently disabled" and "disabled for this boot" Status in cloud-init: New Bug description: Using ds-identify and a systemd generator, cloud-init can detect that it should disable itself for a particular boot when there is nothing for it to do. However, if on the next boot a datasource becomes applicable (e.g. a NoCloud/ConfigDrive device is presented to the system) then cloud-init will _not_ be disabled, because ds-identify will detect an applicable datasource. If users want a stronger guarantee that cloud-init will not run, then they can touch /etc/cloud/cloud-init.disabled, or add cloud- init=disabled to their grub configured kernel command line. When they do so, cloud-init will _never_ run, regardless of the applicability of datasources. In both of these cases, `cloud-init status` reports "disabled". This means that users who want to confirm that cloud-init will never run in the future given its current configuration have to check all the potential ways that cloud-init might be permanently disabled (/etc/..., kernel cmdline, maybe other options that I haven't documented here, maybe new options in the future) themselves. We should distinguish between these two modalities of "disabled" for users in our status output. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1883122/+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 1883124] [NEW] `cloud-init status` reports "disabled" for a boot when it did run
Public bug reported: Steps to reproduce, on a booted instance: $ cloud-init status done $ touch /etc/cloud/cloud-init.disabled $ cloud-init status disabled While this is accurate on one sense (cloud-init _is_ now disabled) it obscures the fact that cloud-init did run for this boot. It is both "done" _and_ "disabled". ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1883124 Title: `cloud-init status` reports "disabled" for a boot when it did run Status in cloud-init: New Bug description: Steps to reproduce, on a booted instance: $ cloud-init status done $ touch /etc/cloud/cloud-init.disabled $ cloud-init status disabled While this is accurate on one sense (cloud-init _is_ now disabled) it obscures the fact that cloud-init did run for this boot. It is both "done" _and_ "disabled". To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1883124/+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 1880701] [NEW] `cloud-init query` cannot be used to determine the current datasource
Public bug reported:
On a lxd container, which uses the NoCloud datasource[0], the only place
where "NoCloud" is queryable is in `datasource_list`:
# cloud-init query -a | grep -B1 -A2 NoCloud
"datasource_list": [
"NoCloud",
"None"
],
With ds-identify enabled, you probably _can_ take that first value as
the correct DS (because if that DS wasn't used then you probably don't
have access to the instance), but that won't generalise well. We should
provide the name of the datasource used in the queryable data somewhere.
[0] # cat /run/cloud-init/result.json
{
"v1": {
"datasource": "DataSourceNoCloud
[seed=/var/lib/cloud/seed/nocloud-net][dsmode=net]",
"errors": []
}
}
** Affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1880701
Title:
`cloud-init query` cannot be used to determine the current datasource
Status in cloud-init:
New
Bug description:
On a lxd container, which uses the NoCloud datasource[0], the only
place where "NoCloud" is queryable is in `datasource_list`:
# cloud-init query -a | grep -B1 -A2 NoCloud
"datasource_list": [
"NoCloud",
"None"
],
With ds-identify enabled, you probably _can_ take that first value as
the correct DS (because if that DS wasn't used then you probably don't
have access to the instance), but that won't generalise well. We
should provide the name of the datasource used in the queryable data
somewhere.
[0] # cat /run/cloud-init/result.json
{
"v1": {
"datasource": "DataSourceNoCloud
[seed=/var/lib/cloud/seed/nocloud-net][dsmode=net]",
"errors": []
}
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1880701/+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 1879356] [NEW] `cloud-init devel schema --annotate` fails for integer keys which do not roundtrip through string representation
Public bug reported:
When using the new snap.commands schema (introduced in
https://github.com/canonical/cloud-init/pull/364), it's possible to
trigger a bug in our assertion code. Specifically, this file will fail
validation (correctly, because `123` is an integer and not a string):
#cloud-config
snap:
commands:
01: ["foo", 123]
And then traceback during annotation:
$ cloud-init devel schema -c foo.yaml --annotate
Traceback (most recent call last):
File "/home/daniel/dev/cloud-init/cloudinit/config/schema.py", line 217, in
validate_cloudconfig_file
validate_cloudconfig_schema(
File "/home/daniel/dev/cloud-init/cloudinit/config/schema.py", line 121, in
validate_cloudconfig_schema
raise SchemaValidationError(errors)
cloudinit.config.schema.SchemaValidationError: Cloud config schema errors:
snap.commands.1: ['foo', 123] is not valid under any of the given schemas
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/daniel/.virtualenvs/cloud-init/bin/cloud-init", line 11, in
load_entry_point('cloud-init', 'console_scripts', 'cloud-init')()
File "/home/daniel/dev/cloud-init/cloudinit/cmd/main.py", line 891, in main
retval = util.log_time(
File "/home/daniel/dev/cloud-init/cloudinit/util.py", line 2618, in log_time
ret = func(*args, **kwargs)
File "/home/daniel/dev/cloud-init/cloudinit/config/schema.py", line 446, in
handle_schema_args
validate_cloudconfig_file(
File "/home/daniel/dev/cloud-init/cloudinit/config/schema.py", line 221, in
validate_cloudconfig_file
print(annotated_cloudconfig_file(
File "/home/daniel/dev/cloud-init/cloudinit/config/schema.py", line 153, in
annotated_cloudconfig_file
errors_by_line[schemapaths[path]].append(msg)
KeyError: 'snap.commands.1'
Note the `1` at the end of the key we're looking for (instead of 01).
If we modify the input file to drop the leading 0:
#cloud-config
snap:
commands:
1: ["foo", 123]
then we don't see a traceback:
$ cloud-init devel schema -c foo.yaml --annotate
#cloud-config
snap:
commands:
1: ["foo", 123] # E1
# Errors: -
# E1: ['foo', 123] is not valid under any of the given schemas
** Affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1879356
Title:
`cloud-init devel schema --annotate` fails for integer keys which do
not roundtrip through string representation
Status in cloud-init:
New
Bug description:
When using the new snap.commands schema (introduced in
https://github.com/canonical/cloud-init/pull/364), it's possible to
trigger a bug in our assertion code. Specifically, this file will
fail validation (correctly, because `123` is an integer and not a
string):
#cloud-config
snap:
commands:
01: ["foo", 123]
And then traceback during annotation:
$ cloud-init devel schema -c foo.yaml --annotate
Traceback (most recent call last):
File "/home/daniel/dev/cloud-init/cloudinit/config/schema.py", line 217,
in validate_cloudconfig_file
validate_cloudconfig_schema(
File "/home/daniel/dev/cloud-init/cloudinit/config/schema.py", line 121,
in validate_cloudconfig_schema
raise SchemaValidationError(errors)
cloudinit.config.schema.SchemaValidationError: Cloud config schema errors:
snap.commands.1: ['foo', 123] is not valid under any of the given schemas
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/daniel/.virtualenvs/cloud-init/bin/cloud-init", line 11, in
load_entry_point('cloud-init', 'console_scripts', 'cloud-init')()
File "/home/daniel/dev/cloud-init/cloudinit/cmd/main.py", line 891, in
main
retval = util.log_time(
File "/home/daniel/dev/cloud-init/cloudinit/util.py", line 2618, in
log_time
ret = func(*args, **kwargs)
File "/home/daniel/dev/cloud-init/cloudinit/config/schema.py", line 446,
in handle_schema_args
validate_cloudconfig_file(
File "/home/daniel/dev/cloud-init/cloudinit/config/schema.py", line 221,
in validate_cloudconfig_file
print(annotated_cloudconfig_file(
File "/home/daniel/dev/cloud-init/cloudinit/config/schema.py", line 153,
in annotated_cloudconfig_file
errors_by_line[schemapaths[path]].append(msg)
KeyError: 'snap.commands.1'
Note the `1` at the end of the key we're looking for (instead of 01).
If we modify the input file to drop the leading 0:
#cloud-config
snap:
commands:
1: ["foo", 123]
then we don't see a traceback:
$ cloud-init devel schema -c foo.yaml --annotate
#cloud-config
snap:
[Yahoo-eng-team] [Bug 1876941] [NEW] Document that network-config MAC addresses should be lower case
Public bug reported: Currently users may see failures if using upper-case MAC addresses in network configuration, because cloud-init does not appropriately normalise the case of MAC addresses in all situations. https://cloudinit.readthedocs.io/en/latest/topics/network-config- format-v2.html should be updated to (a) only use lower-case MAC addresses, and (b) indicate to users that this is an intentional choice that they need to follow. (https://bugs.launchpad.net/cloud-init/+bug/1876363 covers fixing the underlying issue, this is strictly about documenting the currently- required input.) ** Affects: cloud-init Importance: High Status: Triaged ** Tags: bitesize -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1876941 Title: Document that network-config MAC addresses should be lower case Status in cloud-init: Triaged Bug description: Currently users may see failures if using upper-case MAC addresses in network configuration, because cloud-init does not appropriately normalise the case of MAC addresses in all situations. https://cloudinit.readthedocs.io/en/latest/topics/network-config- format-v2.html should be updated to (a) only use lower-case MAC addresses, and (b) indicate to users that this is an intentional choice that they need to follow. (https://bugs.launchpad.net/cloud-init/+bug/1876363 covers fixing the underlying issue, this is strictly about documenting the currently- required input.) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1876941/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1876795] [NEW] `cloud-init analyze` should emit a useful error message if it finds no log lines to process
Public bug reported: When run on the log output from Amazon Linux 2 (see bug 1876323), `analyze` fails to find any log lines to process. Currently, it treats this as a normal situation and emits: $ cloud-init analyze show -i ~/Downloads/uhJNysgm.txt -- 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. Total Time: 0.0 seconds 1 boot records analyzed It would be better if it emitted a clear error message that it didn't find any log lines. ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1876795 Title: `cloud-init analyze` should emit a useful error message if it finds no log lines to process Status in cloud-init: New Bug description: When run on the log output from Amazon Linux 2 (see bug 1876323), `analyze` fails to find any log lines to process. Currently, it treats this as a normal situation and emits: $ cloud-init analyze show -i ~/Downloads/uhJNysgm.txt -- 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. Total Time: 0.0 seconds 1 boot records analyzed It would be better if it emitted a clear error message that it didn't find any log lines. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1876795/+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 1876794] [NEW] `cloud-init analyze` depends on the upstream-shipped log format to function
Public bug reported: This is a more general version of bug 1876323: `cloud-init analyze` relies on the log format that upstream ships in order to detect log lines. This means that if logging configuration by users or downstream packagers diverges (as is the case on Amazon Linux 2, for example), then the `analyze` commands will not produce any useful output (or a useful error message). (Ubuntu uses this log format, so this bug does not present on Ubuntu.) ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1876794 Title: `cloud-init analyze` depends on the upstream-shipped log format to function Status in cloud-init: New Bug description: This is a more general version of bug 1876323: `cloud-init analyze` relies on the log format that upstream ships in order to detect log lines. This means that if logging configuration by users or downstream packagers diverges (as is the case on Amazon Linux 2, for example), then the `analyze` commands will not produce any useful output (or a useful error message). (Ubuntu uses this log format, so this bug does not present on Ubuntu.) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1876794/+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 1876323] [NEW] `cloud-init analyze` fails to produce useful output on Amazon Linux 2 due to log format configuration
Public bug reported: When running `cloud-init analyze show` against a log file from an Amazon Linux 2 instance (e.g. https://pastebin.com/uhJNysgm), no useful output is produced: $ cloud-init analyze show -i ~/Downloads/uhJNysgm.txt -- 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. Total Time: 0.0 seconds 1 boot records analyzed This is because the log configuration on Amazon Linux 2 (https://pastebin.com/x6NZ4NFJ) configures this for arg0Formatter: format=%(asctime)s cloud-init[%(process)d]: %(filename)s[%(levelname)s]: %(message)s which differs from the upstream definition: format=%(asctime)s - %(filename)s[%(levelname)s]: %(message)s This is a problem, because the `cloud-init analyze` commands depend on the " - " part of the line's presence as a separator (see https://github.com/canonical/cloud- init/blob/master/cloudinit/analyze/dump.py#L78), so when we run analyze against an Amazon Linux 2 log file, we incorrectly fail to identify any of the lines in it as being cloud-init log lines. (As an aside, this is the only non-whitespace difference between the two configuration files.) ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1876323 Title: `cloud-init analyze` fails to produce useful output on Amazon Linux 2 due to log format configuration Status in cloud-init: New Bug description: When running `cloud-init analyze show` against a log file from an Amazon Linux 2 instance (e.g. https://pastebin.com/uhJNysgm), no useful output is produced: $ cloud-init analyze show -i ~/Downloads/uhJNysgm.txt -- 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. Total Time: 0.0 seconds 1 boot records analyzed This is because the log configuration on Amazon Linux 2 (https://pastebin.com/x6NZ4NFJ) configures this for arg0Formatter: format=%(asctime)s cloud-init[%(process)d]: %(filename)s[%(levelname)s]: %(message)s which differs from the upstream definition: format=%(asctime)s - %(filename)s[%(levelname)s]: %(message)s This is a problem, because the `cloud-init analyze` commands depend on the " - " part of the line's presence as a separator (see https://github.com/canonical/cloud- init/blob/master/cloudinit/analyze/dump.py#L78), so when we run analyze against an Amazon Linux 2 log file, we incorrectly fail to identify any of the lines in it as being cloud-init log lines. (As an aside, this is the only non-whitespace difference between the two configuration files.) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1876323/+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 1876139] Re: Groovy cloud-images failing during growpart
OK, a binary wasn't relocated, but the dependency from util-linux -> fdisk was dropped (in https://launchpad.net/ubuntu/+source/util- linux/2.34-0.1ubuntu3): util-linux (2.34-0.1ubuntu3) focal; urgency=medium * Drop dependency from util-linux to fdisk. The transition to split-out fdisk was done before 18.04 so the transitional dependency is no longer needed, and fdisk should not be pulled into the essential package set since it's not needed in container environments. For bootable systems which need fdisk, it will be pulled in directly. -- Steve Langasek Fri, 22 Nov 2019 13:40:12 -0800 ** Also affects: cloud-images Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1876139 Title: Groovy cloud-images failing during growpart Status in cloud-images: New Status in cloud-init: Incomplete Bug description: Was running on Azure, but I expect this happens on all cloud images. We did not see our disk grow as expected on first boot. Took a look at /var/log/cloud-init and saw the following: 2020-04-30 16:04:46,837 - util.py[WARNING]: Failed growpart --dry-run for (/dev/sda, 1) 2020-04-30 16:04:46,837 - util.py[DEBUG]: Failed growpart --dry-run for (/dev/sda, 1) Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 145, in resize util.subp(["growpart", '--dry-run', diskdev, partnum]) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2084, in subp raise ProcessExecutionError(stdout=out, stderr=err, cloudinit.util.ProcessExecutionError: Unexpected error while running command. Command: ['growpart', '--dry-run', '/dev/sda', '1'] Exit code: 2 Reason: - Stdout: FAILED: sfdisk not found To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1876139/+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 1874875] [NEW] cloudinit.sources.NetworkConfigSource can be refactored to an enum
Public bug reported: It is currently implemented as a namedtuple, because it was written when the codebase supported Python 2 (where using an enum would have introduced a new dependency). As enum is in the stdlib in all our supported Python releases, we can now use it without that constraint. ** Affects: cloud-init Importance: Wishlist Status: Triaged ** Tags: bitesize -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1874875 Title: cloudinit.sources.NetworkConfigSource can be refactored to an enum Status in cloud-init: Triaged Bug description: It is currently implemented as a namedtuple, because it was written when the codebase supported Python 2 (where using an enum would have introduced a new dependency). As enum is in the stdlib in all our supported Python releases, we can now use it without that constraint. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1874875/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1874866] [NEW] Add more Python versions to cloud-init's Travis CI
Public bug reported: Currently we run cloud-init's unit tests twice in Travis: * once on Python 3.6 with the latest versions of our dependencies from PyPI, and * once on Python 3.5 with the versions of our dependencies that are in xenial (but installed from PyPI, rather than apt) We currently know that cloud-init is run on 3.7 and 3.8, because eoan and focal use those versions respectively. We should expand our matrix of testing to cover all currently-supported Python versions, 3.4+. ** Affects: cloud-init Importance: Medium Status: Triaged ** Tags: bitesize -- 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/1874866 Title: Add more Python versions to cloud-init's Travis CI Status in cloud-init: Triaged Bug description: Currently we run cloud-init's unit tests twice in Travis: * once on Python 3.6 with the latest versions of our dependencies from PyPI, and * once on Python 3.5 with the versions of our dependencies that are in xenial (but installed from PyPI, rather than apt) We currently know that cloud-init is run on 3.7 and 3.8, because eoan and focal use those versions respectively. We should expand our matrix of testing to cover all currently- supported Python versions, 3.4+. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1874866/+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 1869306] Re: Users module errors for users of same SSH key type with existing user
Actually I think that may have been a red herring, I think "-
name:trent" was the actual problem: that's parsed as ["name:trent"], not
{"name": "trent"}. Which then means that the parser expects the
following line to be a list item, and it's a mapping item, hence the
blow up.
Regardless, glad you got this sorted!
** Changed in: cloud-init
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1869306
Title:
Users module errors for users of same SSH key type with existing user
Status in cloud-init:
Invalid
Bug description:
I'm starting an instance (tried both centos and ubuntu) in AWS with
user_data similar to the following:
users:
- name: bob
sudo: ALL=(ALL) NOPASSWD:ALL
groups: users
lock_passwd: true
ssh_authorized_keys:
- ssh-rsa some-ssh-pubkey-x
- name: alice
sudo: ALL=(ALL) NOPASSWD:ALL
groups: users
lock_passwd: true
ssh_authorized_keys:
- ssh-rsa some-ssh-pubkey-x
- name: mallory
sudo: ALL=(ALL) NOPASSWD:ALL
groups: users
lock_passwd: true
ssh_authorized_keys:
- ssh-rsa some-ssh-pubkey-x
- name: trent
sudo: ALL=(ALL) NOPASSWD:ALL
groups: users
lock_passwd: true
ssh_authorized_keys:
- ssh-ed25519 some-ssh-pubkey-x
Two things are special in this case. Mallory made herself a user
account on the box before baking the original image, and Trent has an
ECC key (the rest are using RSA).
Upon running this in AWS, only Trent gets created. The only
discernible error I have seen is:
File "/usr/lib/python2.7/site-packages/cloudinit/ssh_util.py", line 208, in
us
ers_ssh_info
pw_ent = pwd.getpwnam(username)
KeyError: 'getpwnam(): name not found: alice'
Trent can log in and see that his key has been created, but literally
every other user who is using an RSA SSH key hasn't had their user
created. Compounding it, Mallory doesn't have a login but still
retains her home directory.
The fix for this entails making a user "mallory2" and leaving mallory
alone. When this happens, all users get created (though mallory's
original account is missing other than /home). I've also tried making
a mallory user with a custom homedir of /home/mallorytoo, but the same
error happens.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1869306/+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 1873910] [NEW] Nightly CI builds are failing because due to missing get_interfaces_by_mac mocking
Public bug reported: get_interfaces_by_mac is currently errorring on the system that runs cloud-init's nightly CI. This indicates missing mocking in the following tests: FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_context_devname FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_emptycontext FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_nonecontext FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_withdefaultvalue FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_withdefaultvalue_emptycontext FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_gateway FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_gateway6 FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6 FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_dual FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_prefix FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_prefix_emptystring FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_ula FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip_emptystring FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_mask FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_mask_emptystring FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_mtu FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_nameservers FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_network FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_network_emptystring FAILED cloudinit/sources/tests/test_oracle.py::TestDataSourceOracle::test_network_cmdline FAILED cloudinit/sources/tests/test_oracle.py::TestDataSourceOracle::test_network_fallback (Sourced from https://jenkins.ubuntu.com/server/job/cloud-init-ci- nightly/712/.) ** Affects: cloud-init Importance: Undecided Assignee: Dan Watkins (daniel-thewatkins) Status: New ** Changed in: cloud-init Assignee: (unassigned) => Dan Watkins (daniel-thewatkins) -- 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/1873910 Title: Nightly CI builds are failing because due to missing get_interfaces_by_mac mocking Status in cloud-init: New Bug description: get_interfaces_by_mac is currently errorring on the system that runs cloud-init's nightly CI. This indicates missing mocking in the following tests: FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_context_devname FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_emptycontext FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_nonecontext FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_withdefaultvalue FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_field_withdefaultvalue_emptycontext FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_gateway FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_gateway6 FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6 FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_dual FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_prefix FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_prefix_emptystring FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip6_ula FAILED tests/unittests/test_datasource/test_opennebula.py::TestOpenNebulaNetwork::test_get_ip_emptystring FAILED tests/unittests/test_datasource/test_opennebula
[Yahoo-eng-team] [Bug 1872813] Re: cloud-init fails to detect iSCSI root on focal Oracle instances
** Also affects: open-iscsi (Ubuntu) Importance: Undecided Status: New ** Changed in: cloud-init Status: In Progress => 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/1872813 Title: cloud-init fails to detect iSCSI root on focal Oracle instances Status in cloud-init: Invalid Status in open-iscsi package in Ubuntu: New Bug description: Currently focal images on Oracle are failing to get data from the Oracle DS with this traceback: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 772, in find_source if s.update_metadata([EventType.BOOT_NEW_INSTANCE]): File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 661, in update_metadata result = self.get_data() File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 279, in get_data return_value = self._get_data() File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceOracle.py", line 195, in _get_data with dhcp.EphemeralDHCPv4(net.find_fallback_nic()): 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 109, in obtain_lease ephipv4.__enter__() File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 1019, in __enter__ self._bringup_static_routes() File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 1071, in _bringup_static_routes util.subp( File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2084, in subp raise ProcessExecutionError(stdout=out, stderr=err, 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 In https://github.com/canonical/cloud-init/blob/46cf23c28812d3e3ba0c570defd9a05628af5556/cloudinit/sources/DataSourceOracle.py#L194-L198, we can see that this path is only taken if _is_iscsi_root returns False. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1872813/+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 1872813] [NEW] cloud-init fails to detect iSCSI root on focal Oracle instances
Public bug reported:
Currently focal images on Oracle are failing to get data from the Oracle
DS with this traceback:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line
772, in find_source
if s.update_metadata([EventType.BOOT_NEW_INSTANCE]):
File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line
661, in update_metadata
result = self.get_data()
File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line
279, in get_data
return_value = self._get_data()
File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceOracle.py",
line 195, in _get_data
with dhcp.EphemeralDHCPv4(net.find_fallback_nic()):
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 109, in
obtain_lease
ephipv4.__enter__()
File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 1019,
in __enter__
self._bringup_static_routes()
File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 1071,
in _bringup_static_routes
util.subp(
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2084, in subp
raise ProcessExecutionError(stdout=out, stderr=err,
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
In
https://github.com/canonical/cloud-init/blob/46cf23c28812d3e3ba0c570defd9a05628af5556/cloudinit/sources/DataSourceOracle.py#L194-L198,
we can see that this path is only taken if _is_iscsi_root returns False.
** Affects: cloud-init
Importance: Undecided
Assignee: Dan Watkins (daniel-thewatkins)
Status: In Progress
** Changed in: cloud-init
Assignee: (unassigned) => Dan Watkins (daniel-thewatkins)
--
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/1872813
Title:
cloud-init fails to detect iSCSI root on focal Oracle instances
Status in cloud-init:
In Progress
Bug description:
Currently focal images on Oracle are failing to get data from the
Oracle DS with this traceback:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line
772, in find_source
if s.update_metadata([EventType.BOOT_NEW_INSTANCE]):
File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line
661, in update_metadata
result = self.get_data()
File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line
279, in get_data
return_value = self._get_data()
File
"/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceOracle.py", line
195, in _get_data
with dhcp.EphemeralDHCPv4(net.find_fallback_nic()):
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 109, in
obtain_lease
ephipv4.__enter__()
File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 1019,
in __enter__
self._bringup_static_routes()
File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 1071,
in _bringup_static_routes
util.subp(
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2084, in subp
raise ProcessExecutionError(stdout=out, stderr=err,
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
In
https://github.com/canonical/cloud-init/blob/46cf23c28812d3e3ba0c570defd9a05628af5556/cloudinit/sources/DataSourceOracle.py#L194-L198,
we can see that this path is only taken if _is_iscsi_root returns False.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1872813/+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] [NEW] cloud-init should support parsing ssh_config/sshd_config files with Include directives
Public bug reported: 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 ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1871858 Title: cloud-init should support parsing ssh_config/sshd_config files with Include directives Status in cloud-init: New 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 1871859] [NEW] cloud-init should write ssh_config.d/sshd_config.d snippets (when supported) instead of modifying config files
Public bug reported: 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 ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1871859 Title: cloud-init should write ssh_config.d/sshd_config.d snippets (when supported) instead of modifying config files Status in cloud-init: New 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 1861460] Re: cloud-init should parse initramfs rendered netplan if present
Ryan has started work on this, moving to In Progress. ** Changed in: cloud-init Status: Invalid => Triaged ** Changed in: cloud-init Status: Triaged => In Progress -- 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: In Progress 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 1869155] Re: Cloud-init uses macaddress keyword on s390x where MAC addresses are not necessarily stable/unique across reboots
cloud-init isn't the source of this configuration, so I'm marking our
task Incomplete and adding subiquity (which I believe generates this
config).
(Regardless, I've responded to a couple of things below for background.)
> I think with the right tooling (ip, ifconfig, ethtool or even the
network-manager UI) you can even change MAC addresses today on other
platforms.
There's a substantial difference between people being able to opt into
changing MACs and the platform not providing stable MACs. In the former
case, we can tell people to stop doing it, or tell them other manual
steps that they can perform when they are manually changing their MAC.
In the latter case, we don't have that option. ;)
> Nowadays interface names are based on their underlying physical
device/address (here in this case '600' or to be precise '0600' -
leading '0' are removed), which makes the interface and it's name
already quite unique - since it is not possible to have two devices (in
one system) with the exact same address.
This may be true for Z, but it isn't for cloud instances because the
"physical" device can move between PCI ports on reboot, for example, or
be named differently based on the order in which the kernel detects each
interface. In these cases, using the MAC address is a lot more reliable
than using the physical address.
** Changed in: cloud-init
Status: New => Incomplete
** Also affects: subiquity
Importance: Undecided
Status: New
** Summary changed:
- Cloud-init uses macaddress keyword on s390x where MAC addresses are not
necessarily stable/unique across reboots
+ When installing with subiquity, the generated network config uses the
macaddress keyword on s390x (where MAC addresses are not necessarily stable
across reboots)
--
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/1869155
Title:
When installing with subiquity, the generated network config uses the
macaddress keyword on s390x (where MAC addresses are not necessarily
stable across reboots)
Status in cloud-init:
Incomplete
Status in subiquity:
New
Status in Ubuntu on IBM z Systems:
New
Bug description:
While performing a subiquity focal installation on an s390x LPAR (where the
LPAR is connected to a VLAN trunk) I saw a section like this:
match:
macaddress: 02:28:0b:00:00:53
So the macaddress keyword is used, but on several s390x machine generation
MAC addresses are
not necessarily stable and uniquie across reboots.
(z14 GA2 and newer system have in between a modified firmware that ensures
that MAC addresses are stable and uniquire across reboots, but for z14 GA 1 and
older systems, incl. the z13 that I used this is not the case - and a backport
of the firmware modification is very unlikely)
The configuration that I found is this:
$ 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 reboot. 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:
ethernets:
enc600:
addresses:
- 10.245.236.26/24
gateway4: 10.245.236.1
match:
macaddress: 02:28:0b:00:00:53
nameservers:
addresses:
- 10.245.236.1
set-name: enc600
version: 2
(This is a spin-off of ticket LP 1868246.)
It's understood that the initial idea for the MAC addresses was to have a
unique identifier, but
I think with the right tooling (ip, ifconfig, ethtool or even the
network-manager UI) you can even change MAC addresses today on other platforms.
Nowadays interface names are based on their underlying physical
device/address (here in this case '600' or to be precise '0600' -
leading '0' are removed), which makes the interface and it's name
already quite unique - since it is not possible to have two devices
(in one system) with the exact same address.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1869155/+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 1867043] Re: Daily builds failing due to missing pytest
** Changed in: cloud-init Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1867043 Title: Daily builds failing due to missing pytest Status in cloud-init: Fix Released Bug description: e.g. https://launchpadlibrarian.net/468666983/buildlog_ubuntu-xenial- amd64.cloud- init_20.1-2345-gd5dbbd1-0ubuntu1+1465~trunk~ubuntu16.04.1_BUILDING.txt.gz http_proxy= make PYVER=python3 check make[2]: Entering directory '/<>' python3 -m pytest -v tests/unittests cloudinit /usr/bin/python3: No module named pytest Makefile:52: recipe for target 'unittest3' failed make[2]: *** [unittest3] Error 1 make[2]: Leaving directory '/<>' debian/rules:11: recipe for target 'override_dh_auto_test' failed make[1]: *** [override_dh_auto_test] Error 2 make[1]: Leaving directory '/<>' debian/rules:7: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1867043/+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 1867043] [NEW] Daily builds failing due to missing pytest
Public bug reported: e.g. https://launchpadlibrarian.net/468666983/buildlog_ubuntu-xenial- amd64.cloud- init_20.1-2345-gd5dbbd1-0ubuntu1+1465~trunk~ubuntu16.04.1_BUILDING.txt.gz http_proxy= make PYVER=python3 check make[2]: Entering directory '/<>' python3 -m pytest -v tests/unittests cloudinit /usr/bin/python3: No module named pytest Makefile:52: recipe for target 'unittest3' failed make[2]: *** [unittest3] Error 1 make[2]: Leaving directory '/<>' debian/rules:11: recipe for target 'override_dh_auto_test' failed make[1]: *** [override_dh_auto_test] Error 2 make[1]: Leaving directory '/<>' debian/rules:7: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1867043 Title: Daily builds failing due to missing pytest Status in cloud-init: New Bug description: e.g. https://launchpadlibrarian.net/468666983/buildlog_ubuntu-xenial- amd64.cloud- init_20.1-2345-gd5dbbd1-0ubuntu1+1465~trunk~ubuntu16.04.1_BUILDING.txt.gz http_proxy= make PYVER=python3 check make[2]: Entering directory '/<>' python3 -m pytest -v tests/unittests cloudinit /usr/bin/python3: No module named pytest Makefile:52: recipe for target 'unittest3' failed make[2]: *** [unittest3] Error 1 make[2]: Leaving directory '/<>' debian/rules:11: recipe for target 'override_dh_auto_test' failed make[1]: *** [override_dh_auto_test] Error 2 make[1]: Leaving directory '/<>' debian/rules:7: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1867043/+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 1860789] Re: ssh_authkey_fingerprints must use sha256 not md5
This bug is believed to be fixed in cloud-init in version 20.1. If this is still a problem for you, please make a comment and set the state back to New Thank you. ** Also affects: cloud-init Importance: Undecided Status: New ** Changed in: cloud-init Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1860789 Title: ssh_authkey_fingerprints must use sha256 not md5 Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: ssh_authkey_fingerprints must use sha256sum not md5 on focal and up. or maybe you should show both, becuase old ssh clients might only show md5 checksums, and like ssh clients on Windows, etc. If you switch to show both, it then can be backported to all stable releases, as md5 is no longer secure for this purpose. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1860789/+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 1860795] Re: cc_set_passwords is too short for RANDOM
This bug is believed to be fixed in cloud-init in version 20.1. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Also affects: cloud-init
Importance: Undecided
Status: New
** Changed in: cloud-init
Status: New => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1860795
Title:
cc_set_passwords is too short for RANDOM
Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Bug description:
PW_SET = (''.join([x for x in ascii_letters + digits
if x not in 'loLOI01']))
def rand_user_password(pwlen=9):
return util.rand_str(pwlen, select_from=PW_SET)
len(PW_SET) is 55
log_2(55^20) is 115 bits, which is above 112, which matches the default
OpenSSL SECLEVEL=2 setting in focal fossa.
Please bump PW_SET to 20, as 9 is crackable (provides 52 bits of
security which is less than SECLEVEL 0).
As I'm about to use this on a mainframe, which by definition can crack
that.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1860795/+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 1861412] Re: cloud-init crashes with static network configuration
This bug is believed to be fixed in cloud-init in version 20.1. If this is still a problem for you, please make a comment and set the state back to New Thank you. ** Also affects: cloud-init Importance: Undecided Status: New ** Changed in: cloud-init Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1861412 Title: cloud-init crashes with static network configuration Status in cloud-init: Fix Released Status in Ubuntu on IBM z Systems: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: I am booting an s390x VM with vlan & static ip= configuration on the kernel command line. It appears that cloudinit is trying to parse the ipconfig results, and is failing. Attaching: cmdline - /proc/cmdline net-encc000.2653.conf - the /run/net-encc000.2653.conf klibc ipconfig state file encc000.2653.yaml - /run/netplan/encc000.2653.yaml which initramfs-tools generates, but cloud-init is not using cloud-init-output.log & cloud-init.log - showing a crash traceback To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1861412/+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 1863943] Re: do not log imdsv2 token headers
This bug is believed to be fixed in cloud-init in version 20.1. If this is still a problem for you, please make a comment and set the state back to New Thank you. ** Changed in: cloud-init Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1863943 Title: do not log imdsv2 token headers Status in cloud-init: Fix Released Bug description: Cloud-init currently logs all headers when processing URLs. On Ec2, this includes the IMDSv2 token negotiation and all IMDS interactions. The value of seeing the headers in the log is quite useful, especially for confirming whether cloud-init is using IMDSv2 or not; however the actual value of the token does not aide in this effort. Reported by: https://github.com/ishug86 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1863943/+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 1863954] Re: Release 20.1
This bug is believed to be fixed in cloud-init in version 20.1. If this is still a problem for you, please make a comment and set the state back to New Thank you. ** Changed in: cloud-init Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1863954 Title: Release 20.1 Status in cloud-init: Fix Released Bug description: == Release Notes == Cloud-init release 20.1 is now available The 20.1 release: * spanned about 9 weeks * had 19 contributors from 19 domains * fixed 13 Launchpad issues Highlights: - Python 2 support has been dropped - A number of FreeBSD improvements landed - Two (low priority) CVEs were addressed: - utils: use SystemRandom when generating random password (CVE-2020-8631) - cc_set_password: increase random pwlength from 9 to 20 (CVE-2020-8632) == Changelog == - ec2: Do not log IMDSv2 token values, instead use REDACTED (#219) (LP: #1863943) - utils: use SystemRandom when generating random password. (#204) [Dimitri John Ledkov] - docs: mount_default_files is a list of 6 items, not 7 (#212) - azurecloud: fix issues with instances not starting (#205) (LP: #1861921) - unittest: fix stderr leak in cc_set_password random unittest output. (#208) - cc_disk_setup: add swap filesystem force flag (#207) - import sysvinit patches from freebsd-ports tree (#161) [Igor Galić] - docs: fix typo (#195) [Edwin Kofler] - sysconfig: distro-specific config rendering for BOOTPROTO option (#162) [Robert Schweikert] (LP: #1800854) - cloudinit: replace "from six import X" imports (except in util.py) (#183) - run-container: use 'test -n' instead of 'test ! -z' (#202) [Paride Legovini] - net/cmdline: correctly handle static ip= config (#201) [Dimitri John Ledkov] (LP: #1861412) - Replace mock library with unittest.mock (#186) - HACKING.rst: update CLA link (#199) - Scaleway: Fix DatasourceScaleway to avoid backtrace (#128) [Louis Bouchard] - cloudinit/cmd/devel/net_convert.py: add missing space (#191) - tools/run-container: drop support for python2 (#192) [Paride Legovini] - Print ssh key fingerprints using sha256 hash (#188) (LP: #1860789) - Make the RPM build use Python 3 (#190) [Paride Legovini] - cc_set_password: increase random pwlength from 9 to 20 (#189) (LP: #1860795) - .travis.yml: use correct Python version for xenial tests (#185) - cloudinit: remove ImportError handling for mock imports (#182) - Do not use fallocate in swap file creation on xfs. (#70) [Eduardo Otubo] (LP: #1781781) - .readthedocs.yaml: install cloud-init when building docs (#181) (LP: #1860450) - Introduce an RTD config file, and pin the Sphinx version to the RTD default (#180) - Drop most of the remaining use of six (#179) - Start removing dependency on six (#178) - Add Rootbox & HyperOne to list of cloud in README (#176) [Adam Dobrawy] - docs: add proposed SRU testing procedure (#167) - util: rename get_architecture to get_dpkg_architecture (#173) - Ensure util.get_architecture() runs only once (#172) - Only use gpart if it is the BSD gpart (#131) [Conrad Hoffmann] - freebsd: remove superflu exception mapping (#166) [Gonéri Le Bouder] - ssh_auth_key_fingerprints_disable test: fix capitalization (#165) [Paride Legovini] - util: move uptime's else branch into its own boottime function (#53) [Igor Galić] (LP: #1853160) - workflows: add contributor license agreement checker (#155) - net: fix rendering of 'static6' in network config (#77) (LP: #1850988) - Make tests work with Python 3.8 (#139) [Conrad Hoffmann] - fixed minor bug with mkswap in cc_disk_setup.py (#143) [andreaf74] - freebsd: fix create_group() cmd (#146) [Gonéri Le Bouder] - doc: make apt_update example consistent (#154) - doc: add modules page toc with links (#153) (LP: #1852456) - Add support for the amazon variant in cloud.cfg.tmpl (#119) [Frederick Lefebvre] - ci: remove Python 2.7 from CI runs (#137) - modules: drop cc_snap_config config module (#134) - migrate-lp-user-to-github: ensure Launchpad repo exists (#136) - docs: add initial troubleshooting to FAQ (#104) [Joshua Powers] - doc: update cc_set_hostname frequency and descrip (#109) [Joshua Powers] (LP: #1827021) - freebsd: introduce the freebsd renderer (#61) [Gonéri Le Bouder] - cc_snappy: remove deprecated module (#127) - HACKING.rst: clarify that everyone needs to do the LP->GH dance (#130) - freebsd: cloudinit service requires devd (#132) [Gonéri Le Bouder] - cloud-init: fix capitalisation of SSH (#126) - doc: update cc_ssh clarify host and auth keys [Joshua Powers] (LP: #1827021) - ci: emit names of tests run in Travis (#120) To manage notifications about this bug go to:
[Yahoo-eng-team] [Bug 1861921] Re: cloud tests ssh time out
This bug is believed to be fixed in cloud-init in version 20.1. If this is still a problem for you, please make a comment and set the state back to New Thank you. ** Changed in: cloud-init Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1861921 Title: cloud tests ssh time out Status in cloud-init: Fix Released Bug description: The function platforms/instance._wait_for_system causes ssh timeout on Azure cloud tests in the instance.start after initializing VM. Here is the tracebacks before and after removing it. Before FULL: https://paste.ubuntu.com/p/zJ3DNKxRTx/ https://paste.ubuntu.com/p/QyBnfrhVSs/ After removing FULL: https://paste.ubuntu.com/p/JfksGJyRYc/ https://paste.ubuntu.com/p/gxKZffv2zd/ Something in platforms/instance._wait_for_system is causing this, don't want to mess with it because it's also used in ec2 and other cloud tests. I found the easiest way to reproduce this is by going idle. -- Added verbose logging to investigate Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1861921/+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 1781781] Re: /swap.img w/fallocate has holes
This bug is believed to be fixed in cloud-init in version 20.1. If this is still a problem for you, please make a comment and set the state back to New Thank you. ** Changed in: cloud-init Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1781781 Title: /swap.img w/fallocate has holes Status in cloud-init: Fix Released Status in curtin: Confirmed Bug description: The /swap.img file on an XFS root filesystem is not being used. The dmesg says it "has holes". From the swapon manpage; The swap file implementation in the kernel expects to be able to write to the file directly, without the assistance of the filesystem. This is a problem on preallocated files (e.g. fallocate(1)) on filesystems like XFS or ext4, and on copy-on-write filesystems like btrfs. It is recommended to use dd(1) and /dev/zero to avoid holes on XFS and ext4. I've tracked down this commit which seems to be a step in the right direction; https://github.com/CanonicalLtd/curtin/commit/a909966f9c235282267024e86adf404dab83ccfe To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1781781/+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
