[Yahoo-eng-team] [Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute
** Also affects: linux-azure (Ubuntu) Importance: Undecided Status: New ** Changed in: linux-azure (Ubuntu) Milestone: None => ubuntu-21.04 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1919177 Title: Azure: issues with accelerated networking on Hirsute Status in cloud-init: Incomplete Status in cloud-init package in Ubuntu: New Status in linux-azure package in Ubuntu: New Bug description: [General] On Azure, when provisioning a Hirsute VM with Accelerated Networking enabled, sometimes the SSH key is not setup properly and the user cannot log into the VM. [how to reproduce] Start a VM with AN enabled: ``` az vm create --name "$VM_NAME --resource-group "$GROUP" --location "UK South" --image 'Canonical:0001-com-ubuntu-server-hirsute-daily:21_04-daily-gen2:latest' --size Standard_F8s_v2 --admin-username ubuntu --ssh-key-value "$SSH_KEY" --accelerated-networking ``` After a moment, try to SSH: if you succeed, delete and recreate a new VM. [troubleshooting] To be able to connect into the VM to debug, run: ``` az vm run-command invoke -g "$GROUP" -n "$VM_NAME" --command-id RunShellScript --scripts "sudo -u ubuntu ssh-import-id $LP_USERNAME" ``` In "/run/cloud-init/instance-data.json", I can see: ``` "publicKeys": [ { "keyData": "", "path": "/home/ubuntu/.ssh/authorized_keys" } ], ``` as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1919177/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1905447] [NEW] ds-identify OpenStack is odd
Public bug reported: ds-identify OpenStack is odd # LP: #1715241 : arch other than intel are not identified properly. case "$DI_UNAME_MACHINE" in i?86|x86_64) :;; *) return ${DS_MAYBE};; esac It has that, which is not nice. Also i think above is no longer true, i think that arm64 ppc64le s390x do have better openstack identification these days. Also returning DS_MAYBE is a bit harmful on arches that are known not to have openstack yet - i.e. riscv64. ** 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/1905447 Title: ds-identify OpenStack is odd Status in cloud-init: New Bug description: ds-identify OpenStack is odd # LP: #1715241 : arch other than intel are not identified properly. case "$DI_UNAME_MACHINE" in i?86|x86_64) :;; *) return ${DS_MAYBE};; esac It has that, which is not nice. Also i think above is no longer true, i think that arm64 ppc64le s390x do have better openstack identification these days. Also returning DS_MAYBE is a bit harmful on arches that are known not to have openstack yet - i.e. riscv64. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1905447/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1892851] Re: Staged boot, to fix integration of systemd generators
I think it's best to keep cloud-init task as Invalid for now. ** Also affects: netplan.io (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/1892851 Title: Staged boot, to fix integration of systemd generators Status in cloud-init: Invalid Status in netplan: Fix Committed Status in netplan.io package in Ubuntu: New Bug description: [Intro] Cloud-init makes use of the "netplan" systemd generator, but calls "netplan generate" manually at runtime, while currently executing the initial systemd boot transaction, instead of running it as intended via "systemctl daemon-reload" at systemd generator stage, due to restrictions it has regarding fetching of its data source (e.g. netplan YAML config). [Problem] This leads to problems at first boot, as the systemd unit dependencies are calculated after the generator stage, but ahead of the boot transaction (e.g. via systemctl daemon-reload), therefore the new service units and its dependencies, which are generated by manually calling systemd generators are ignored during the first-boot transaction. In subsequent boots (where the cloud-init data source, netplan YAML config and unit files are already in place), everything works as expected. It is a tricky situation, as cloud-init 1/ does not have the full config to run the systemd generators (e.g. netplan YAML) yet before the systemd boot transaction. It first needs to fetch it via a DataSource, possibly via a network connection. 2/ cannot execute the generators manually (e.g. "netplan generate") during the systemd boot transaction, because this way the newly generated service units and corresponding dependencies will be ignored. 3/ cannot re-execute the systemd generators after the initial boot transaction, as it is already too late at this point and applications expect to have a readily configured network setup after cloud-final.target has been reached. [References] Such problems have been reported and discussed for WiFi on RaspberryPi (LP: #1870346) or Open vSwitch setups in MAAS (https://github.com/CanonicalLtd/netplan/pull/157), where some of the generated service units/dependencies (netplan-ovs-*.service or netplan-wpa-*.service, possibly SR-IOV units as well...) are not properly executed on first boot. [Suggestion] A possible solution I discussed with @xnox would be to re-engineer how cloud-init targets work a bit, by splitting up the cloud-init boot sequence into multiple stages, e.g.: * Start "Stage 0" systemd transaction: systemctl isolate cloud-stage0.target - execute the init local modules - setup basic networking (DHCP on eth0/ens3) - fetch data source & place netplan YAML in /etc/netplan/ * Finish "Stage 0" transaction * Call systemctl daemon-reload - This will trigger all systemd generators (incl. netplan generate) and re-calculate all dependencies * Start "Stage 1" systemd transaction: systemctl isolate default.target - execute all the normal cloud-init modules and start all the normal services, e.g. via cloud-final.target * Finish "Stage 1" transaction * System is now fully booted The idea here is to split up the boot sequence into two (or more?) systemd transactions, so we can call "systemctl daemon-reload" in between (but not within a running systemd transaction) to re-run all the generators and re-calculate all the dependencies. This way all generators would be used in their intended way and should work as expected, even on first boot. Doing that would also allow users to do interesting things with systemd via cloud-config. Like changing the default.target from multiuser.target to emergency.target, adding / masking / removing units used in early boot, and "just write fstab" and allow systemd- fstab-generator to process it, and mount things, etc... ### Config used to reproduce the problem in a LXD container: "systemctl status netplan-ovs-ovs0.service" will show that this unit has not be executed on first boot. config: user.network-config: | # cloud-config version: 2 bridges: ovs0: addresses: [10.10.10.20/24] interfaces: [eth0.21] parameters: stp: false openvswitch: {} ethernets: eth0: addresses: [10.10.10.30/24] vlans: eth0.21: id: 21 link: eth0 description: My OVS debugging profile devices: eth0: name: eth0 network: lxdbr0 type: nic root: path: / pool: default type: disk name: myovs To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1892851/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://lau
[Yahoo-eng-team] [Bug 1892851] Re: Staged boot, to fix integration of systemd generators
@slyon I have disscussed multi-transaction boot with systemd upstream; and cloud-init developers. Overall, it's an expensive operation, that may cause the boot slower, and may have unintended consequences which will be harder to debug. If more needs to add units during boot arise, imho we should do similar to what was done in netplan to simply start/add units to the current transaction whenever possible. As that is quick. ** Changed in: cloud-init Status: Confirmed => Invalid ** Changed in: netplan Status: New => Fix Committed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1892851 Title: Staged boot, to fix integration of systemd generators Status in cloud-init: Invalid Status in netplan: Fix Committed Status in netplan.io package in Ubuntu: New Bug description: [Intro] Cloud-init makes use of the "netplan" systemd generator, but calls "netplan generate" manually at runtime, while currently executing the initial systemd boot transaction, instead of running it as intended via "systemctl daemon-reload" at systemd generator stage, due to restrictions it has regarding fetching of its data source (e.g. netplan YAML config). [Problem] This leads to problems at first boot, as the systemd unit dependencies are calculated after the generator stage, but ahead of the boot transaction (e.g. via systemctl daemon-reload), therefore the new service units and its dependencies, which are generated by manually calling systemd generators are ignored during the first-boot transaction. In subsequent boots (where the cloud-init data source, netplan YAML config and unit files are already in place), everything works as expected. It is a tricky situation, as cloud-init 1/ does not have the full config to run the systemd generators (e.g. netplan YAML) yet before the systemd boot transaction. It first needs to fetch it via a DataSource, possibly via a network connection. 2/ cannot execute the generators manually (e.g. "netplan generate") during the systemd boot transaction, because this way the newly generated service units and corresponding dependencies will be ignored. 3/ cannot re-execute the systemd generators after the initial boot transaction, as it is already too late at this point and applications expect to have a readily configured network setup after cloud-final.target has been reached. [References] Such problems have been reported and discussed for WiFi on RaspberryPi (LP: #1870346) or Open vSwitch setups in MAAS (https://github.com/CanonicalLtd/netplan/pull/157), where some of the generated service units/dependencies (netplan-ovs-*.service or netplan-wpa-*.service, possibly SR-IOV units as well...) are not properly executed on first boot. [Suggestion] A possible solution I discussed with @xnox would be to re-engineer how cloud-init targets work a bit, by splitting up the cloud-init boot sequence into multiple stages, e.g.: * Start "Stage 0" systemd transaction: systemctl isolate cloud-stage0.target - execute the init local modules - setup basic networking (DHCP on eth0/ens3) - fetch data source & place netplan YAML in /etc/netplan/ * Finish "Stage 0" transaction * Call systemctl daemon-reload - This will trigger all systemd generators (incl. netplan generate) and re-calculate all dependencies * Start "Stage 1" systemd transaction: systemctl isolate default.target - execute all the normal cloud-init modules and start all the normal services, e.g. via cloud-final.target * Finish "Stage 1" transaction * System is now fully booted The idea here is to split up the boot sequence into two (or more?) systemd transactions, so we can call "systemctl daemon-reload" in between (but not within a running systemd transaction) to re-run all the generators and re-calculate all the dependencies. This way all generators would be used in their intended way and should work as expected, even on first boot. Doing that would also allow users to do interesting things with systemd via cloud-config. Like changing the default.target from multiuser.target to emergency.target, adding / masking / removing units used in early boot, and "just write fstab" and allow systemd- fstab-generator to process it, and mount things, etc... ### Config used to reproduce the problem in a LXD container: "systemctl status netplan-ovs-ovs0.service" will show that this unit has not be executed on first boot. config: user.network-config: | # cloud-config version: 2 bridges: ovs0: addresses: [10.10.10.20/24] interfaces: [eth0.21] parameters: stp: false openvswitch: {} ethernets: eth0: addresses: [10.10.10.30/24] vlans: eth0.21: id: 21 link: eth0 description: My OVS debug
[Yahoo-eng-team] [Bug 1880734] [NEW] ordering cycle upon booting groovy
Public bug reported: May 26 15:27:19 ubuntu-server systemd[1]: multi-user.target: Found ordering cycle on getty.target/start May 26 15:27:19 ubuntu-server systemd[1]: multi-user.target: Found dependency on serial-getty@sclp_line0.service/start May 26 15:27:19 ubuntu-server systemd[1]: multi-user.target: Found dependency on cloud-final.service/start May 26 15:27:19 ubuntu-server systemd[1]: multi-user.target: Found dependency on multi-user.target/start May 26 15:27:19 ubuntu-server systemd[1]: multi-user.target: Job getty.target/start deleted to break ordering cycle starting with multi-user.target/start We shall not have dependency cycles. Looks like we ordered getty.target to be both before and after multi- user.target via cloud-final & serial-getty service (getty.target) ** Affects: cloud-init Importance: Undecided Status: New ** Affects: subiquity Importance: Undecided Status: New ** Also 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/1880734 Title: ordering cycle upon booting groovy Status in cloud-init: New Status in subiquity: New Bug description: May 26 15:27:19 ubuntu-server systemd[1]: multi-user.target: Found ordering cycle on getty.target/start May 26 15:27:19 ubuntu-server systemd[1]: multi-user.target: Found dependency on serial-getty@sclp_line0.service/start May 26 15:27:19 ubuntu-server systemd[1]: multi-user.target: Found dependency on cloud-final.service/start May 26 15:27:19 ubuntu-server systemd[1]: multi-user.target: Found dependency on multi-user.target/start May 26 15:27:19 ubuntu-server systemd[1]: multi-user.target: Job getty.target/start deleted to break ordering cycle starting with multi-user.target/start We shall not have dependency cycles. Looks like we ordered getty.target to be both before and after multi- user.target via cloud-final & serial-getty service (getty.target) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1880734/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1872124] Re: ubuntu-drivers-common integration
I don't think that implementing just subiquity is enough. Ubiquity was the last piece of ubuntu-drivers integration on the Desktop, as update- manager continiously was already checking for any new drivers that are available for the systems' hardware, and continiously providing notifications to install / switch between new alternatives / dismiss installing drivers, on continuous basis post-install / post-upgrade. Doing this during install, simply moved that step from post-install to pre-install. Ubuntu Server currently does not have ubuntu-drivers integration with motd, unattanded upgrades, and apt output to notify users of the newly available driver implementations, and how to opt into them. Command line tooling exists, but currently only used non-interactively by cloud-init on some compatible public clouds. ** Also affects: ubuntu-meta (Ubuntu) Importance: Undecided Status: New ** Also affects: ubuntu-drivers-common (Ubuntu) Importance: Undecided Status: New ** Also affects: maas Importance: Undecided Status: New ** Summary changed: - ubuntu-drivers-common integration + Please integrate ubuntu-drivers --gpgpu into Ubuntu Server ** Also 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/1872124 Title: Please integrate ubuntu-drivers --gpgpu into Ubuntu Server Status in cloud-init: New Status in MAAS: New Status in subiquity: Triaged Status in ubuntu-drivers-common package in Ubuntu: New Status in ubuntu-meta package in Ubuntu: New Bug description: Could subiquity provide an option in the UI to install and execute ubuntu-drivers-common on the target? The use case I'm interested in is an "on-rails" installation of Nvidia drivers for servers being installed for deep learning workloads. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1872124/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1868246] Re: No network after subiquity LPAR installation on s390x with VLAN
and one more typo ** Also affects: initramfs-tools (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/1868246 Title: No network after subiquity LPAR installation on s390x with VLAN Status in cloud-init: Invalid Status in subiquity: Fix Released Status in Ubuntu on IBM z Systems: Fix Released Status in initramfs-tools package in Ubuntu: New Bug description: I tried today an subiquity LPAR installation using the latest ISO (March 19) that includes the latest 20.03 subiquity. The installation itself completed fine, but after the post-install reboot the system didn't had a network active - please note that the LPAR is connected to a VLAN. $ ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group defaul t qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: encc000: mtu 1500 qdisc noop state DOWN group default q len 1000 link/ether a2:8d:91:85:12:e3 brd ff:ff:ff:ff:ff:ff 3: enP1p0s0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 82:0c:2d:0c:b8:70 brd ff:ff:ff:ff:ff:ff 4: enP1p0s0d1: mtu 1500 qdisc noop state DOWN group defaul t qlen 1000 link/ether 82:0c:2d:0c:b8:71 brd ff:ff:ff:ff:ff:ff 5: enP2p0s0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 82:0c:2d:0c:b7:00 brd ff:ff:ff:ff:ff:ff 6: enP2p0s0d1: mtu 1500 qdisc noop state DOWN group defaul t qlen 1000 link/ether 82:0c:2d:0c:b7:01 brd ff:ff:ff:ff:ff:ff Wanting to have a look at the netplan config it turned out that there is no yaml file: $ ls -l /etc/netplan/ total 0 Adding one manually and applying it worked fine. So looks like the installer does not properly generate or copy a 01-netcfg.yaml to /etc/netplan. Please see below the entire steps as well as a compressed file with the entire content of /var/log To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1868246/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : 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
casper has been changed to generate cloud.cfg instead of netplan, thus no further work in cloud-init is required for focal. Closing this issue as fix released in casper & z project. It would be nice for cloud-init to do what was originally asked, but that is a feature request of a lower priority now, that needs further spec / implementation as discussed on github PR. ** Changed in: cloud-init Status: In Progress => Invalid ** Changed in: ubuntu-z-systems Status: In Progress => Fix Released ** Changed in: casper (Ubuntu) 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/1861460 Title: cloud-init should parse initramfs rendered netplan if present Status in cloud-init: Invalid 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 1868246] Re: No network after subiquity LPAR installation on s390x with VLAN
When using today's ISO, with only a single disk drive attached, and snap refreshed from edge channel, one should be able to complete the install with networking not getting interrupted, and correctly have networking in the target too. ** Changed in: ubuntu-z-systems Status: New => Fix Released ** Changed in: subiquity 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/1868246 Title: No network after subiquity LPAR installation on s390x with VLAN Status in cloud-init: Invalid Status in subiquity: Fix Released Status in Ubuntu on IBM z Systems: Fix Released Bug description: I tried today an subiquity LPAR installation using the latest ISO (March 19) that includes the latest 20.03 subiquity. The installation itself completed fine, but after the post-install reboot the system didn't had a network active - please note that the LPAR is connected to a VLAN. $ ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group defaul t qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: encc000: mtu 1500 qdisc noop state DOWN group default q len 1000 link/ether a2:8d:91:85:12:e3 brd ff:ff:ff:ff:ff:ff 3: enP1p0s0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 82:0c:2d:0c:b8:70 brd ff:ff:ff:ff:ff:ff 4: enP1p0s0d1: mtu 1500 qdisc noop state DOWN group defaul t qlen 1000 link/ether 82:0c:2d:0c:b8:71 brd ff:ff:ff:ff:ff:ff 5: enP2p0s0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 82:0c:2d:0c:b7:00 brd ff:ff:ff:ff:ff:ff 6: enP2p0s0d1: mtu 1500 qdisc noop state DOWN group defaul t qlen 1000 link/ether 82:0c:2d:0c:b7:01 brd ff:ff:ff:ff:ff:ff Wanting to have a look at the netplan config it turned out that there is no yaml file: $ ls -l /etc/netplan/ total 0 Adding one manually and applying it worked fine. So looks like the installer does not properly generate or copy a 01-netcfg.yaml to /etc/netplan. Please see below the entire steps as well as a compressed file with the entire content of /var/log To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1868246/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1870225] [NEW] ssh-key or random password
Public bug reported: ssh-key or random password I'd like to setup my user with an ssh key, if there is one in metadata and no password auth / locked account (cannot ssh with passord, cannot login on tty with password). If no ssh key available, I want user with random password, and tty login available, and password based ssh available. ** 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/1870225 Title: ssh-key or random password Status in cloud-init: New Bug description: ssh-key or random password I'd like to setup my user with an ssh key, if there is one in metadata and no password auth / locked account (cannot ssh with passord, cannot login on tty with password). If no ssh key available, I want user with random password, and tty login available, and password based ssh available. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1870225/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1861460] Re: cloud-init should parse initramfs rendered netplan if present
maybe casper can hack this ** Also affects: casper (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/1861460 Title: cloud-init should parse initramfs rendered netplan if present Status in cloud-init: In Progress Status in Ubuntu on IBM z Systems: In Progress Status in casper package in Ubuntu: New 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 1868246] Re: No network after subiquity LPAR installation on s390x with VLAN
1) cloud-init should be fixed for /run/netplan/* which is another bug 2) this bug is about subiquity not deleting/tearing down critical connections ** This bug is no longer a duplicate of bug 1861460 cloud-init should parse initramfs rendered netplan if present ** 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/1868246 Title: No network after subiquity LPAR installation on s390x with VLAN Status in cloud-init: Invalid Status in subiquity: New Status in Ubuntu on IBM z Systems: New Bug description: I tried today an subiquity LPAR installation using the latest ISO (March 19) that includes the latest 20.03 subiquity. The installation itself completed fine, but after the post-install reboot the system didn't had a network active - please note that the LPAR is connected to a VLAN. $ ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group defaul t qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: encc000: mtu 1500 qdisc noop state DOWN group default q len 1000 link/ether a2:8d:91:85:12:e3 brd ff:ff:ff:ff:ff:ff 3: enP1p0s0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 82:0c:2d:0c:b8:70 brd ff:ff:ff:ff:ff:ff 4: enP1p0s0d1: mtu 1500 qdisc noop state DOWN group defaul t qlen 1000 link/ether 82:0c:2d:0c:b8:71 brd ff:ff:ff:ff:ff:ff 5: enP2p0s0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 82:0c:2d:0c:b7:00 brd ff:ff:ff:ff:ff:ff 6: enP2p0s0d1: mtu 1500 qdisc noop state DOWN group defaul t qlen 1000 link/ether 82:0c:2d:0c:b7:01 brd ff:ff:ff:ff:ff:ff Wanting to have a look at the netplan config it turned out that there is no yaml file: $ ls -l /etc/netplan/ total 0 Adding one manually and applying it worked fine. So looks like the installer does not properly generate or copy a 01-netcfg.yaml to /etc/netplan. Please see below the entire steps as well as a compressed file with the entire content of /var/log To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1868246/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1798424] Re: Xenial Azure: Make generation of network config from IMDS hotplug scripts configurable opt-in
this should have had ubuntu task added. Has this been verified yet? ** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu Xenial) Status: New => Fix Committed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1798424 Title: Xenial Azure: Make generation of network config from IMDS hotplug scripts configurable opt-in Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: New Status in cloud-init source package in Xenial: Fix Committed Bug description: cloud-init v. 18.4-0ubuntu1~16.04.1 in -proposed automatically renders network configuration from Azure's IMDS by default instead of fallback config of dhcp on eth0. This represents a difference in behavior from current Xenial. On Xenial Azure, Ubuntu cloud images have udev scripts to handle network hotplug. Azure datasource has the ability to read full network config from their IMDS service and render hotplugged devices as well as remove the cloud-image default scripts. Make the cloud-init hotplug behavior configurable and default it to off in Xenial. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1798424/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1734167] Re: DNS doesn't work in no-cloud as launched by ubuntu
smoser, yeah, so like cloud-init.service should want/after systemd-resolved.service; or e.g. systemd-resolved.service should declare itself before cloud-init.service smoser, i think changing it in systemd unit might be better. ** Also affects: cloud-init (Ubuntu Artful) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Artful) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Bionic) Importance: High Status: Confirmed ** Also affects: systemd (Ubuntu Bionic) Importance: High Status: Confirmed ** Also affects: cloud-init (Ubuntu Zesty) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Zesty) 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/1734167 Title: DNS doesn't work in no-cloud as launched by ubuntu Status in cloud-init: Confirmed Status in cloud-init package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in cloud-init source package in Zesty: New Status in systemd source package in Zesty: New Status in cloud-init source package in Artful: New Status in systemd source package in Artful: New Status in cloud-init source package in Bionic: Confirmed Status in systemd source package in Bionic: Confirmed Bug description: I use no-cloud to test the kernel in CI (I am maintainer of the bcache subsystem), and have been running it successfully under 16.04 cloud images from qemu, using a qemu command that includes: -smbios "type=1,serial=ds=nocloud- net;s=https://raw.githubusercontent.com/mlyle/mlyle/master/cloud- metadata/linuxtst/" As documented here: http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html Under the new 17.10 cloud images, this doesn't work: the network comes up, but name resolution doesn't work-- /etc/resolv.conf is a symlink to a nonexistent file at this point of the boot and systemd-resolved is not running. When I manually hack /etc/resolv.conf in the cloud image to point to 4.2.2.1 it works fine. I don't know if nameservice not working is by design, but it seems like it should work. The documentation states: "With ds=nocloud-net, the seedfrom value must start with http://, https:// or ftp://"; And https is not going to work for a raw IP address. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1734167/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1717470] [NEW] cloud-init should show iproute2 output with MTU
Public bug reported: cloud-init should show output of $ ip address which includes mtu in the console.log ** Affects: cloud-init Importance: Undecided Status: New ** Tags: nplanfail ** Tags added: nplanfail -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1717470 Title: cloud-init should show iproute2 output with MTU Status in cloud-init: New Bug description: cloud-init should show output of $ ip address which includes mtu in the console.log To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1717470/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1707222] Re: usage of /tmp during boot is not safe due to systemd-tmpfiles-clean
/tmp is only guaranteed to be in a usable state after sysinit.target currently. Or more generally, after system is fully up only. During boot (initramfs, post-initramfs, early boot, post-boot) system services should use /run, private runtime dir, private tmp dir. This is not a bug in Ubuntu boot sequence. Please fix cloud-init to use /run. ** Changed in: systemd (Ubuntu) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1707222 Title: usage of /tmp during boot is not safe due to systemd-tmpfiles-clean Status in cloud-init: New Status in cloud-init package in Ubuntu: New Status in systemd package in Ubuntu: Won't Fix Bug description: Earlier this week on Zesty on Azure I saw a cloud-init failure in its 'mount_cb' function. That function esentially does: a.) make a tmp directory for a mount point b.) mount some filesystem to that mount point c.) call a function d.) unmount the directory What I recall was that access to a file inside the mount point failed during 'c'. This seems possible as systemd-tmpfiles-clean may be running at the same time as cloud-init (cloud-init.service in this example). It seems that this service basically inhibits *any* other service from using tmp files. It's ordering statements are only: After=local-fs.target time-sync.target Before=shutdown.target So while in most cases only services that run early in the boot process like cloud-init will be affected, any service could have its tmp files removed. this service could take quite a long time to run if /tmp/ had been filled with lots of files in the previous boot. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1707222/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1690388] Re: wrong hwaddr on the vlan bond with nplan and cloud-init
** Also 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/1690388 Title: wrong hwaddr on the vlan bond with nplan and cloud-init Status in cloud-init: New Status in cloud-init package in Ubuntu: In Progress Status in nplan package in Ubuntu: New Status in cloud-init source package in Xenial: New Status in nplan source package in Xenial: New Status in cloud-init source package in Yakkety: New Status in nplan source package in Yakkety: New Status in cloud-init source package in Zesty: New Status in nplan source package in Zesty: New Bug description: The expected hwaddresses are as follows: 4: bond0: mtu 1500 qdisc noqueue state UP group default link/ether a0:36:9f:2d:93:80 brd ff:ff:ff:ff:ff:ff inet6 fe80::a236:9fff:fe2d:9380/64 scope link valid_lft forever preferred_lft forever 5: bond0.101@bond0: mtu 1500 qdisc noqueue state UP group default link/ether a0:36:9f:2d:93:80 brd ff:ff:ff:ff:ff:ff inet 104.130.20.119/24 brd 104.130.20.255 scope global bond0.101 valid_lft forever preferred_lft forever inet6 fe80::a236:9fff:fe2d:9380/64 scope link valid_lft forever preferred_lft forever 6: bond0.401@bond0: mtu 1500 qdisc noqueue state UP group default link/ether a0:36:9f:2d:93:81 brd ff:ff:ff:ff:ff:ff inet 10.184.7.120/20 brd 10.184.15.255 scope global bond0.401 valid_lft forever preferred_lft forever inet6 fe80::a236:9fff:fe2d:9381/64 scope link valid_lft forever preferred_lft forever however cloud-init shows: May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: Net device info May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: +---+--+--+---+---+---+ May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: | Device | Up | Address| Mask | Scope | Hw-Address| May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: +---+--+--+---+---+---+ May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: | bond0 | True | . | . | . | a0:36:9f:2d:93:81 | May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: | bond0 | True | fe80::a236:9fff:fe2d:9381/64 | . | link | a0:36:9f:2d:93:81 | May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: | bond0.101 | True | 104.130.20.119| 255.255.255.0 | . | a0:36:9f:2d:93:81 | May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: | bond0.101 | True | fe80::a236:9fff:fe2d:9381/64 | . | link | a0:36:9f:2d:93:81 | May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: | lo| True | 127.0.0.1 | 255.0.0.0 | . | . | May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: | lo| True | ::1/128| . | host | . | May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: | bond0.401 | True | 10.184.7.120 | 255.255.240.0 | . | a0:36:9f:2d:93:81 | May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: | bond0.401 | True | fe80::a236:9fff:fe2d:9381/64 | . | link | a0:36:9f:2d:93:81 | May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: | ens9f1 | True | . | . | . | a0:36:9f:2d:93:81 | May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: | ens9f0 | True | . | . | . | a0:36:9f:2d:93:81 | May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: +---+--+--+---+---+---+ Specifically bond0 | True | fe80::a236:9fff:fe2d:9381/64 | . | link | a0:36:9f:2d:93:81 bond0.101 | True |104.130.20.119| 255.255.255.0 | . | a0:36:9f:2d:93:81 Instead of expected a0:36:9f:2d:93:80 The generated netplan.yaml does not set macaddress on the vlans at all. Where as the network_data.json does explicitely specifies the mac address to be in use for those vlans: "vlan_mac_address" : "a0:36:9f:2d:93:80" To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1690388/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1689346] Re: cloud-init and nplan do not parse and use OpenStack networking correctly with netmask
** Also 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/1689346 Title: cloud-init and nplan do not parse and use OpenStack networking correctly with netmask Status in cloud-init: New Status in cloud-init package in Ubuntu: In Progress Status in nplan package in Ubuntu: Invalid Status in cloud-init source package in Xenial: Confirmed Status in nplan source package in Xenial: Invalid Status in cloud-init source package in Yakkety: Confirmed Status in nplan source package in Yakkety: Invalid Status in cloud-init source package in Zesty: Confirmed Status in nplan source package in Zesty: Invalid Bug description: networking data josn has: "ip_address" : "104.130.20.155", "netmask" : "255.255.255.0" "ip_address" : "10.184.3.234", "netmask" : "255.255.240.0", that got rendered into nplan as: - 104.130.20.155/255.255.255.0 - 10.184.3.234/255.255.240.0 which it failed to parse Stderr: Error in network definition //etc/netplan/50-cloud-init.yaml line 32 column 12: invalid prefix length in address '104.130.20.155/255.255.255.0' I believe nplan is expecing CIDR notation of /24 or some such. I belive the current plan is to fix cloud-init to generate /24 cidr notation in the nplan renderer. This needs SRU into xenial. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1689346/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1690480] Re: cloud-init / nplan - missing bond mode miimon xmit_hash_policy
** Also 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/1690480 Title: cloud-init / nplan - missing bond mode miimon xmit_hash_policy Status in cloud-init: New Status in cloud-init package in Ubuntu: In Progress Status in cloud-init source package in Xenial: New Status in cloud-init source package in Yakkety: New Status in cloud-init source package in Zesty: New Bug description: Given network-data.json http://paste.ubuntu.com/24561026/ cloud-init generates http://paste.ubuntu.com/24564006/ which is missing "bond_mode" : "802.3ad", "bond_miimon" : 100, "bond_xmit_hash_policy" : "layer3+4" For the bond specification As per nplan docs it should be defined as parameters dictionary https://git.launchpad.net/netplan/tree/doc/netplan.md#n302 mode: 802.3ad mii-monitor-interval: 100 transmit-hash-policy: layer3+4 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1690480/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1506958] [NEW] TypeError: object.__new__(thread.lock) is not safe, use thread.lock.__new__()
Public bug reported: When using /usr/bin/nova-api, running $ openstack availability zone list -> works fine. If using the wsgi scripts, and running nova-api via e.g. uwsgi, the same client command fails as following: 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions [req-184fd1f3-ae97-49d0-85dd-05ef08800238 0e56b818bc9c4eaea4b8d6a2f5da6227 906359c0c71749ceb27e46612e0419ce - - -] Unexpected exception in API method 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions Traceback (most recent call last): 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line 478, in wrapped 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions return f(*args, **kwargs) 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/api/openstack/compute/availability_zone.py", line 115, in detail 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions return self._describe_availability_zones_verbose(context) 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/api/openstack/compute/availability_zone.py", line 61, in _describe_availability_zones_verbose 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions ctxt = context.elevated() 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/context.py", line 198, in elevated 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions context = copy.deepcopy(self) 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/copy.py", line 190, in deepcopy 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions y = _reconstruct(x, rv, 1, memo) 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/copy.py", line 334, in _reconstruct 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions state = deepcopy(state, memo) 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/copy.py", line 163, in deepcopy 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions y = copier(x, memo) 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/copy.py", line 257, in _deepcopy_dict 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions y[deepcopy(key, memo)] = deepcopy(value, memo) 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/copy.py", line 190, in deepcopy 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions y = _reconstruct(x, rv, 1, memo) 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/copy.py", line 334, in _reconstruct 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions state = deepcopy(state, memo) 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/copy.py", line 163, in deepcopy 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions y = copier(x, memo) 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/copy.py", line 257, in _deepcopy_dict 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions y[deepcopy(key, memo)] = deepcopy(value, memo) 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/copy.py", line 190, in deepcopy 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions y = _reconstruct(x, rv, 1, memo) 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/copy.py", line 329, in _reconstruct 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions y = callable(*args) 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/copy_reg.py", line 93, in __newobj__ 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions return cls.__new__(cls, *args) 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions TypeError: object.__new__(thread.lock) is not safe, use thread.lock.__new__() 2015-10-16 16:58:20.720 18938 ERROR nova.api.openstack.extensions 2015-10-16 16:58:20.721 18938 INFO nova.api.openstack.wsgi [req-184fd1f3-ae97-49d0-85dd-05ef08800238 0e56b818bc9c4eaea4b8d6a2f5da6227 906359c0c71749ceb27e46612e0419ce - - -] HTTP exception thrown: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. Looks like a dejavu of https://bugs.launchpad.net/python-novaclient/+bug/1123561 but I am not certain. This is with liberty final release (or so i believe at the moment). ** Affects: nova Importance: Undecided Status: New -- You received this