[Yahoo-eng-team] [Bug 1919177] Re: Azure: issues with accelerated networking on Hirsute

[Dimitri John Ledkov]

** 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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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 : 

[Yahoo-eng-team] [Bug 1892851] Re: Staged boot, to fix integration of systemd generators

[Dimitri John Ledkov]

@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 

[Yahoo-eng-team] [Bug 1880734] [NEW] ordering cycle upon booting groovy

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

 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

[Dimitri John Ledkov]

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

[Dimitri John Ledkov]

/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

[Dimitri John Ledkov]

** 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

[Dimitri John Ledkov]

** 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

[Dimitri John Ledkov]

** 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__()

[Dimitri John Ledkov]

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