[Yahoo-eng-team] [Bug 1825018] Re: security group driver gets loaded way too much in the api
Reviewed: https://review.opendev.org/697122 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=0461921d9e5313c3e92b039b90f713ed961e20c8 Submitter: Zuul Branch:master commit 0461921d9e5313c3e92b039b90f713ed961e20c8 Author: Matt Riedemann Date: Tue Dec 3 10:54:29 2019 -0500 Cache security group driver Change I0932c652fb455fe10239215a93e183ea947234e3 from Mitaka was a performance improvement to cache the loaded security group driver since the API calls get_openstack_security_group_driver a lot. That performance fix was regressed with change Ia4a8d9954bf456253101b936f8b4ff513aaa73b2 in Newton. This caches the loaded security group driver once again. This is pretty similar to the original change except simpler since we don't have to account for the skip_policy_check flag. Change-Id: Icacc763f19db6dc90e72af32e17d480775ad5edf Closes-Bug: #1825018 ** 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/1825018 Title: security group driver gets loaded way too much in the api Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) ocata series: Confirmed Status in OpenStack Compute (nova) pike series: Confirmed Status in OpenStack Compute (nova) queens series: Confirmed Status in OpenStack Compute (nova) rocky series: Confirmed Status in OpenStack Compute (nova) stein series: Confirmed Status in OpenStack Compute (nova) train series: Confirmed Bug description: There was a fix in Mitaka https://review.openstack.org/#/c/256073/ to cache the security group driver once it was loaded per process. That cache was removed in Newton https://review.openstack.org/#/c/325684/. I put up a test patch to see how many times the security group driver gets loaded https://review.openstack.org/#/c/652783/ and in the neutron-grenade-multinode job the nova-api logs show it getting loaded over 1000 times (browser count hit tops out at 1000). So the fix from mitaka was definitely regressed in newton and we should add the driver cache code again. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1825018/+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 1850818] Re: [RFE][floatingip port_forwarding] Add description field
Reviewed: https://review.opendev.org/692580
Committed:
https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=a37378e8d50e074667a55784758790b2929d75a6
Submitter: Zuul
Branch:master
commit a37378e8d50e074667a55784758790b2929d75a6
Author: pedro
Date: Thu Oct 31 17:09:14 2019 -0300
Add description field in port forwarding API
Problem Description
===
As users create and update theirs floating ip rules, the reason
behind those rules might get lost throughout time. Moreover, in
an environment with many people writing rules, it is important
to track down the reason behind each one of the rules
created/added in a floating IP port forwarding configuration.
The addition of a description field would allow operators to
determine the reason why a rule was created and help the users
to know if the existence of a rule is still reasonable.
Proposed Change
===
To address the described scenario, we propose to create a new
“description” field in the Neutron’s Floating IP port forwarding
rules API JSON. This new field will be a nullable String
containing the description/reason why this new port forwarding
rule is being created.
Change-Id: If98a70011b187d2143a660f1f281ab197d21eb4d
Implements: blueprint portforwarding-description
Closes-Bug: #1850818
** 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/1850818
Title:
[RFE][floatingip port_forwarding] Add description field
Status in neutron:
Fix Released
Bug description:
Problem Description
===
As users create and update theirs floating ip rules, the reason
behind those rules might get lost throughout time. Moreover, in
an environment with many people writing rules, it is important
to track down the reason behind each one of the rules
created/added in a floating IP port forwarding configuration.
The addition of a description field would allow operators to
determine the reason why a rule was created and help the users
to know if the existence of a rule is still reasonable.
Proposed Change
===
To address the described scenario, we propose to create a new
“description” field in the Neutron’s Floating IP port forwarding
rules API JSON. This new field will be a nullable String
containing the description/reason why this new port forwarding
rule is being created.
Example of a modified JSON:
{
"port_forwarding":{
"protocol":"tcp",
"internal_ip_address":"172.16.0.7",
"internal_port":2230,
"internal_port_id":"b67a7746-dc69-45b4-9b84-bb229fe198a0",
"external_port":2230,
"description":"Some description"
}
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1850818/+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 1855196] [NEW] RBXCloud has no dsname defined, so datasource cannot be properly detected.
Public bug reported: Each cloud-init datasource needs to define a dsname property. This property affects the instance-data.json platform_type presented for an instance (via cloud-init query --all) without this defined, cloud- init query will not properly identify this platform and the cloud may not be able to get selected via dpkg-reconfigure. ** 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/1855196 Title: RBXCloud has no dsname defined, so datasource cannot be properly detected. Status in cloud-init: New Bug description: Each cloud-init datasource needs to define a dsname property. This property affects the instance-data.json platform_type presented for an instance (via cloud-init query --all) without this defined, cloud-init query will not properly identify this platform and the cloud may not be able to get selected via dpkg-reconfigure. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1855196/+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 1855190] Re: Improve test and CI coverage for Cinder backend in Glance
I think this more applicable to glance than cinder, but we can leave it on here until we know for sure that there isn't anything we need to change on the cinder side to support this. ** Also affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1855190 Title: Improve test and CI coverage for Cinder backend in Glance Status in Cinder: New Status in Glance: New Bug description: These functionalities are often broken as they also aren't tested in Tempest yet. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1855190/+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 1855170] [NEW] system_info can change the distro
Public bug reported: In triaging https://bugs.launchpad.net/cloud-init/+bug/1854594 i found that system_info can actively change which distro class is picked: system_info: default_user: lock_passwd: true name: root shell: /bin/bash distro: ubuntu will use distro/__init__.py's create_user() and hence lock_passwd() methods! If this is a feature, it should be documented. If this is a bug, it needs fixing. ** 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/1855170 Title: system_info can change the distro Status in cloud-init: New Bug description: In triaging https://bugs.launchpad.net/cloud-init/+bug/1854594 i found that system_info can actively change which distro class is picked: system_info: default_user: lock_passwd: true name: root shell: /bin/bash distro: ubuntu will use distro/__init__.py's create_user() and hence lock_passwd() methods! If this is a feature, it should be documented. If this is a bug, it needs fixing. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1855170/+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 1854950] Re: VM spice console not clear
Thanks Kumar for investigating the issue further and identifying that
the issue is with certain images and not with nova itself. Closing this
bug accordingly based on your findings. Thanks again!
** Changed in: nova
Status: New => Invalid
--
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/1854950
Title:
VM spice console not clear
Status in OpenStack Compute (nova):
Invalid
Bug description:
Hi,
We have openstack ansible rocky 18.1.9 setup and when a user is trying
to access a vm console from web browser, they are not able to send
keystrokes properly. When for example, pressing ENTER key, the display
is broken into number of lines and not clear what they are typing in.
In the nova-spice-console logs, we are observing these messages
frequently:
2019-12-03 09:16:01.278 37844 INFO nova.console.websocketproxy [-] handler
exception: [Errno 32] Broken pipe
2019-12-03 09:16:01.279 37844 DEBUG nova.console.websocketproxy [-] exception
vmsg
/openstack/venvs/nova-18.1.9/lib/python2.7/site-packages/websockify/websocket.py:875
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy Traceback
(most recent call last):
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy File
"/openstack/venvs/nova-18.1.9/lib/python2.7/site-packages/websockify/websocket.py",
line 930, in top_new_client
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy client =
self.do_handshake(startsock, address)
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy File
"/openstack/venvs/nova-18.1.9/lib/python2.7/site-packages/websockify/websocket.py",
line 860, in do_handshake
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy
self.RequestHandlerClass(retsock, address, self)
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy File
"/openstack/venvs/nova-18.1.9/lib/python2.7/site-packages/nova/console/websocketproxy.py",
line 308, in __init__
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy
websockify.ProxyRequestHandler.__init__(self, *args, **kwargs)
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy File
"/openstack/venvs/nova-18.1.9/lib/python2.7/site-packages/websockify/websocket.py",
line 114, in __init__
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy
SimpleHTTPRequestHandler.__init__(self, req, addr, server)
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy File
"/usr/lib/python2.7/SocketServer.py", line 652, in __init__
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy
self.handle()
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy File
"/openstack/venvs/nova-18.1.9/lib/python2.7/site-packages/websockify/websocket.py",
line 581, in handle
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy
SimpleHTTPRequestHandler.handle(self)
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy File
"/usr/lib/python2.7/BaseHTTPServer.py", line 340, in handle
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy
self.handle_one_request()
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy File
"/usr/lib/python2.7/BaseHTTPServer.py", line 328, in handle_one_request
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy method()
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy File
"/openstack/venvs/nova-18.1.9/lib/python2.7/site-packages/websockify/websocket.py",
line 567, in do_HEAD
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy
SimpleHTTPRequestHandler.do_HEAD(self)
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy File
"/usr/lib/python2.7/SimpleHTTPServer.py", line 54, in do_HEAD
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy f =
self.send_head()
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy File
"/usr/lib/python2.7/SimpleHTTPServer.py", line 103, in send_head
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy
self.send_header("Last-Modified", self.date_time_string(fs.st_mtime))
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy File
"/usr/lib/python2.7/BaseHTTPServer.py", line 412, in send_header
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy
self.wfile.write("%s: %s\r\n" % (keyword, value))
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy File
"/usr/lib/python2.7/socket.py", line 328, in write
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy
self.flush()
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy File
"/usr/lib/python2.7/socket.py", line 307, in flush
2019-12-03 09:16:01.279 37844 ERROR nova.console.websocketproxy
[Yahoo-eng-team] [Bug 1854993] Re: QoS bandwidth tempest test no longer running
Reviewed: https://review.opendev.org/697180 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=f347839151a78f9fbc70c79f017fb0e96438465c Submitter: Zuul Branch:master commit f347839151a78f9fbc70c79f017fb0e96438465c Author: Eric Fried Date: Tue Dec 3 14:09:38 2019 -0600 Add QoS tempest config so bw tests run In [1] the tempest-slow-py3 job was dropped and non-redundant bits folded into the nova-next job. Except we forgot to move over some of the config necessary to make this QoS bandwidth test [2] work, so it gets skipped: setUpClass (tempest.scenario.test_minbw_allocation_placement.MinBwAllocationPlacementTest) ... SKIPPED: Skipped as no physnet is available in config for placement based QoS allocation. This syncs the nova-next job with the config like what was done for tempest-slow here [3]. Some of that was already in place (to make QoS heal allocation testing work). [1] https://review.opendev.org/#/c/683988/ [2] https://github.com/openstack/tempest/blob/3eb3c29e979fd3f13c205d62119748952d63054a/tempest/scenario/test_minbw_allocation_placement.py#L142 [3] https://github.com/openstack/tempest/commit/c87a06b3c29427dc8f2513047c804e0410b4b99c Closes-Bug: #1854993 Change-Id: Ib9332b8677c4ccb9e38b6fcdf39e989a891a56fe ** 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/1854993 Title: QoS bandwidth tempest test no longer running Status in OpenStack Compute (nova): Fix Released Bug description: In [1] the tempest-slow-py3 job was dropped and non-redundant bits folded into the nova-next job. Except we forgot to move over some of the config necessary to make this QoS bandwidth test [2] work, so it gets skipped: setUpClass (tempest.scenario.test_minbw_allocation_placement.MinBwAllocationPlacementTest) ... SKIPPED: Skipped as no physnet is available in config for placement based QoS allocation. We think we just need to get the nova-next job synced up with the config like what was done for tempest-slow here [3]. [1] https://review.opendev.org/#/c/683988/ [2] https://github.com/openstack/tempest/blob/3eb3c29e979fd3f13c205d62119748952d63054a/tempest/scenario/test_minbw_allocation_placement.py#L142 [3] https://github.com/openstack/tempest/commit/c87a06b3c29427dc8f2513047c804e0410b4b99c To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1854993/+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 1855123] [NEW] Neutron ovs agent still fails vlan transparency check
Public bug reported: OVS has been supporting vlan transparency for a while (since 2.8), see belo http://www.openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.txt other_config : vlan-limit: optional string, containing an integer, at least 0 Limits the number of VLAN headers that can be matched to the specified number. Further VLAN headers will be treated as pay‐ load, e.g. a packet with more 802.1q headers will match Ethernet type 0x8100. Open vSwitch userspace currently supports at most 2 VLANs, and each datapath has its own limit. If vlan-limit is nonzero, it acts as a further limit. If this value is absent, the default is currently 1. This main‐ tains backward compatibility with controllers that were designed for use with Open vSwitch versions earlier than 2.8, which only supported one VLAN. But Neutron ovs agent still blindly fails the driver capability check, this prevents the OVS feature being used. def check_vlan_transparency(self, context): """Currently Openvswitch driver doesn't support vlan transparency.""" return False ** 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/1855123 Title: Neutron ovs agent still fails vlan transparency check Status in neutron: New Bug description: OVS has been supporting vlan transparency for a while (since 2.8), see belo http://www.openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.txt other_config : vlan-limit: optional string, containing an integer, at least 0 Limits the number of VLAN headers that can be matched to the specified number. Further VLAN headers will be treated as pay‐ load, e.g. a packet with more 802.1q headers will match Ethernet type 0x8100. Open vSwitch userspace currently supports at most 2 VLANs, and each datapath has its own limit. If vlan-limit is nonzero, it acts as a further limit. If this value is absent, the default is currently 1. This main‐ tains backward compatibility with controllers that were designed for use with Open vSwitch versions earlier than 2.8, which only supported one VLAN. But Neutron ovs agent still blindly fails the driver capability check, this prevents the OVS feature being used. def check_vlan_transparency(self, context): """Currently Openvswitch driver doesn't support vlan transparency.""" return False To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1855123/+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 1855124] [NEW] Neutron ovs agent still fails vlan transparency check
Public bug reported: OVS has been supporting vlan transparency for a while (since 2.8), see belo http://www.openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.txt other_config : vlan-limit: optional string, containing an integer, at least 0 Limits the number of VLAN headers that can be matched to the specified number. Further VLAN headers will be treated as pay‐ load, e.g. a packet with more 802.1q headers will match Ethernet type 0x8100. Open vSwitch userspace currently supports at most 2 VLANs, and each datapath has its own limit. If vlan-limit is nonzero, it acts as a further limit. If this value is absent, the default is currently 1. This main‐ tains backward compatibility with controllers that were designed for use with Open vSwitch versions earlier than 2.8, which only supported one VLAN. But Neutron ovs agent still blindly fails the driver capability check, this prevents the OVS feature being used. def check_vlan_transparency(self, context): """Currently Openvswitch driver doesn't support vlan transparency.""" return False ** 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/1855124 Title: Neutron ovs agent still fails vlan transparency check Status in neutron: New Bug description: OVS has been supporting vlan transparency for a while (since 2.8), see belo http://www.openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.txt other_config : vlan-limit: optional string, containing an integer, at least 0 Limits the number of VLAN headers that can be matched to the specified number. Further VLAN headers will be treated as pay‐ load, e.g. a packet with more 802.1q headers will match Ethernet type 0x8100. Open vSwitch userspace currently supports at most 2 VLANs, and each datapath has its own limit. If vlan-limit is nonzero, it acts as a further limit. If this value is absent, the default is currently 1. This main‐ tains backward compatibility with controllers that were designed for use with Open vSwitch versions earlier than 2.8, which only supported one VLAN. But Neutron ovs agent still blindly fails the driver capability check, this prevents the OVS feature being used. def check_vlan_transparency(self, context): """Currently Openvswitch driver doesn't support vlan transparency.""" return False To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1855124/+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 1855015] Re: Intermittent fails in nova-next job with "Multiple possible networks found, use a Network ID to be more specific."
*** This bug is a duplicate of bug 1844568 *** https://bugs.launchpad.net/bugs/1844568 I clearly don't know how to make logstash links properly, but I had that query open for the past 10 days and saw hits on many different jobs across multiple projects, including sdk, cinder, and various networking-*s. The largest proportion of hits were in nova & neutron though (possibly simply due to volume of patches in those projects). Anyway, I talked to -neutron and they've identified [1] as a probable dup, so I'll mark this as such. [1] https://launchpad.net/bugs/1844568 ** Changed in: nova Status: Invalid => New ** This bug has been marked a duplicate of bug 1844568 [compute] "create_test_server" if networks is undefined and more than one network is present -- 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/1855015 Title: Intermittent fails in nova-next job with "Multiple possible networks found, use a Network ID to be more specific." Status in OpenStack Compute (nova): New Bug description: There was something similar before [1] but it was 100% and in one job. This is intermittent and in multiple jobs across multiple projects. http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22Multiple%20possible%20networks%20found,%20use%20a%20Network%20ID%20to%20be%20more%20specific%5C%22 [1] https://bugs.launchpad.net/nova/+bug/1822605 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1855015/+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 1855015] Re: Intermittent fails in nova-next job with "Multiple possible networks found, use a Network ID to be more specific."
*** This bug is a duplicate of bug 1844568 ***
https://bugs.launchpad.net/bugs/1844568
It looks like that tempest test is actually expecting the error:
https://opendev.org/openstack/tempest/src/branch/master/tempest/api/compute/servers/test_attach_interfaces.py#L236
try:
iface = self._test_create_interface(server)
except lib_exc.BadRequest as e:
msg = ('Multiple possible networks found, use a Network ID to be '
'more specific.')
if not CONF.compute.fixed_network_name and six.text_type(e) == msg:
raise
else:
ifs.append(iface)
** Changed in: nova
Status: New => Invalid
--
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/1855015
Title:
Intermittent fails in nova-next job with "Multiple possible networks
found, use a Network ID to be more specific."
Status in OpenStack Compute (nova):
New
Bug description:
There was something similar before [1] but it was 100% and in one job.
This is intermittent and in multiple jobs across multiple projects.
http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22Multiple%20possible%20networks%20found,%20use%20a%20Network%20ID%20to%20be%20more%20specific%5C%22
[1] https://bugs.launchpad.net/nova/+bug/1822605
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1855015/+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 1855015] Re: Intermittent fails since 11/23 with "Multiple possible networks found, use a Network ID to be more specific."
*** This bug is a duplicate of bug 1844568 *** https://bugs.launchpad.net/bugs/1844568 Based on that query I guess you're specifically looking at the nova-next job, right? It looks like the most fails on that are from this series starting with https://review.opendev.org/#/c/697180/. Having said that, this is also hitting in the gate queue. Note that the 11/23 in the bug title is misleading since logstash only goes back 10 days for us so you're just seeing where it falls off. ** Summary changed: - Intermittent fails since 11/23 with "Multiple possible networks found, use a Network ID to be more specific." + Intermittent fails in nova-next job with "Multiple possible networks found, use a Network ID to be more specific." ** No longer affects: neutron -- 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/1855015 Title: Intermittent fails in nova-next job with "Multiple possible networks found, use a Network ID to be more specific." Status in OpenStack Compute (nova): New Bug description: There was something similar before [1] but it was 100% and in one job. This is intermittent and in multiple jobs across multiple projects. http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22Multiple%20possible%20networks%20found,%20use%20a%20Network%20ID%20to%20be%20more%20specific%5C%22 [1] https://bugs.launchpad.net/nova/+bug/1822605 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1855015/+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 1833267] Re: Horizon doesn't show images for instances created from volume=true
Reviewed: https://review.opendev.org/694102 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=5de6df19dc7989312e5916bfd840a4f5f917308d Submitter: Zuul Branch:master commit 5de6df19dc7989312e5916bfd840a4f5f917308d Author: Tatiana Ovchinnikova Date: Wed Nov 13 14:09:24 2019 +0100 Add image data for instance with volume If an instance was created with a volume from an image, there is no image details in instance overview page. This patch adds image info from volume image-metadata. Change-Id: I1da69eb4a65ab13f77d610b870bada994de876f2 Closes-Bug: 1833267 ** Changed in: horizon Status: In Progress => Fix Released -- 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/1833267 Title: Horizon doesn't show images for instances created from volume=true Status in OpenStack Dashboard (Horizon): Fix Released Bug description: In the Project > Compute > Instances table, if an instance was created with a volume from an image, no image is listed. This information could be pulled from the root volume's image-metadata To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1833267/+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
