[Yahoo-eng-team] [Bug 1978489] Re: libvirt / cgroups v2: cannot boot instance with more than 16 CPUs
comment #17 stated that noble and mantic have the patch, so I'm marking the noble (devel) task as fix released. ** Changed in: nova (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1978489 Title: libvirt / cgroups v2: cannot boot instance with more than 16 CPUs Status in Ubuntu Cloud Archive: Invalid Status in Ubuntu Cloud Archive yoga series: Fix Committed Status in OpenStack Compute (nova): In Progress Status in nova package in Ubuntu: Fix Released Status in nova source package in Jammy: Fix Released Bug description: Description === Using the libvirt driver and a host OS that uses cgroups v2 (RHEL 9, Ubuntu Jammy), an instance with more than 16 CPUs cannot be booted. Steps to reproduce == 1. Boot an instance with 10 (or more) CPUs on RHEL 9 or Ubuntu Jammy using Nova with the libvirt driver. Expected result === Instance boots. Actual result = Instance fails to boot with a 'Value specified in CPUWeight is out of range' error. Environment === Originially report as a libvirt but in RHEL 9 [1] Additional information == This is happening because Nova defaults to 1024 * (# of CPUs) for the value of domain/cputune/shares in the libvirt XML. This is then passed directly by libvirt to the cgroups API, but cgroups v2 has a maximum value of 1. 1 / 1024 ~= 9.76 [1] https://bugzilla.redhat.com/show_bug.cgi?id=2035518 Ubuntu SRU Details: [Impact] See above. [Test Case] See above. [Regression Potential] We've had this change in other jammy-based versions of the nova package for a while now, including zed, antelope, bobcat. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1978489/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1774666] Re: Bond interfaces stuck at 1500 MTU on Bionic
Somehow the netplan.io and cloud-init tasks are linked in terms of those nominations. If I approve the cloud-init ones, netplan's also get approved. ** Also affects: cloud-init (Ubuntu Artful) Importance: Undecided Status: New ** Also affects: netplan.io (Ubuntu Artful) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: netplan.io (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: netplan.io (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Cosmic) Importance: Undecided Status: Confirmed ** Also affects: netplan.io (Ubuntu Cosmic) Importance: Undecided Status: Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1774666 Title: Bond interfaces stuck at 1500 MTU on Bionic Status in cloud-init: Fix Committed Status in MAAS: Invalid Status in cloud-init package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: Confirmed Status in cloud-init source package in Xenial: New Status in netplan.io source package in Xenial: New Status in cloud-init source package in Artful: New Status in netplan.io source package in Artful: New Status in cloud-init source package in Bionic: New Status in netplan.io source package in Bionic: New Status in cloud-init source package in Cosmic: Confirmed Status in netplan.io source package in Cosmic: Confirmed Bug description: When deploying a machine through MAAS with bonded network interfaces, the bond does not have a 9000 byte MTU applied despite the attached VLANs having had a 9000 MTU explicitly set. The MTU size is set on the bond members, but not on the bond itself in Netplan. Consequently, when the bond is brought up, the interface MTU is decreased from 9000 to 1500. Manually changing the interface MTU after boot is successful. This is not observed when deploying Xenial on the same machine. The bond comes up at the expected 9000 byte MTU. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1774666/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1751051] [NEW] UnicodeEncodeError when creating user with non-ascii chars
Public bug reported: I was testing subiquity, and at the user creation prompt typed in "André D'Silva" for the username, and just "andre" for the login. The installer finished fine, but upon first login I couldn't login. Booting into rescue mode showed me that the user had not been created. Checking cloud-init logs, I find the UnicodeEncodeError. 2018-02-22 12:44:01,386 - __init__.py[DEBUG]: Adding user andre 2018-02-22 12:44:01,387 - util.py[WARNING]: Failed to create user andre 2018-02-22 12:44:01,387 - util.py[DEBUG]: Failed to create user andre Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/distros/__init__.py", line 463, in add_user util.subp(adduser_cmd, logstring=log_adduser_cmd) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1871, in subp env=env, shell=shell) File "/usr/lib/python3.6/subprocess.py", line 709, in __init__ restore_signals, start_new_session) File "/usr/lib/python3.6/subprocess.py", line 1275, in _execute_child restore_signals, start_new_session, preexec_fn) UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in position 4: ordinal not in range(128) user-data contains this: #cloud-config hostname: sbqt users: - gecos: "Andr\xE9 D'Silva" groups: [adm, cdrom, dip, lpadmin, plugdev, sambashare, debian-tor, libvirtd, lxd, sudo] lock-passwd: false name: andre passwd: $6$UaxxahbQam4Ko1g7$WB5tNuCR84DvWwI7ovxDiofIdLP47pG2USPel2iIQV/qzzT3pAb1VtlbelCR2iCNRxCoJgsVafcNtqdfz1/IL1 shell: /bin/bash ssh_import_id: ['lp:ahasenack'] cloud-init is 17.2-34-g644048e3-0ubuntu1 from bionic/main. ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1751051 Title: UnicodeEncodeError when creating user with non-ascii chars Status in cloud-init: New Bug description: I was testing subiquity, and at the user creation prompt typed in "André D'Silva" for the username, and just "andre" for the login. The installer finished fine, but upon first login I couldn't login. Booting into rescue mode showed me that the user had not been created. Checking cloud-init logs, I find the UnicodeEncodeError. 2018-02-22 12:44:01,386 - __init__.py[DEBUG]: Adding user andre 2018-02-22 12:44:01,387 - util.py[WARNING]: Failed to create user andre 2018-02-22 12:44:01,387 - util.py[DEBUG]: Failed to create user andre Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/distros/__init__.py", line 463, in add_user util.subp(adduser_cmd, logstring=log_adduser_cmd) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1871, in subp env=env, shell=shell) File "/usr/lib/python3.6/subprocess.py", line 709, in __init__ restore_signals, start_new_session) File "/usr/lib/python3.6/subprocess.py", line 1275, in _execute_child restore_signals, start_new_session, preexec_fn) UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in position 4: ordinal not in range(128) user-data contains this: #cloud-config hostname: sbqt users: - gecos: "Andr\xE9 D'Silva" groups: [adm, cdrom, dip, lpadmin, plugdev, sambashare, debian-tor, libvirtd, lxd, sudo] lock-passwd: false name: andre passwd: $6$UaxxahbQam4Ko1g7$WB5tNuCR84DvWwI7ovxDiofIdLP47pG2USPel2iIQV/qzzT3pAb1VtlbelCR2iCNRxCoJgsVafcNtqdfz1/IL1 shell: /bin/bash ssh_import_id: ['lp:ahasenack'] cloud-init is 17.2-34-g644048e3-0ubuntu1 from bionic/main. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1751051/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1498946] Re: local dhcp service not working on Icehouse
** Also affects: nova Importance: Undecided Status: New ** Also affects: landscape Importance: Undecided Status: New ** No longer affects: nova ** Also affects: landscape/cisco-odl Importance: Undecided Status: New ** Changed in: landscape/cisco-odl Milestone: None => falkor-0.9 ** No longer affects: landscape -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1498946 Title: local dhcp service not working on Icehouse Status in Landscape Server cisco-odl series: New Status in neutron-openvswitch package in Juju Charms Collection: Confirmed Status in nova-compute package in Juju Charms Collection: Confirmed Bug description: DHCP and metadata requests from guests fail in an Icehouse deploy when deploying without a neutron gateway and enable-local-dhcp-and-metadata set to true in neutron-openvswitch. To manage notifications about this bug go to: https://bugs.launchpad.net/landscape/cisco-odl/+bug/1498946/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1496746] Re: When hugepages is enabled shmmax is not changed
** Also affects: nova Importance: Undecided Status: New ** Also affects: landscape Importance: Undecided Status: New ** No longer affects: nova ** Also affects: landscape/cisco-odl Importance: Undecided Status: New ** Changed in: landscape/cisco-odl Milestone: None => falkor-0.9 ** No longer affects: landscape -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1496746 Title: When hugepages is enabled shmmax is not changed Status in Landscape Server cisco-odl series: New Status in nova-compute package in Juju Charms Collection: Confirmed Bug description: When enabling hugepages Shared Memory Max must be greator or equal to the total size of hugepages. For 2MB pages, TotalHugepageSize = vm.nr_hugepages * 2 * 1024 * 1024 To manage notifications about this bug go to: https://bugs.launchpad.net/landscape/cisco-odl/+bug/1496746/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
