[Yahoo-eng-team] [Bug 1869222] [NEW] In Resize Instance interface Advanced Options -> Server Group option does not do anything
Public bug reported: Choosing a server affinity group from the drop-down menu does not do anything. Checking resize_instance.py there is no mentioning of the form's server_group field: https://pastebin.ubuntu.com/p/Dp5jpBnxrk/ ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1869222 Title: In Resize Instance interface Advanced Options -> Server Group option does not do anything Status in OpenStack Dashboard (Horizon): New Bug description: Choosing a server affinity group from the drop-down menu does not do anything. Checking resize_instance.py there is no mentioning of the form's server_group field: https://pastebin.ubuntu.com/p/Dp5jpBnxrk/ To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1869222/+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 1869244] [NEW] RowNotFound: Cannot find Bridge with name=tbr-XXXXXXXX-X when using trunk bridges with DPDK vhostusermode
Public bug reported: DPDK vhostuser mode (DPDK/vhu) means that when an instance is powered off the port is deleted, and when an instance is powered on a port is created. This means a reboot is functionally a super fast delete-then-create. Neutron trunking mode in combination with DPDK/vhu implements a trunk bridge for each tenant, and the ports for the instances are created as subports of that bridge. The standard way a trunk bridge works is that when all the subports are deleted, a thread is spawned to delete the trunk bridge, because that is an expensive and time-consuming operation. That means that if the port in question is the only port on the trunk on that compute node, this happens: 1. The port is deleted 2. A thread is spawned to delete the trunk 3. The port is recreated If the trunk is deleted after #3 happens then the instance has no networking and is inaccessible; this is the scenario that was dealt with in a previous change [1]. But there continue to be issues with errors "RowNotFound: Cannot find Bridge with name=tbr--X". 2020-03-02 10:37:45.929 6278 ERROR ovsdbapp.backend.ovs_idl.command [-] Error executing command: RowNotFound: Cannot find Bridge with name=tbr--X 2020-03-02 10:37:45.929 6278 ERROR ovsdbapp.backend.ovs_idl.command Traceback (most recent call last): 2020-03-02 10:37:45.929 6278 ERROR ovsdbapp.backend.ovs_idl.command File "/usr/lib/python2.7/site-packages/ovsdbapp/backend/ovs_idl/command.py", line 37, in execute 2020-03-02 10:37:45.929 6278 ERROR ovsdbapp.backend.ovs_idl.command self.run_idl(None) 2020-03-02 10:37:45.929 6278 ERROR ovsdbapp.backend.ovs_idl.command File "/usr/lib/python2.7/site-packages/ovsdbapp/schema/open_vswitch/commands.py", line 335, in run_idl 2020-03-02 10:37:45.929 6278 ERROR ovsdbapp.backend.ovs_idl.command br = idlutils.row_by_value(self.api.idl, 'Bridge', 'name', self.bridge) 2020-03-02 10:37:45.929 6278 ERROR ovsdbapp.backend.ovs_idl.command File "/usr/lib/python2.7/site-packages/ovsdbapp/backend/ovs_idl/idlutils.py", line 63, in row_by_value 2020-03-02 10:37:45.929 6278 ERROR ovsdbapp.backend.ovs_idl.command raise RowNotFound(table=table, col=column, match=match) 2020-03-02 10:37:45.929 6278 ERROR ovsdbapp.backend.ovs_idl.command RowNotFound: Cannot find Bridge with name=tbr--X 2020-03-02 10:37:45.929 6278 ERROR ovsdbapp.backend.ovs_idl.command 2020-03-02 10:37:45.932 6278 ERROR neutron.services.trunk.drivers.openvswitch.agent.ovsdb_handler [-] Cannot obtain interface list for bridge tbr--X: Cannot find Bridge with name=tbr--X: RowNotFound: Cannot find Bridge with name=tbr--X What I believe is happening in this case is that the trunk is being deleted in the middle of the execution of #3, so that it stops existing in the middle of the port creation logic but before the port is actually recreated. This issue was observed in setups running Queens. ** Affects: neutron Importance: Undecided Assignee: Nate Johnston (nate-johnston) Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1869244 Title: RowNotFound: Cannot find Bridge with name=tbr--X when using trunk bridges with DPDK vhostusermode Status in neutron: New Bug description: DPDK vhostuser mode (DPDK/vhu) means that when an instance is powered off the port is deleted, and when an instance is powered on a port is created. This means a reboot is functionally a super fast delete-then-create. Neutron trunking mode in combination with DPDK/vhu implements a trunk bridge for each tenant, and the ports for the instances are created as subports of that bridge. The standard way a trunk bridge works is that when all the subports are deleted, a thread is spawned to delete the trunk bridge, because that is an expensive and time-consuming operation. That means that if the port in question is the only port on the trunk on that compute node, this happens: 1. The port is deleted 2. A thread is spawned to delete the trunk 3. The port is recreated If the trunk is deleted after #3 happens then the instance has no networking and is inaccessible; this is the scenario that was dealt with in a previous change [1]. But there continue to be issues with errors "RowNotFound: Cannot find Bridge with name=tbr--X". 2020-03-02 10:37:45.929 6278 ERROR ovsdbapp.backend.ovs_idl.command [-] Error executing command: RowNotFound: Cannot find Bridge with name=tbr--X 2020-03-02 10:37:45.929 6278 ERROR ovsdbapp.backend.ovs_idl.command Traceback (most recent call last): 2020-03-02 10:37:45.929 6278 ERROR ovsdbapp.backend.ovs_idl.command File "/usr/lib/python2.7/site-packages/ovsdbapp/backend/ovs_idl/command.py", line 37, in execute 2020-03-02 10:37:45.929 6278 ERROR ovsdbapp.backend.ovs_idl.command
[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 1869129] [NEW] neutron accepts CIDR in security groups that are invalid in ovn
Public bug reported: We have found that there are some CIDR accepted by neutron, which does not work in networking ovn. Specifically, these are network CIDRs with the host bits set. Steps to reproduce - Create VM. Attach a floating IP to it - Remove all security group. Attach a blank security group to it - Add a security group rule and start ping For example, if my IP is 10.10.10.175/26 (first 3 octets changed for privacy), the following security rules work openstack security group rule create --protocol icmp --remote-ip 10.10.10.175/32 cidr openstack security group rule create --protocol icmp --remote-ip 10.10.10.128/26 cidr However, the following security group rule do not work openstack security group rule create --protocol icmp --remote-ip 10.10.10.175/26 cidr FWIW, in our testing, CIDRs like 10.10.10.175/26 work in other drivers, like linuxbridge and midonet. ** Affects: neutron Importance: Undecided Status: New ** Description changed: We have found that there are some CIDR accepted by neutron, which does not work in networking ovn. Specifically, these are network CIDRs with the host bits set. Steps to reproduce - Create VM. Attach a floating IP to it - Remove all security group. Attach a blank security group to it - Add a security group rule and start ping - For example, if my IP is 10.10.10.175/26 (first 3 bits changed for + For example, if my IP is 10.10.10.175/26 (first 3 octets changed for privacy), the following security rules work openstack security group rule create --protocol icmp --remote-ip 10.10.10.175/32 cidr openstack security group rule create --protocol icmp --remote-ip 10.10.10.128/26 cidr However, the following security group rule do not work openstack security group rule create --protocol icmp --remote-ip 10.10.10.175/26 cidr - - FWIW, in our testing, CIDRs like 10.10.10.175/26 work in other drivers, like linuxbridge and midonet. + FWIW, in our testing, CIDRs like 10.10.10.175/26 work in other drivers, + like linuxbridge and midonet. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1869129 Title: neutron accepts CIDR in security groups that are invalid in ovn Status in neutron: New Bug description: We have found that there are some CIDR accepted by neutron, which does not work in networking ovn. Specifically, these are network CIDRs with the host bits set. Steps to reproduce - Create VM. Attach a floating IP to it - Remove all security group. Attach a blank security group to it - Add a security group rule and start ping For example, if my IP is 10.10.10.175/26 (first 3 octets changed for privacy), the following security rules work openstack security group rule create --protocol icmp --remote-ip 10.10.10.175/32 cidr openstack security group rule create --protocol icmp --remote-ip 10.10.10.128/26 cidr However, the following security group rule do not work openstack security group rule create --protocol icmp --remote-ip 10.10.10.175/26 cidr FWIW, in our testing, CIDRs like 10.10.10.175/26 work in other drivers, like linuxbridge and midonet. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1869129/+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 1869277] [NEW] azure vms with cloud-init display ec2 info in output
Public bug reported: Azure VMs that are deployed sometimes show EC2 related output. This happens intermittently. Output of bug find is here: https://paste.ubuntu.com/p/nrWNYjzsXH/ ** 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/1869277 Title: azure vms with cloud-init display ec2 info in output Status in cloud-init: New Bug description: Azure VMs that are deployed sometimes show EC2 related output. This happens intermittently. Output of bug find is here: https://paste.ubuntu.com/p/nrWNYjzsXH/ To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1869277/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1813147] Re: p35 jobs are failing with subunit.parser ... FAILED
** Changed in: glance
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1813147
Title:
p35 jobs are failing with subunit.parser ... FAILED
Status in Glance:
Fix Released
Status in OpenStack Compute (nova):
Fix Released
Bug description:
Various py35 jobs[1] are failing recently with:
2019-01-22 00:10:44.708744 | ubuntu-xenial | {0} subunit.parser [0.000360s]
... FAILED
2019-01-22 00:10:44.708947 | ubuntu-xenial |
2019-01-22 00:10:44.709000 | ubuntu-xenial | Captured Parser Error:
2019-01-22 00:10:44.709057 | ubuntu-xenial | ~~
2019-01-22 00:10:44.709122 | ubuntu-xenial | b'Short read - got 167
bytes, wanted 4263 bytes'
It seems that when a job fails, the log of the test case that
triggered the failure is truncated. Also it feels that it is caused by
extensive logging.
There was a past cinder bug[2] that was marked fixed after couple of
logging reduction.
There was 11 failures in the last 24 hours[3]
[1]
http://logs.openstack.org/58/632158/1/check/cross-nova-py35/afe0282/job-output.txt#_2019-01-22_00_10_44_708744
[2] https://bugs.launchpad.net/cinder/+bug/1728640
[3]
http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22subunit.parser%5C%22%20AND%20message:%5C%22FAILED%5C%22%20AND%20voting:1=864000s
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1813147/+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 1869139] Re: In linux IP rule the pref and priority are interchangeable, use priority every time.
** Changed in: neutron Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1869139 Title: In linux IP rule the pref and priority are interchangeable, use priority every time. Status in neutron: Invalid Bug description: In IP rule the pref and priority are interchangeable.When using pref as input, the returned result is priority, which is not standard, so need to convert pref to priority every time. * Version: ** OpenStack version(rocky) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1869139/+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 1869139] [NEW] In linux IP rule the pref and priority are interchangeable, use priority every time.
Public bug reported: In IP rule the pref and priority are interchangeable.When using pref as input, the returned result is priority, which is not standard, so need to convert pref to priority every time. * Version: ** OpenStack version(rocky) ** Affects: neutron Importance: Undecided Assignee: jacy lee (jacylees) Status: New ** Changed in: neutron Assignee: (unassigned) => jacy lee (jacylees) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1869139 Title: In linux IP rule the pref and priority are interchangeable, use priority every time. Status in neutron: New Bug description: In IP rule the pref and priority are interchangeable.When using pref as input, the returned result is priority, which is not standard, so need to convert pref to priority every time. * Version: ** OpenStack version(rocky) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1869139/+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 1869136] [NEW] Use public flat network to create vm faild
Public bug reported: When creating a VM, use a flat network(--public) to report an error, and use vxlan non public network to create a VM normally. ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1869136 Title: Use public flat network to create vm faild Status in neutron: New Bug description: When creating a VM, use a flat network(--public) to report an error, and use vxlan non public network to create a VM normally. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1869136/+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 1868691] Re: neutron-rally-task fails 100% on stable branches
** Changed in: networking-ovn
Assignee: (unassigned) => Bernard Cafarelli (bcafarel)
** Changed in: networking-ovn
Status: New => Fix Released
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1868691
Title:
neutron-rally-task fails 100% on stable branches
Status in networking-ovn:
Fix Released
Status in neutron:
Fix Released
Bug description:
Since March 23, the job started to fail on train:
https://zuul.opendev.org/t/openstack/build/0bea3158833944c185b5101f823af9c1
https://zuul.opendev.org/t/openstack/build/0b24c107a4e44d91addda71bf193ccfa
https://zuul.opendev.org/t/openstack/build/20b752ab736a45c09ac25921ad19c7d9
recheck does not help, jobs fail with:
++ /opt/stack/rally-openstack/devstack/lib/rally:init_rally:142 : rally
--config-file /etc/rally/rally.conf deployment create --name devstack
--filename /tmp/tmp.U7S1L63idY
2020-03-23 23:47:41.570 31668 WARNING rally.common.plugin.discover [-]
Failed to load plugins from module 'rally_openstack' (package:
'rally-openstack 1.7.1.dev9'): (kubernetes 10.0.1
(/usr/local/lib/python3.6/dist-packages),
Requirement.parse('kubernetes>=11.0.0')): pkg_resources.VersionConflict:
(kubernetes 10.0.1 (/usr/local/lib/python3.6/dist-packages),
Requirement.parse('kubernetes>=11.0.0'))[00m
Env manager got invalid spec:
['There is no Platform plugin `existing` in openstack platform.']
+ /opt/stack/rally-openstack/devstack/lib/rally:init_rally:1 : exit_trap
To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-ovn/+bug/1868691/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1869155] [NEW] Cloud-init uses macaddress keyword on s390x where MAC addresses are not necessarily stable/unique across reboots
Public bug reported:
While performing a subiquity focal installation on an s390x LPAR (where the
LPAR is connected to a VLAN trunk) I saw a section like this:
match:
macaddress: 02:28:0b:00:00:53
So the macaddress keyword is used, but on several s390x machine generation MAC
addresses are
not necessarily stable and uniquie across reboots.
(z14 GA2 and newer system have in between a modified firmware that ensures that
MAC addresses are stable and uniquire across reboots, but for z14 GA 1 and
older systems, incl. the z13 that I used this is not the case - and a backport
of the firmware modification is very unlikely)
The configuration that I found is this:
$ cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
enc600:
addresses:
- 10.245.236.26/24
gateway4: 10.245.236.1
match:
macaddress: 02:28:0b:00:00:53
nameservers:
addresses:
- 10.245.236.1
set-name: enc600
version: 2
(This is a spin-off of ticket LP 1868246.)
It's understood that the initial idea for the MAC addresses was to have a
unique identifier, but
I think with the right tooling (ip, ifconfig, ethtool or even the
network-manager UI) you can even change MAC addresses today on other platforms.
Nowadays interface names are based on their underlying physical
device/address (here in this case '600' or to be precise '0600' -
leading '0' are removed), which makes the interface and it's name
already quite unique - since it is not possible to have two devices (in
one system) with the exact same address.
** Affects: cloud-init
Importance: Undecided
Status: New
** Affects: ubuntu-z-systems
Importance: Undecided
Assignee: Canonical Server Team (canonical-server)
Status: New
** Tags: installer s390x
** Also affects: ubuntu-z-systems
Importance: Undecided
Status: New
** Changed in: ubuntu-z-systems
Assignee: (unassigned) => Canonical Server Team (canonical-server)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1869155
Title:
Cloud-init uses macaddress keyword on s390x where MAC addresses are
not necessarily stable/unique across reboots
Status in cloud-init:
New
Status in Ubuntu on IBM z Systems:
New
Bug description:
While performing a subiquity focal installation on an s390x LPAR (where the
LPAR is connected to a VLAN trunk) I saw a section like this:
match:
macaddress: 02:28:0b:00:00:53
So the macaddress keyword is used, but on several s390x machine generation
MAC addresses are
not necessarily stable and uniquie across reboots.
(z14 GA2 and newer system have in between a modified firmware that ensures
that MAC addresses are stable and uniquire across reboots, but for z14 GA 1 and
older systems, incl. the z13 that I used this is not the case - and a backport
of the firmware modification is very unlikely)
The configuration that I found is this:
$ cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
enc600:
addresses:
- 10.245.236.26/24
gateway4: 10.245.236.1
match:
macaddress: 02:28:0b:00:00:53
nameservers:
addresses:
- 10.245.236.1
set-name: enc600
version: 2
(This is a spin-off of ticket LP 1868246.)
It's understood that the initial idea for the MAC addresses was to have a
unique identifier, but
I think with the right tooling (ip, ifconfig, ethtool or even the
network-manager UI) you can even change MAC addresses today on other platforms.
Nowadays interface names are based on their underlying physical
device/address (here in this case '600' or to be precise '0600' -
leading '0' are removed), which makes the interface and it's name
already quite unique - since it is not possible to have two devices
(in one system) with the exact same address.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1869155/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe :
[Yahoo-eng-team] [Bug 1869181] [NEW] [Focal] cloud-init service never get nework actived during MaaS deploy.
Public bug reported: MaaS server used to wait for cloud-init on target reporting status. It works well on Bionic desktop but failed on Focal desktop. It might be caused by the ordering of systemd service because the network service always is started after the cloud-init service. Journalctl: 三 26 18:34:18 CANONICALID cloud-init[816]: Cloud-init v. 20.1-10-g71af48df-0ubuntu2 running 'init' at Thu, 26 Mar 2020 10:34:18 +. Up 6.59 seconds. 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: Net device info 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: +-+---+---+---+---+---+ 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: | Device | Up | Address |Mask | Scope | Hw-Address| 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: +-+---+---+---+---+---+ 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: | enx00e04c70045f | False | . | . | . | 00:e0:4c:70:04:5f | 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: |lo | True | 127.0.0.1 | 255.0.0.0 | host | . | 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: |lo | True | ::1/128 | . | host | . | 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: | wlp2s0 | False | . | . | . | 9c:b6:d0:8e:90:81 | 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: +-+---+---+---+---+---+ .[skip] 三 26 18:34:18 CANONICALID cloud-init[816]: 2020-03-26 10:34:18,361 - handlers.py[WARNING]: failed posting event: start: init-network/check-cache: attempting to read from cache [trust] .[skip] 三 26 18:36:25 CANONICALID systemd[1]: Starting Network Manager... ** Affects: cloud-init Importance: Undecided Status: New ** Affects: oem-priority Importance: Critical Status: New ** Also affects: oem-priority Importance: Undecided Status: New ** Changed in: oem-priority Importance: Undecided => Critical -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1869181 Title: [Focal] cloud-init service never get nework actived during MaaS deploy. Status in cloud-init: New Status in OEM Priority Project: New Bug description: MaaS server used to wait for cloud-init on target reporting status. It works well on Bionic desktop but failed on Focal desktop. It might be caused by the ordering of systemd service because the network service always is started after the cloud-init service. Journalctl: 三 26 18:34:18 CANONICALID cloud-init[816]: Cloud-init v. 20.1-10-g71af48df-0ubuntu2 running 'init' at Thu, 26 Mar 2020 10:34:18 +. Up 6.59 seconds. 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: Net device info 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: +-+---+---+---+---+---+ 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: | Device | Up | Address |Mask | Scope | Hw-Address| 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: +-+---+---+---+---+---+ 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: | enx00e04c70045f | False | . | . | . | 00:e0:4c:70:04:5f | 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: |lo | True | 127.0.0.1 | 255.0.0.0 | host | . | 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: |lo | True | ::1/128 | . | host | . | 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: | wlp2s0 | False | . | . | . | 9c:b6:d0:8e:90:81 | 三 26 18:34:18 CANONICALID cloud-init[816]: ci-info: +-+---+---+---+---+---+ .[skip] 三 26 18:34:18 CANONICALID cloud-init[816]: 2020-03-26 10:34:18,361 - handlers.py[WARNING]: failed posting event: start: init-network/check-cache: attempting to read from cache [trust] .[skip] 三 26 18:36:25 CANONICALID systemd[1]: Starting Network Manager... To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1869181/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1869182] [NEW] Poor LUKSv1 performance when using native QEMU decryption
Public bug reported: Description === LUKSv1 encrypted volumes have been natively decrypted by QEMU since I5a0de814f2868f1a4980a69b72b45ee829cedb94. This behaviour is not optional at present. Recently discovered performance issues within the libgcrypt library [1] used by QEMU to decrypt LUKSv1 disks mean that some users may wish to disable this feature within the libvirt driver. Disabling native decryption by QEMU should result in the original dm- crypt approach being taken using encryptors provided from os-brick. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1762765 Steps to reproduce == * Attach a LUKSv1 encrypted volume to an instance * Test I/O performance within the instance to the volume. Expected result === Performance is close to baremetal performance using dm-crypt. Actual result = Performance is severely degraded if the libgcrypt issue [1] is not resolved on the host. Environment === 1. Exact version of OpenStack you are running. See the following list for all releases: http://docs.openstack.org/releases/ Master. 2. Which hypervisor did you use? (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...) What's the version of that? libvirt + QEMU/KVM 2. Which storage type did you use? (For example: Ceph, LVM, GPFS, ...) What's the version of that? N/A - LUKSv1 encryption used. 3. Which networking type did you use? (For example: nova-network, Neutron with OpenVSwitch, ...) N/A Logs & Configs == N/A ** Affects: nova Importance: High Status: New ** Changed in: nova Importance: Undecided => High -- 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/1869182 Title: Poor LUKSv1 performance when using native QEMU decryption Status in OpenStack Compute (nova): New Bug description: Description === LUKSv1 encrypted volumes have been natively decrypted by QEMU since I5a0de814f2868f1a4980a69b72b45ee829cedb94. This behaviour is not optional at present. Recently discovered performance issues within the libgcrypt library [1] used by QEMU to decrypt LUKSv1 disks mean that some users may wish to disable this feature within the libvirt driver. Disabling native decryption by QEMU should result in the original dm- crypt approach being taken using encryptors provided from os-brick. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1762765 Steps to reproduce == * Attach a LUKSv1 encrypted volume to an instance * Test I/O performance within the instance to the volume. Expected result === Performance is close to baremetal performance using dm-crypt. Actual result = Performance is severely degraded if the libgcrypt issue [1] is not resolved on the host. Environment === 1. Exact version of OpenStack you are running. See the following list for all releases: http://docs.openstack.org/releases/ Master. 2. Which hypervisor did you use? (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...) What's the version of that? libvirt + QEMU/KVM 2. Which storage type did you use? (For example: Ceph, LVM, GPFS, ...) What's the version of that? N/A - LUKSv1 encryption used. 3. Which networking type did you use? (For example: nova-network, Neutron with OpenVSwitch, ...) N/A Logs & Configs == N/A To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1869182/+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 1869184] [NEW] Poor LUKSv1 performance when using native QEMU decryption and RBD volumes
Public bug reported: Description === This bug specifically covers the RBD use case when dealing with bug #1869182. In addition to allowing operators to switch to the os-brick encryptors when decrypting LUKSv1 volumes RBD users will also need to use the RBD connector also provided by os-brick. This will connect the RBD volume to the host and provide it as a host block device, allowing the os-brick encryptors to be layered on top of it as with other volume types. Steps to reproduce == * Attach a LUKSv1 RBD encrypted volume to an instance * Test I/O performance within the instance to the volume. Expected result === Performance is close to baremetal performance using dm-crypt. Actual result = Performance is severely degraded if the libgcrypt issue [1] is not resolved on the host. Environment === 1. Exact version of OpenStack you are running. See the following list for all releases: http://docs.openstack.org/releases/ Master. 2. Which hypervisor did you use? (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...) What's the version of that? libvirt + QEMU/KVM 2. Which storage type did you use? (For example: Ceph, LVM, GPFS, ...) What's the version of that? RBD - LUKSv1 encryption used. 3. Which networking type did you use? (For example: nova-network, Neutron with OpenVSwitch, ...) N/A Logs & Configs == N/A ** Affects: nova Importance: High Status: New ** Changed in: nova Importance: Undecided => High -- 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/1869184 Title: Poor LUKSv1 performance when using native QEMU decryption and RBD volumes Status in OpenStack Compute (nova): New Bug description: Description === This bug specifically covers the RBD use case when dealing with bug #1869182. In addition to allowing operators to switch to the os-brick encryptors when decrypting LUKSv1 volumes RBD users will also need to use the RBD connector also provided by os-brick. This will connect the RBD volume to the host and provide it as a host block device, allowing the os-brick encryptors to be layered on top of it as with other volume types. Steps to reproduce == * Attach a LUKSv1 RBD encrypted volume to an instance * Test I/O performance within the instance to the volume. Expected result === Performance is close to baremetal performance using dm-crypt. Actual result = Performance is severely degraded if the libgcrypt issue [1] is not resolved on the host. Environment === 1. Exact version of OpenStack you are running. See the following list for all releases: http://docs.openstack.org/releases/ Master. 2. Which hypervisor did you use? (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...) What's the version of that? libvirt + QEMU/KVM 2. Which storage type did you use? (For example: Ceph, LVM, GPFS, ...) What's the version of that? RBD - LUKSv1 encryption used. 3. Which networking type did you use? (For example: nova-network, Neutron with OpenVSwitch, ...) N/A Logs & Configs == N/A To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1869184/+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 1864588] Re: Cpu model is not correct on Aarch64/Qemu/Custom mode
Reviewed: https://review.opendev.org/709494 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=5d4f82a15c7bccc89f78a5a1f00a25cfafdbdde0 Submitter: Zuul Branch:master commit 5d4f82a15c7bccc89f78a5a1f00a25cfafdbdde0 Author: Kevin Zhao Date: Mon Mar 16 10:41:05 2020 +0800 Add default cpu model for AArch64 Unlike x86, AArch64 doesn't have a default model. Usually when using libvirt driver, set cpu mode to custom, nova will call libvirt to return the default models. But for aarch64, the support CPU models varies according to machine type. AArch64 use "virt" as the default machine type. In Qemu it support several models, and we should choose "max" as the by default one. Closes-Bug: #1864588 Change-Id: Ib2df50bda991a659fe10ef1dd9e7ab56800c34fb Signed-off-by: Kevin Zhao ** Changed in: nova Status: In Progress => 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/1864588 Title: Cpu model is not correct on Aarch64/Qemu/Custom mode Status in OpenStack Compute (nova): Fix Released Bug description: Background: We'd like to setup Nova and Devstack Upstream CI. Should support launch vm via Qemu virt_type. But host-passthrough mode(default in Aarch64) doesn't work on Qemu. So we can just use "custom" and specify CPU-model. But actually Aarch64 don't return available cpu models list from Libvirt side. Ref:https://libvirt.org/html/libvirt-libvirt- host.html#virConnectGetCPUModelNames So we should use the specified ones from config file. And add default ones to it on Aarch64. Nova-cpu.conf: [libvirt] live_migration_uri = qemu+ssh://stack@%s/system cpu_mode = custom virt_type = qemu cpu_model = cortex-a57 WARNING nova.virt.libvirt.driver [-] The libvirt driver is not tested on qemu/aarch64 by the OpenStack project and thus its quality can not be ensured. For more information, see: https://docs.openstack.org/nova/latest/user/support-matrix.html WARNING nova.virt.libvirt.driver [-] Running Nova with a libvirt version less than 5.0.0 is deprecated. The required minimum version of libvirt will be raised to 5.0.0 in the next release. WARNING nova.virt.libvirt.driver [-] Running Nova with a QEMU version less than 4.0.0 is deprecated. The required minimum version of QEMU will be raised to 4.0.0 in the next release. ERROR oslo_service.service [-] Error starting thread.: nova.exception.InvalidCPUInfo: Configured CPU model: cortex-a57 is not correct, or your host CPU arch does not suuport this model. Please correct your config and try again. ERROR oslo_service.service Traceback (most recent call last): ERROR oslo_service.service File "/usr/local/lib/python3.6/dist-packages/oslo_service/service.py", line 810, in run_service ERROR oslo_service.service service.start() ERROR oslo_service.service File "/opt/stack/nova/nova/service.py", line 158, in start ERROR oslo_service.service self.manager.init_host() ERROR oslo_service.service File "/opt/stack/nova/nova/compute/manager.py", line 1394, in init_host ERROR oslo_service.service self.driver.init_host(host=self.host) ERROR oslo_service.service File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 715, in init_host ERROR oslo_service.service self._check_cpu_compatibility() ERROR oslo_service.service File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 747, in _check_cpu_compatibility ERROR oslo_service.service raise exception.InvalidCPUInfo(msg) ERROR oslo_service.service nova.exception.InvalidCPUInfo: Configured CPU model: cortex-a57 is not correct, or your host CPU arch does not suuport this model. Please correct your config and try again. ERROR oslo_service.service To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1864588/+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 1640442] Re: glance image-tag-update, not updating a tag whose length is more than 255
** Changed in: glance
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1640442
Title:
glance image-tag-update, not updating a tag whose length is more than
255
Status in Glance:
Invalid
Bug description:
The command "glance image-tag-update " will
update the tag to the give . If the length of the
is more than 255 , it won't update the tag and throws the
below error:
"400 Bad Request: Provided object does not match schema 'image':
u'123niteshgjkdhgjfdghfdjghfdjkghjfdghsdjfghjsdfghfdjghfdjghfdjghsdfgjkshdkjsfhdgljksfdghfsdkjghfdsjkdkghdsfjghdfjkhgjkdfghjkdfghjsdfkghfdjkghdfjkghsdfkjghsdfgkljsfhdgsjkdfghfsdjkghsddjskfndjighfnidughndfjgkhfndjkbhfdnbujfhdnbuidfsdsafsfsdfsdfdsfsdfdsdfdfffsdfsdfdsfsdf'
is too long: Failed validating 'maxLength' in
schema['properties']['tags']['items']:: {'maxLength': 255, 'type':
'string'}: On instance['tags'][0]::
u'123niteshgjkdhgjfdghfdjghfdjkghjfdghsdjfghjsdfghfdjghfdjghfdjghsdfgjkshdkjsfhdgljksfdghfsdkjghfdsjkdkghdsfjghdfjkhgjkdfghjkdfghjsdfkghfdjkghdfjkghsdfkjghsdfgkljsfhdgsjkdfghfsdjkghsddjskfndjighfnidughndfjgkhfndjkbhfdnbujfhdnbuidfsdsafsfsdfsdfdsfsdfdsdfdfffsdfsdfdsfsdf'
(HTTP 400)"
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1640442/+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 1716868] Re: config file is not read
** Also affects: cloud-archive Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1716868 Title: config file is not read Status in Ubuntu Cloud Archive: New Status in OpenStack Dashboard (Horizon): Invalid Bug description: we are running horizon on an Ubuntu 16 cluster with the official repos for the new pike release and figured out that the configuration file /etc/openstack-dashboard/local_settings.py is no longer read. it seems the symlink /usr/share/openstack- dashboard/openstack_dashboard/local/local_settings.py is no longer working. we removed that symlink and copied the file directly into /usr/share/openstack-dashboard/openstack_dashboard/local/ which seems to help for the moment. installed package: python-django-horizon - 3:12.0.0-0ubuntu1~cloud0 OS: Ubuntu 16.04.3 LTS apache virtual host config: http://paste.openstack.org/show/621008/ file permissions: -rw-r--r-- 1 root horizon 34573 Sep 13 10:01 /etc/openstack-dashboard/local_settings.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1716868/+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
