[Yahoo-eng-team] [Bug 1842517] Re: neutron-sanity-check command fails if netdev datapath is used
Reviewed: https://review.opendev.org/c/openstack/neutron/+/679808
Committed:
https://opendev.org/openstack/neutron/commit/02030f037ad754b9b8ba3f3a657022d66c32c71e
Submitter: "Zuul (22348)"
Branch:master
commit 02030f037ad754b9b8ba3f3a657022d66c32c71e
Author: Deepak Tiwari
Date: Tue Sep 3 10:18:28 2019 -0500
ovs-dpdk support in neutron-sanity-check
While creating bridges, pass the optional argument 'datapath_type'.
This parameter is read from openvswitch.ini conf file.
Closes-Bug: #1842517
Change-Id: I05f0484636e4da6290c750a1eabd5f9d09588008
** 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/1842517
Title:
neutron-sanity-check command fails if netdev datapath is used
Status in neutron:
Fix Released
Bug description:
If ovs-dpdk is being used, in containerized openstack deployment,
restarting the neutron pods sometimes leads to neutron-sanity-check
command getting failed. This script tries to create several bridges
but with 'system' datapath_type. Even though 'netdev' datapath_type
bridges were already created by core neutron_ovs_agent process.
steps:
--
1. Deploy ovs-dpdk in a containerized environment (using openstack-helm for
ex.)
2. Deploy neutron pods
3. First time neutron-ovs-agent pods shall come up fine (and it shall create
ovs bridges with netdev datapath_type)
4. Then restart neutron pods multiple times unless following issue is observed
5. The init containers shall run neutron-sanity-check which tries to create
ovs bridges with 'system' datapath_type which fails randomly
Logs:
--
+ OVS_SOCKET=/run/openvswitch/db.sock
+ chown neutron: /run/openvswitch/db.sock
+ DPDK_CONFIG_FILE=/tmp/dpdk.conf
+ DPDK_CONFIG=
+ '[' '!' -f /tmp/dpdk.conf ']'
++ cat /tmp/dpdk.conf
+
DPDK_CONFIG='{"bonds":[{"bridge":"br-phy-bond0","migrate_ip":false,"mtu":9000,"n_rxq":4,"n_rxq_size":1024,"n_txq_size":1024,"name":"dpdkbond0","nics":[{"name":"dpdk_b0s0","pci_id":":5e:00.0","vf_index":0},{"name":"dpdk_b0s1","pci_id":":87:00.1","vf_index":0}],"ovs_options":"bond_mode=active-backup"}],"bridges":[{"name":"br-phy-bond0"}],"driver":"vfio-pci","enabled":true,"nics":[]}'
+ neutron-sanity-check --version
+ timeout 3m neutron-sanity-check --config-file /etc/neutron/neutron.conf
--config-file /etc/neutron/plugins/ml2/openvswitch_agent.ini --ovsdb_native
--nokeepalived_ipv6_support
Guru meditation now registers SIGUSR1 and SIGUSR2 by default for backward
compatibility. SIGUSR1 will no longer be registered in a future release, so
please use SIGUSR2 to generate reports.
2019-08-31 04:07:15.696 1161 INFO neutron.common.config [-] Logging enabled!
2019-08-31 04:07:15.696 1161 INFO neutron.common.config [-]
/var/lib/openstack/bin/neutron-sanity-check version 10.0.8.dev105
2019-08-31 04:07:16.572 1161 INFO neutron.agent.ovsdb.native.vlog [-]
tcp:127.0.0.1:6640: connecting...
2019-08-31 04:07:16.572 1161 INFO neutron.agent.ovsdb.native.vlog [-]
tcp:127.0.0.1:6640: connected
2019-08-31 04:07:26.612 1161 CRITICAL neutron [-] TimeoutException: Commands
[AddBridgeCommand(datapath_type=system, may_exist=True, name=patchtest-4e35d),
DbAddCommand(column=protocols, record=patchtest-4e35d, values=('OpenFlow10',),
table=Bridge), DbSetCommand(table=Bridge, col_values=(('other_config',
{'mac-table-size': '5'}),), record=patchtest-4e35d)] exceeded timeout 10
seconds
2019-08-31 04:07:26.612 1161 ERROR neutron Traceback (most recent call last):
2019-08-31 04:07:26.612 1161 ERROR neutron File
"/var/lib/openstack/bin/neutron-sanity-check", line 10, in
2019-08-31 04:07:26.612 1161 ERROR neutron sys.exit(main())
2019-08-31 04:07:26.612 1161 ERROR neutron File
"/var/lib/openstack/local/lib/python2.7/site-packages/neutron/cmd/sanity_check.py",
line 394, in main
2019-08-31 04:07:26.612 1161 ERROR neutron return 0 if all_tests_passed()
else 1
2019-08-31 04:07:26.612 1161 ERROR neutron File
"/var/lib/openstack/local/lib/python2.7/site-packages/neutron/cmd/sanity_check.py",
line 381, in all_tests_passed
2019-08-31 04:07:26.612 1161 ERROR neutron return all(opt.callback() for
opt in OPTS if cfg.CONF.get(opt.name))
2019-08-31 04:07:26.612 1161 ERROR neutron File
"/var/lib/openstack/local/lib/python2.7/site-packages/neutron/cmd/sanity_check.py",
line 381, in
2019-08-31 04:07:26.612 1161 ERROR neutron return all(opt.callback() for
opt in OPTS if cfg.CONF.get(opt.name))
2019-08-31 04:07:26.612 1161 ERROR neutron File
"/var/lib/openstack/local/lib/python2.7/site-packages/neutron/cmd/sanity_check.py",
line 79, in check_ovs_patch
2019-08-31 04:07:26.612 1161 ERROR neutron result =
checks.patch_supported()
2019-08-31 04:07:26.612 1161 ERROR neutron File
"/var/lib/openstack/local/lib/
[Yahoo-eng-team] [Bug 1616713] Re: neutron provider network type shouldn't include "vxlan" and "gre"
** Changed in: neutron Status: In Progress => 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/1616713 Title: neutron provider network type shouldn't include "vxlan" and "gre" Status in neutron: Invalid Bug description: I think there is a mistake on "Networking API v2.0" document at http://developer.openstack.org/api-ref/networking/v2/?expanded=update-network-provider-network-detail. The api points that "provider:network_type" is the type of physical network that maps to this network resource. For example, flat, vlan, vxlan, or gre. But "vxlan" and "gre" network types are both overlay network types, they should not be included in provider network types. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1616713/+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 1613542] Re: tempest.conf doesn't contain $project in [service_available] section
Just like keystone, the network service is always set to True in tempest
(tempest/common/utils/__init__.py), so I'll mark this invalid for
neutron. Please create a new bug if/when this ever needs to change in
tempest and we can make an appropriate change in neutron.
** Changed in: neutron
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1613542
Title:
tempest.conf doesn't contain $project in [service_available] section
Status in Aodh:
Fix Released
Status in Ceilometer:
Fix Released
Status in ec2-api:
Fix Released
Status in Gnocchi:
Fix Released
Status in Ironic:
Fix Released
Status in Ironic Inspector:
Fix Released
Status in OpenStack Identity (keystone):
Invalid
Status in Magnum:
Fix Released
Status in neutron:
Invalid
Status in OpenStack Data Processing ("Sahara") sahara-tests:
Fix Released
Status in senlin:
Invalid
Status in vmware-nsx:
Fix Released
Bug description:
When generating the tempest conf, the tempest plugins need to register the
config options.
But for the [service_available] section, ceilometer (and the other mentioned
projects) doesn't register any value so it's missng in the tempest sample
config.
Steps to reproduce:
$ tox -egenconfig
$ source .tox/genconfig/bin/activate
$ oslo-config-generator --config-file
.tox/genconfig/lib/python2.7/site-packages/tempest/cmd/config-generator.tempest.conf
--output-file tempest.conf.sample
Now check the [service_available] section from tempest.conf.sample
To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1613542/+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 1586208] Re: Scenario: Provider networks with Linux bridge in Networking Guide
** Changed in: neutron Status: Confirmed => 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/1586208 Title: Scenario: Provider networks with Linux bridge in Networking Guide Status in neutron: Fix Released Status in openstack-manuals: Won't Fix Bug description: Not so much a bug than feedback. The page is not clear whether each node has a single Linux Bridge or several. Somebody with good networking skills might consider this common knowledge, but if you are not that versed in the field of datacenter networking (I am certainly not), you may be a bit lost. At some point, the page talks about the Linux Bridge Agent managing "switches" (plural; and why "switches" and not "bridges"?), but elsewhere there is only talk about one bridge named qbr (and sometimes brq. Better name it consistently!). I suggest the following change: - make it clear that there is one bridge per provider network, not a single bridge per compute and control node. Or am I wrong? (see, I am confused!) And these minor changes: - label the bridges consistently - if you call Linux Bridges "switches", explain why --- Release: 0.9 on 2016-05-25 13:08 SHA: 0671dca2730c636eaaca64f3880513bf7242e4b4 Source: http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/networking-guide/source/scenario-provider-lb.rst URL: http://docs.openstack.org/mitaka/networking-guide/scenario-provider-lb.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1586208/+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 1586213] Re: Scenario: Provider networks with Linux bridge in Networking Guide
** Changed in: neutron Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1586213 Title: Scenario: Provider networks with Linux bridge in Networking Guide Status in neutron: Won't Fix Status in openstack-manuals: Won't Fix Bug description: The use cases in the first part of the page present several provider networks plus an external network. The external network has IP addresses in the 203 range, the other provider networks use the 192 range. Instances are connected to 192. addresses. On the other hand, the second part Example Configuration creates a single network, which is also external, and connects the instance to it. IP addresses are 203.. Architecture and Packet Flow are explained at considerable detail. It's a pity that the Example Configuration doesn't use the scenarios developed in the first part of the page. I suggest to show the configuration of one external and two provider networks using the same IP address ranges 203... and 192... . --- Release: 0.9 on 2016-05-25 13:08 SHA: 0671dca2730c636eaaca64f3880513bf7242e4b4 Source: http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/networking-guide/source/scenario-provider-lb.rst URL: http://docs.openstack.org/mitaka/networking-guide/scenario-provider-lb.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1586213/+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 1592345] Re: Import of tempest.test has side-effect that config is parsed
** 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/1592345
Title:
Import of tempest.test has side-effect that config is parsed
Status in neutron:
Invalid
Status in tempest:
Invalid
Bug description:
During implementation of tempest scenario for qos, it revealed that
calling
from tempest import test
has a side-effect. It replaces oslo config object with a proxy object.
Calling __getattr__ on this object has a side-effect of parsing the
config which makes config object no longer capable of registering new
CLI opts.
In [1]: from oslo_config import cfg
In [2]: from tempest import test
2016-06-14 10:21:46.063 7637 INFO tempest [-] Using tempest config file
/etc/tempest/tempest.conf
^[[A^[[A
In [3]: cfg.CONF.register_cli_opts([cfg.StrOpt('foo')])
---
ArgsAlreadyParsedErrorTraceback (most recent call last)
in ()
> 1 cfg.CONF.register_cli_opts([cfg.StrOpt('foo')])
/usr/lib/python2.7/site-packages/oslo_config/cfg.pyc in __inner(self, *args,
**kwargs)
2106 def __inner(self, *args, **kwargs):
2107 if kwargs.pop('clear_cache', True):
-> 2108 result = f(self, *args, **kwargs)
2109 self.__cache.clear()
2110 return result
/usr/lib/python2.7/site-packages/oslo_config/cfg.pyc in
register_cli_opts(self, opts, group)
2290 """Register multiple CLI option schemas at once."""
2291 for opt in opts:
-> 2292 self.register_cli_opt(opt, group, clear_cache=False)
2293
2294 def register_group(self, group):
/usr/lib/python2.7/site-packages/oslo_config/cfg.pyc in __inner(self, *args,
**kwargs)
2110 return result
2111 else:
-> 2112 return f(self, *args, **kwargs)
2113
2114 return __inner
/usr/lib/python2.7/site-packages/oslo_config/cfg.pyc in
register_cli_opt(self, opt, group)
2282 """
2283 if self._args is not None:
-> 2284 raise ArgsAlreadyParsedError("cannot register CLI option")
2285
2286 return self.register_opt(opt, group, cli=True,
clear_cache=False)
ArgsAlreadyParsedError: arguments already parsed: cannot register CLI
option
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1592345/+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 1266962] Re: Remove set_time_override in timeutils
** 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 OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1266962 Title: Remove set_time_override in timeutils Status in Ceilometer: Fix Released Status in Cinder: Fix Released Status in gantt: New Status in Glance: Fix Released Status in OpenStack Heat: Triaged Status in Ironic: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Shared File Systems Service (Manila): Fix Released Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Status in oslo.messaging: Fix Released Status in oslo.utils: Triaged Status in python-keystoneclient: Fix Released Status in python-novaclient: Fix Released Status in rack: In Progress Status in Sahara: Invalid Status in tuskar: Fix Released Status in zaqar: Fix Released Bug description: set_time_override was written as a helper function to mock utcnow in unittests. However we now use mock or fixture to mock our objects so set_time_override has become obsolete. We should first remove all usage of set_time_override from downstream projects before deleting it from oslo. List of attributes and functions to be removed from timeutils: * override_time * set_time_override() * clear_time_override() * advance_time_delta() * advance_time_seconds() To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1266962/+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 1877301] Re: [RFE] L3 Router support ndp proxy
I think it's done, anything else can be treated as a bug. ** 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/1877301 Title: [RFE] L3 Router support ndp proxy Status in neutron: Fix Released Bug description: As the ipv6 device more and more popularize, we should make our ipv6 VMs more easily connect to external network,but neutron don't support Floating IP and NAT for ipv6. The bgp-dynamic-routing is a optional way to make the ipv6 VMs accessed by external network. But the bgp configuration is more complex, it depend on the external physical router. So, I propose a eaiser way to make the ipv6 VMs accessed by external network: In openstack l3 router we set 'proxy_ndp' [1] kernal paramer as '1', like this: 'sysctl -w net.ipv6.conf.all.proxy_ndp=1', then we can add proxied address to gateway tap device, like this: 'ip -6 neigh add proxy 2001:400:1234:567:::8 dev qg-733bd76b-62'. In external router we just need to add a static direct route, like this: 'ip route add 2001:400:1234:567:::/80 dev fake-gw-port'. In this way, the external traffic can accurately forward to proper openstack router and then forward to specify VM. We can implement a plugin to support some APIs, these APIs should support add a single address proxy entry to router external gateway port, in order to that we can control advertise which address to external network. And the iptables can be used to break the trafffic immediately when user delete a address proxy entry. To guarantee the address is unique, the address scope should be considered. [1] https://www.geeklab.info/2013/05/ipv6-neighbour-proxy/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1877301/+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 1877447] Re: Add TCP/UDP port forwarding extension to OVN
** 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/1877447 Title: Add TCP/UDP port forwarding extension to OVN Status in neutron: Fix Released Bug description: Floating IP Port Forwarding needs to be implemented to ml2/OVN This is a functionality gap that currently exists between ml2/ovs and ml2/ovn, mentioned in [1]. Blueprint information is available here [2]. [1]: https://review.opendev.org/#/c/658414/19/specs/ussuri/ml2ovs-ovn-convergence.rst [2]: https://blueprints.launchpad.net/neutron/+spec/port-forwarding To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1877447/+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 1904436] Re: "gateway" option is not honored when creating a subnet with subnet pool
** Changed in: neutron Status: New => 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/1904436 Title: "gateway" option is not honored when creating a subnet with subnet pool Status in neutron: Fix Released Bug description: When a subnet is created using a subnet pool (--subnet-pool option), the option --gateway is not honored. According to [1][2], the gateway IP is read from the input parameters only when --subnet-range is provided (subnet['cidr']). It could be easy to, when a subnet pool is provided and a subnet range is selected, to check if the provided gateway IP belongs to this subnet range and assign it. NOTE: when using a subnet pool, the user can't decide the specific CIDR to be assigned to this subnet. If this feature is implemented, the server needs to check first if the GW IP provided falls into one of the available CIDRs (if this is possible or accepted by the community). [1]https://github.com/openstack/neutron/blob/40c501dcb158b1ab14137c94c60697e19a73c170/neutron/db/ipam_pluggable_backend.py#L596-L602 [2]https://github.com/openstack/neutron/blob/40c501dcb158b1ab14137c94c60697e19a73c170/neutron/db/ipam_backend_mixin.py#L67 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1904436/+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 1991051] Re: Latest image breaks Juju on LXD 4.0
** Changed in: cloud-images Status: In Progress => 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/1991051 Title: Latest image breaks Juju on LXD 4.0 Status in cloud-images: Fix Released Status in cloud-init: Invalid Status in lxd: New Status in cloud-init package in Ubuntu: Triaged Bug description: Ubuntu focal comes with LXD 4.0 installed by default. When using Juju to create containers on a local LXD with focal based instances, the deployment breaks due to and incorrect cloud-init configuration (see https://github.com/lxc/lxd/issues/10951, which existed since 2015!). A fix is not meant to arrive in LXD 4.0 till November (see https://github.com/lxc/lxd/issues/10951#issuecomment-1258691195). The new behavior in cloud-init has real implications as right now our commercial offering of the Anbox Cloud Appliance on the AWS marketplace (https://aws.amazon.com/marketplace/pp/prodview- aqmdt52vqs5qk) is broken when people buy it without a simple path to fix, other than forcing users to upgrade to LXD 5.0. We will hotfix this and ask people at installation time to upgrade to LXD 5.0. However, have we considered rolling back the cloud-init update as it's causing issues for a variety of people? I know about one other product which broke due to this (OSM). Also see https://bugs.launchpad.net/juju/+bug/1990594 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1991051/+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 1832758] Re: [RFE] Allow/deny custom ethertypes in security groups
** 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/1832758 Title: [RFE] Allow/deny custom ethertypes in security groups Status in neutron: Fix Released Bug description: Some operators need to allow/deny custom Ethertypes for applications which use their own non-IP traffic (such as for clustering applications). The Security Group API only handles specifying behavior within the IP protocol. With the firewall reference implementation (OVS Firewall) anything other than IPv4 and IPv6 is subject to the default deny. This means OpenStack customers have no options to use OpenStack to permit protocols that use separate ethertypes like InfiniBand and FCoE. We propose adding to the Security Group API the capability to specify standard security group behaviors (allow, deny) for custom ethertypes, with the aim of implementing these controls in the OVS firewall. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1832758/+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 1792901] Re: [RFE] subnet pool can not delete prefixes
Looks like all the changes for this have merged, marking fixed, please
re-open if I missed something.
** Changed in: neutron
Status: Triaged => 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/1792901
Title:
[RFE] subnet pool can not delete prefixes
Status in neutron:
Fix Released
Bug description:
env: Rocky devstack
I create a subnetpool like this:
[stack@qs11 ~]$ openstack subnet pool show demo-subnetpool4
+---+---+
| Field | Value
|
+---+---+
| address_scope_id | None
|
| created_at| 2018-09-17T09:07:04Z
|
| default_prefixlen | 26
|
| default_quota | None
|
| description |
|
| id| ee80a076-ab3a-464d-88bf-a3181c0cf6d8
|
| ip_version| 4
|
| is_default| False
|
| max_prefixlen | 32
|
| min_prefixlen | 8
|
| name | demo-subnetpool4
|
| prefixes | 192.168.11.0/24, 198.160.10.0/23, 198.51.100.0/24,
203.0.113.0/24 |
| project_id| 3cc022c8972345aaafc1346343eb4747
|
| revision_number | 6
|
| shared| True
|
| tags |
|
| updated_at| 2018-09-17T09:52:32Z
|
+---+---+
The subnet pool have prefixes:
192.168.11.0/24
198.160.10.0/23
198.51.100.0/24
203.0.113.0/24
The prefixes 198.160.10.0/23 is create by mistake, I try to delete
198.160.10.0/23 prefixes, but I can't find out a method.
usage: neutron subnetpool-update [-h] [--description DESCRIPTION]
[--min-prefixlen MIN_PREFIXLEN]
[--max-prefixlen MAX_PREFIXLEN]
[--default-prefixlen DEFAULT_PREFIXLEN]
[--pool-prefix PREFIXES]
[--is-default {True,False}] [--name NAME]
[--address-scope ADDRSCOPE |
--no-address-scope]
SUBNETPOOL
usage: openstack subnet pool set [-h] [--name ]
[--pool-prefix ]
[--default-prefix-length
]
[--min-prefix-length ]
[--max-prefix-length ]
[--address-scope |
--no-address-scope]
[--default | --no-default]
[--description ]
[--default-quota ]
[--tag ] [--no-tag]
usage: openstack subnet pool unset [-h] [--pool-prefix ]
[--tag | --all-tag]
Only have "load prefixes" method.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1792901/+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 1747028] Re: Segments extension documentation does not explain why you would want to use it
Reviewed: https://review.opendev.org/c/openstack/neutron/+/869877 Committed: https://opendev.org/openstack/neutron/commit/7751ac32a7e0119cdef7efccf2282f695f6055c3 Submitter: "Zuul (22348)" Branch:master commit 7751ac32a7e0119cdef7efccf2282f695f6055c3 Author: Brian Haley Date: Wed Jan 11 17:13:49 2023 -0500 Add info on segments extension to contrib guide Add link from segments extension doc to routed networks spec, which explains the use case. Trivialfix Closes-bug: #1747028 Change-Id: I8af639bc44924582135d3cc94196b3c9b3ca4b5d ** 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/1747028 Title: Segments extension documentation does not explain why you would want to use it Status in neutron: Fix Released Bug description: https://docs.openstack.org/neutron/pike/contributor/internals/segments.html The segments extension says 'this lets you operate on segments', basically. It doesn't say what a segment is (or refer to external documentation that does) and it does not say why you might want an API to operate on them, nor what that API is. So it doesn't tell me what I would want this service plugin for or how I would use it if I worked out that I wanted it. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1747028/+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 1855919] Re: broken pipe errors cause neutron metadata agent to fail
Reviewed: https://review.opendev.org/c/openstack/neutron/+/869770 Committed: https://opendev.org/openstack/neutron/commit/ed048638f4ef6a1799a1dcbd8819627b3fa8e75e Submitter: "Zuul (22348)" Branch:master commit ed048638f4ef6a1799a1dcbd8819627b3fa8e75e Author: Brian Haley Date: Tue Jan 10 16:40:29 2023 -0500 Add text to WSGI config guide for debugging Add "broken pipe" example error message to WSGI guide in rpc_workers section, could help diagnose agent issues. Trivialfix Change-Id: I6e95614bce42124f125be4c23fff0d923ea9ebcc Closes-bug: #1855919 ** 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/1855919 Title: broken pipe errors cause neutron metadata agent to fail Status in neutron: Fix Released Bug description: After we increased computes to 200, we started seeing "broken pipe" errors in neutron-metadata-agent.log on the controllers. After a neutron restart the errors are reduced, then they increase until the log is mostly errors, and the neutron metadata service fails, and VMs cannot boot. Another symptom is that unacked RMQ messages build up in the q-plugin queue. This is the first error we see; this one occurs as the server is starting: 2019-12-10 10:56:01.942 1838536 INFO eventlet.wsgi.server [-] (1838536) wsgi starting up on http:/var/lib/neutron/metadata_proxy 2019-12-10 10:56:01.943 1838538 INFO eventlet.wsgi.server [-] (1838538) wsgi starting up on http:/var/lib/neutron/metadata_proxy 2019-12-10 10:56:01.945 1838539 INFO eventlet.wsgi.server [-] (1838539) wsgi starting up on http:/var/lib/neutron/metadata_proxy 2019-12-10 10:56:21.138 1838538 INFO eventlet.wsgi.server [-] Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 521, in handle_one_response write(b''.join(towrite)) File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 462, in write wfile.flush() File "/usr/lib/python2.7/socket.py", line 307, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 390, in sendall tail = self.send(data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 384, in send return self._send_loop(self.fd.send, data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 371, in _send_loop return send_method(data, *args) error: [Errno 32] Broken pipe 2019-12-10 10:56:21.138 1838538 INFO eventlet.wsgi.server [-] 10.195.74.25, "GET /latest/meta-data/instance-id HTTP/1.0" status: 200 len: 0 time: 19.0296111 2019-12-10 10:56:25.059 1838516 INFO eventlet.wsgi.server [-] 10.195.74.28, "GET /latest/meta-data/instance-id HTTP/1.0" status: 200 len: 146 time: 0.2840948 2019-12-10 10:56:25.181 1838529 INFO eventlet.wsgi.server [-] 10.195.74.68, "GET /latest/meta-data/instance-id HTTP/1.0" status: 200 len: 146 time: 0.2695429 2019-12-10 10:56:25.259 1838518 INFO eventlet.wsgi.server [-] 10.195.74.28, "GET /latest/meta-data/instance-id HTTP/1.0" status: 200 len: 146 time: 0.1980510 Then we see some "call queues" warnings and the threshold increases to 40: 2019-12-10 10:56:31.414 1838515 WARNING oslo_messaging._drivers.amqpdriver [-] Number of call queues is 11, greater than warning threshold: 10. There could be a leak. Increasing threshold to: 20 Next we see RPC timeout errors: 2019-12-10 10:57:02.043 1838520 WARNING oslo_messaging._drivers.amqpdriver [-] Number of call queues is 11, greater than warning threshold: 10. There could be a leak. Increasing threshold to: 20 2019-12-10 10:57:02.059 1838534 ERROR neutron.common.rpc [-] Timeout in RPC method get_ports. Waiting for 37 seconds before next attempt. If the server is not down, consider increasing the rpc_response_timeout option as Neutron server(s) may be overloaded and unable to respond quickly enough.: MessagingTimeout: Timed out waiting for a reply to message ID 1ed3e021607e466f8b9b84cd3b05b188 2019-12-10 10:57:02.059 1838534 WARNING neutron.common.rpc [-] Increasing timeout for get_ports calls to 120 seconds. Restart the agent to restore it to the default value.: MessagingTimeout: Timed out waiting for a reply to message ID 1ed3e021607e466f8b9b84cd3b05b188 2019-12-10 10:57:02.285 1838521 INFO eventlet.wsgi.server [-] 10.195.74.27, "GET /latest/meta-data/instance-id HTTP/1.0" status: 200 len: 146 time: 0.7959940 2019-12-10 10:57:16.215 1838531 WARNING oslo_messaging._drivers.amqpdriver [-] Number of call queues is 21, greater than warning threshold: 20. There could be a leak. Increasing threshold to: 40 2019-12-10 10:57:17.339 1838539 WARNING oslo_messaging._drivers.amqpdriver [-] Number of
[Yahoo-eng-team] [Bug 1980845] Re: Impossible to remove deleted project from private flavor's access list
Reviewed: https://review.opendev.org/c/openstack/nova/+/849131
Committed:
https://opendev.org/openstack/nova/commit/8c6daaacbedc33e738ce85aec0ead5f6947d60bf
Submitter: "Zuul (22348)"
Branch:master
commit 8c6daaacbedc33e738ce85aec0ead5f6947d60bf
Author: Alexey Stupnikov
Date: Fri Jul 8 17:56:38 2022 +0200
Remove deleted projects from flavor access list
Previously Nova was unable to remove deleted projects from flavor's
access lists. This patch lifts described limitation and improves
logic of nova/api/openstack/identity.py library by introducing two
separate kinds of exceptions:
- webob.exc.HTTPInternalServerError is raised when Keystone identity
service version 3.0 was not found.
- webob.exc.HTTPBadRequest is raised when specified project is not
found.
Closes-bug: #1980845
Change-Id: Icbf3bdd944f9a6c38f25ddea0b521ca48ee87a7f
** 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/1980845
Title:
Impossible to remove deleted project from private flavor's access list
Status in OpenStack Compute (nova):
Fix Released
Bug description:
Private flavors have a list of projects which can use them. This list
of projects is maintained in flavor_projects table and this list is
not updated automatically when some project is removed by Keystone.
As a result, OpenStack users may face situations when project
associated with private flavor no longer exists and it is impossible
to remove it.
Steps to reproduce:
(overcloud) [stack@undercloud-0 ~]$ openstack project create testproject
+-+--+
| Field | Value|
+-+--+
| description | |
| domain_id | default |
| enabled | True |
| id | e9884959c0ad46f5a9b1dfe9654aa577 |
| is_domain | False|
| name| testproject |
| options | {} |
| parent_id | default |
| tags| [] |
+-+--+
(overcloud) [stack@undercloud-0 ~]$ openstack flavor create --private
--project testproject --ram 64 --disk 1 test_testproj
++--+
| Field | Value|
++--+
| OS-FLV-DISABLED:disabled | False|
| OS-FLV-EXT-DATA:ephemeral | 0|
| description| None |
| disk | 1|
| extra_specs| {} |
| id | b1a3307c-03d2-4da8-bfa9-d138025d5203 |
| name | test_testproj|
| os-flavor-access:is_public | False|
| properties | |
| ram| 64 |
| rxtx_factor| 1.0 |
| swap | 0|
| vcpus | 1|
++--+
(overcloud) [stack@undercloud-0 ~]$ openstack project delete testproject
(overcloud) [stack@undercloud-0 ~]$ openstack flavor unset --project
testproject test_testproj
Failed to remove flavor access from project: No project with a name or ID of
'testproject' exists.
Command Failed: One or more of the operations failed
Code:
https://github.com/openstack/nova/blob/master/nova/api/openstack/identity.py
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1980845/+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 2002687] [NEW] [RFE] Active-active L3 Gateway with Multihoming
Public bug reported: Some network designs include multiple L3 gateways to: * Share the load across different gateways; * Provide independent network paths for the north-south direction (e.g. via different ISPs). Having multi-homing implemented at the instance level imposes additional burden on the end user of a cloud and support requirements for the guest OS, whereas utilizing ECMP and BFD at the router side alleviates the need for instance-side awareness of a more complex routing setup. Adding more than one gateway port implies extending the existing data model which was described in the multiple external gateways spec (https://specs.openstack.org/openstack/neutron-specs/specs/xena/multiple-external-gateways.html). However, it left adding additional gateway routes out of scope leaving this to future improvements around dynamic routing. Also the focus of neutron-dynamic-routing has so far been around advertising routes, not accepting new ones from the external peers - so dynamic routing support like this is a very different subject. However, manual addition of extra routes does not utilize the default gateway IP information available from subnets in Neutron while this could be addressed by implementing an extra conditional behavior when adding more than one gateway port to a router. ECMP routes can result in black-holing of traffic should the next-hop of a route becomes unreachable. BFD is a standard protocol adopted by IETF for next-hop failure detection which can be used for route eviction. OVN supports BFD as of v21.03.0 (https://github.com/ovn-org/ovn/commit/6e0a69ad4bcdf9e4cace5c73ef48ab06065e8519) with a data model that allows enabling BFD on a per next-hop basis by associating BFD session information with routes, however, it is not modeled at the Neutron level even if a backend supports it. >From the Neutron data model perspective, ECMP for routes is already a supported concept since ECMP support spec got implemented (https://specs.openstack.org/openstack/neutron-specs/specs/wallaby/l3-router-support-ecmp.html) in Wallaby (albeit the spec focused on the L3-agent based implementation only). As for OVN and BFD, the OVN database state needs to be populated by Neutron based on the data from the Neutron database, therefore, data model changes to the Neutron DB are needed to represent the BFD session parameters. --- The previous work on multiple gateway ports did not get completed and the neutron-lib changes were reverted. Likewise, the scope of this RFE is bigger with some overlap and augmentation compared to prior art. The spec will follow for this RFE with more details as to how the data model and API changes are proposed to be made. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2002687 Title: [RFE] Active-active L3 Gateway with Multihoming Status in neutron: New Bug description: Some network designs include multiple L3 gateways to: * Share the load across different gateways; * Provide independent network paths for the north-south direction (e.g. via different ISPs). Having multi-homing implemented at the instance level imposes additional burden on the end user of a cloud and support requirements for the guest OS, whereas utilizing ECMP and BFD at the router side alleviates the need for instance-side awareness of a more complex routing setup. Adding more than one gateway port implies extending the existing data model which was described in the multiple external gateways spec (https://specs.openstack.org/openstack/neutron-specs/specs/xena/multiple-external-gateways.html). However, it left adding additional gateway routes out of scope leaving this to future improvements around dynamic routing. Also the focus of neutron-dynamic-routing has so far been around advertising routes, not accepting new ones from the external peers - so dynamic routing support like this is a very different subject. However, manual addition of extra routes does not utilize the default gateway IP information available from subnets in Neutron while this could be addressed by implementing an extra conditional behavior when adding more than one gateway port to a router. ECMP routes can result in black-holing of traffic should the next-hop of a route becomes unreachable. BFD is a standard protocol adopted by IETF for next-hop failure detection which can be used for route eviction. OVN supports BFD as of v21.03.0 (https://github.com/ovn-org/ovn/commit/6e0a69ad4bcdf9e4cace5c73ef48ab06065e8519) with a data model that allows enabling BFD on a per next-hop basis by associating BFD session information with routes, however, it is not modeled at the Neutron level even if a backend supports it. From the Neutron data model perspective, ECMP for routes is already a
[Yahoo-eng-team] [Bug 2002672] [NEW] Bad JSON in application credential example
Public bug reported: In the form for creating application credentials, there is an example of what you can fill in for Access Rules. One would expect that the example works, but it doesn't. I attach a screen shot. The issue is likely that there are non-breakable spaces in the example, which aren't valid JSON. The YAML example also doesn't work. versions (the patch is for our own skinning): heat-dashboard-common_3.0.1-0ubuntu1+5eda8988~focal~syseleven1_all.deb openstack-dashboard-common_18.3.5-0ubuntu2.1+220c4858~focal~syseleven1_all.deb openstack-dashboard-ubuntu-theme_18.3.5-0ubuntu2.1+220c4858~focal~syseleven1_all.deb openstack-dashboard_18.3.5-0ubuntu2.1+220c4858~focal~syseleven1_all.deb python3-django-horizon_18.3.5-0ubuntu2.1+220c4858~focal~syseleven1_all.deb python3-django-openstack-auth_18.3.5-0ubuntu2.1+220c4858~focal~syseleven1_all.deb python3-heat-dashboard_3.0.1-0ubuntu1+5eda8988~focal~syseleven1_all.deb python3-neutron-lbaas-dashboard_6.0.0-0ubuntu1.1+de473530~focal~syseleven1_all.deb python3-neutron-vpnaas-dashboard_2.0.0-1+13bac31b~focal~syseleven1_all.deb python3-octavia-dashboard_5.0.0-0ubuntu0.20.04.2+85b36c13~focal~syseleven1_all.deb ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "Screenshot 2023-01-12 at 17.15.52.png" https://bugs.launchpad.net/bugs/2002672/+attachment/5641008/+files/Screenshot%202023-01-12%20at%2017.15.52.png ** Summary changed: - Bad JSON in application crediential example + Bad JSON in application credential example -- 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/2002672 Title: Bad JSON in application credential example Status in OpenStack Dashboard (Horizon): New Bug description: In the form for creating application credentials, there is an example of what you can fill in for Access Rules. One would expect that the example works, but it doesn't. I attach a screen shot. The issue is likely that there are non-breakable spaces in the example, which aren't valid JSON. The YAML example also doesn't work. versions (the patch is for our own skinning): heat-dashboard-common_3.0.1-0ubuntu1+5eda8988~focal~syseleven1_all.deb openstack-dashboard-common_18.3.5-0ubuntu2.1+220c4858~focal~syseleven1_all.deb openstack-dashboard-ubuntu-theme_18.3.5-0ubuntu2.1+220c4858~focal~syseleven1_all.deb openstack-dashboard_18.3.5-0ubuntu2.1+220c4858~focal~syseleven1_all.deb python3-django-horizon_18.3.5-0ubuntu2.1+220c4858~focal~syseleven1_all.deb python3-django-openstack-auth_18.3.5-0ubuntu2.1+220c4858~focal~syseleven1_all.deb python3-heat-dashboard_3.0.1-0ubuntu1+5eda8988~focal~syseleven1_all.deb python3-neutron-lbaas-dashboard_6.0.0-0ubuntu1.1+de473530~focal~syseleven1_all.deb python3-neutron-vpnaas-dashboard_2.0.0-1+13bac31b~focal~syseleven1_all.deb python3-octavia-dashboard_5.0.0-0ubuntu0.20.04.2+85b36c13~focal~syseleven1_all.deb To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/2002672/+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 2002668] [NEW] horizon security group pagination
Public bug reported: On horizon there is no pagination for security group page . I have near 1500 security group and page loading takes about 3minutes ! I think this page need pagination like instances page for solving this issue . also sometimes I have 504 gateway timeout when I takes too long to load ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "securitygroup.png" https://bugs.launchpad.net/bugs/2002668/+attachment/5641007/+files/securitygroup.png -- 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/2002668 Title: horizon security group pagination Status in OpenStack Dashboard (Horizon): New Bug description: On horizon there is no pagination for security group page . I have near 1500 security group and page loading takes about 3minutes ! I think this page need pagination like instances page for solving this issue . also sometimes I have 504 gateway timeout when I takes too long to load To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/2002668/+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 2002629] Re: devstack build in the gate fails with: ovnnb_db.sock: database connection failed
Removing neutron from the affected projects, since Yatin found the cause in devstack. ** No longer affects: neutron -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2002629 Title: devstack build in the gate fails with: ovnnb_db.sock: database connection failed Status in devstack: In Progress Bug description: Recently we seem to have many the same devstack build failure in many different gate jobs. The usual error message is: + lib/neutron_plugins/ovn_agent:start_ovn:714 : wait_for_db_file /var/lib/ovn/ovnsb_db.db + lib/neutron_plugins/ovn_agent:wait_for_db_file:175 : local count=0 + lib/neutron_plugins/ovn_agent:wait_for_db_file:176 : '[' '!' -f /var/lib/ovn/ovnsb_db.db ']' + lib/neutron_plugins/ovn_agent:start_ovn:716 : is_service_enabled tls-proxy + functions-common:is_service_enabled:2089 : return 0 + lib/neutron_plugins/ovn_agent:start_ovn:717 : sudo ovn-nbctl --db=unix:/var/run/ovn/ovnnb_db.sock set-ssl /opt/stack/data/CA/int-ca/private/devstack-cert.key /opt/stack/data/CA/int-ca/devstack-cert.crt /opt/stack/data/CA/int-ca/ca-chain.pem ovn-nbctl: unix:/var/run/ovn/ovnnb_db.sock: database connection failed (No such file or directory) + lib/neutron_plugins/ovn_agent:start_ovn:1 : exit_trap A few example logs: https://zuul.opendev.org/t/openstack/build/ec852d75c8094afcb4140871bc9ffa36 https://zuul.opendev.org/t/openstack/build/eae988aa8cd24c78894a3d3438392357 The search expression 'message:"ovnnb_db.sock: database connection failed"' gives me 1200+ hits in https://opensearch.logs.openstack.org for the last 2 weeks. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/2002629/+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 2002649] [NEW] [doc] URL Namespace to use for Nova specific metadata items in XML outdated
Public bug reported: The next link is 404: https://opendev.org/openstack/nova/src/commit/cfafd69017d695b78cedddc6cdea9517254063bd/nova/virt/libvirt/config.py ** Affects: nova Importance: Undecided Status: New -- 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/2002649 Title: [doc] URL Namespace to use for Nova specific metadata items in XML outdated Status in OpenStack Compute (nova): New Bug description: The next link is 404: https://opendev.org/openstack/nova/src/commit/cfafd69017d695b78cedddc6cdea9517254063bd/nova/virt/libvirt/config.py To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2002649/+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 2002629] Re: devstack build in the gate fails with: ovnnb_db.sock: database connection failed
<< The search expression 'message:"ovnnb_db.sock: database connection
failed"' gives me 1200+ hits in https://opensearch.logs.openstack.org
for the last 2 weeks.
I added some more filters and it gives 50 such results:-
https://opensearch.logs.openstack.org/_dashboards/app/discover/?security_tenant=global#/?_g=(filters:!(),refreshInterval:(pause:!t,value:0),time:(from:now-30d,to:now))&_a=(columns:!(_source),filters:!(('$state':(store:appState),meta:(alias:!n,disabled:!f,index:'94869730-aea8-11ec-9e6a-83741af3fdcd',key:build_name,negate:!t,params:(query:tripleo-ci-centos-9-standalone-external-compute-target-host),type:phrase),query:(match_phrase:(build_name:tripleo-ci-centos-9-standalone-external-compute-target-host))),('$state':(store:appState),meta:(alias:!n,disabled:!f,index:'94869730-aea8-11ec-9e6a-83741af3fdcd',key:build_name,negate:!t,params:(query:tobiko-tripleo-minimal),type:phrase),query:(match_phrase:(build_name:tobiko-tripleo-minimal))),('$state':(store:appState),meta:(alias:!n,disabled:!f,index:'94869730-aea8-11ec-9e6a-83741af3fdcd',key:filename,negate:!f,params:(query:job-output.txt),type:phrase),query:(match_phrase:(filename:job-output.txt,index:'94869730-aea8-11ec-9e6a-83741af3fdcd',interval:auto,query:(language:kuery,query:'message:%22ovnnb_db.sock:%20database%20connection%20failed%22%20AND%20build_status:FAILURE'),sort:!())
In past we have seen taking much time to start and available of db files for
those increasing timeout helped
https://review.opendev.org/c/openstack/devstack/+/848548.
But now it's little different issue where it takes time to stop and in that
window(can be seen if the window is less than a second in below example)
wait_for_sock_file returns true and moves forward and later connection to those
.sock files fails as service is not restarted by that time.
2023-01-11 09:24:11.273593 | controller | +
lib/neutron_plugins/ovn_agent:_start_process:239 : sudo systemctl restart
ovn-central.service
2023-01-11 09:24:11.295863 | controller | +
lib/neutron_plugins/ovn_agent:start_ovn:711 : wait_for_sock_file
/var/run/ovn/ovnnb_db.sock
2023-01-11 09:24:11.298605 | controller | +
lib/neutron_plugins/ovn_agent:wait_for_sock_file:186 : local count=0
2023-01-11 09:24:11.300757 | controller | +
lib/neutron_plugins/ovn_agent:wait_for_sock_file:187 : '[' '!' -S
/var/run/ovn/ovnnb_db.sock ']'
2023-01-11 09:24:11.303155 | controller | +
lib/neutron_plugins/ovn_agent:start_ovn:712 : wait_for_sock_file
/var/run/ovn/ovnsb_db.sock
2023-01-11 09:24:11.305826 | controller | +
lib/neutron_plugins/ovn_agent:wait_for_sock_file:186 : local count=0
2023-01-11 09:24:11.308367 | controller | +
lib/neutron_plugins/ovn_agent:wait_for_sock_file:187 : '[' '!' -S
/var/run/ovn/ovnsb_db.sock ']'
2023-01-11 09:24:11.310862 | controller | +
lib/neutron_plugins/ovn_agent:start_ovn:713 : wait_for_db_file
/var/lib/ovn/ovnnb_db.db
2023-01-11 09:24:11.313570 | controller | +
lib/neutron_plugins/ovn_agent:wait_for_db_file:175 : local count=0
2023-01-11 09:24:11.316126 | controller | +
lib/neutron_plugins/ovn_agent:wait_for_db_file:176 : '[' '!' -f
/var/lib/ovn/ovnnb_db.db ']'
2023-01-11 09:24:11.319726 | controller | +
lib/neutron_plugins/ovn_agent:wait_for_db_file:177 : sleep 1
2023-01-11 09:24:12.323489 | controller | +
lib/neutron_plugins/ovn_agent:wait_for_db_file:178 : count=1
2023-01-11 09:24:12.326545 | controller | +
lib/neutron_plugins/ovn_agent:wait_for_db_file:179 : '[' 1 -gt 40 ']'
2023-01-11 09:24:12.328763 | controller | +
lib/neutron_plugins/ovn_agent:wait_for_db_file:176 : '[' '!' -f
/var/lib/ovn/ovnnb_db.db ']'
2023-01-11 09:24:12.331382 | controller | +
lib/neutron_plugins/ovn_agent:start_ovn:714 : wait_for_db_file
/var/lib/ovn/ovnsb_db.db
2023-01-11 09:24:12.333636 | controller | +
lib/neutron_plugins/ovn_agent:wait_for_db_file:175 : local count=0
2023-01-11 09:24:12.336270 | controller | +
lib/neutron_plugins/ovn_agent:wait_for_db_file:176 : '[' '!' -f
/var/lib/ovn/ovnsb_db.db ']'
2023-01-11 09:24:12.339188 | controller | +
lib/neutron_plugins/ovn_agent:start_ovn:716 : is_service_enabled tls-proxy
2023-01-11 09:24:12.357535 | controller | +
functions-common:is_service_enabled:2089 : return 0
2023-01-11 09:24:12.359893 | controller | +
lib/neutron_plugins/ovn_agent:start_ovn:717 : sudo ovn-nbctl
--db=unix:/var/run/ovn/ovnnb_db.sock set-ssl
/opt/stack/data/CA/int-ca/private/devstack-cert.key
/opt/stack/data/CA/int-ca/devstack-cert.crt
/opt/stack/data/CA/int-ca/ca-chain.pem
2023-01-11 09:24:12.367707 | controller | ovn-nbctl:
unix:/var/run/ovn/ovnnb_db.sock: database connection failed (No such file or
directory)
from service status:-
â— ovn-ovsdb-server-nb.service - Open vSwitch database server for OVN
Northbound database
Loaded: loaded (/lib/systemd/system/ovn-ovsdb-server-nb.service; enabled;
vendor preset: enabled)
Active: active (running) since Wed 2023-01-11 09:24:11 UTC; 47s ago
Main PID: 96196
[Yahoo-eng-team] [Bug 2002629] [NEW] devstack build in the gate fails with: ovnnb_db.sock: database connection failed
Public bug reported: Recently we seem to have many the same devstack build failure in many different gate jobs. The usual error message is: + lib/neutron_plugins/ovn_agent:start_ovn:714 : wait_for_db_file /var/lib/ovn/ovnsb_db.db + lib/neutron_plugins/ovn_agent:wait_for_db_file:175 : local count=0 + lib/neutron_plugins/ovn_agent:wait_for_db_file:176 : '[' '!' -f /var/lib/ovn/ovnsb_db.db ']' + lib/neutron_plugins/ovn_agent:start_ovn:716 : is_service_enabled tls-proxy + functions-common:is_service_enabled:2089 : return 0 + lib/neutron_plugins/ovn_agent:start_ovn:717 : sudo ovn-nbctl --db=unix:/var/run/ovn/ovnnb_db.sock set-ssl /opt/stack/data/CA/int-ca/private/devstack-cert.key /opt/stack/data/CA/int-ca/devstack-cert.crt /opt/stack/data/CA/int-ca/ca-chain.pem ovn-nbctl: unix:/var/run/ovn/ovnnb_db.sock: database connection failed (No such file or directory) + lib/neutron_plugins/ovn_agent:start_ovn:1 : exit_trap A few example logs: https://zuul.opendev.org/t/openstack/build/ec852d75c8094afcb4140871bc9ffa36 https://zuul.opendev.org/t/openstack/build/eae988aa8cd24c78894a3d3438392357 The search expression 'message:"ovnnb_db.sock: database connection failed"' gives me 1200+ hits in https://opensearch.logs.openstack.org for the last 2 weeks. ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure ovn -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2002629 Title: devstack build in the gate fails with: ovnnb_db.sock: database connection failed Status in neutron: New Bug description: Recently we seem to have many the same devstack build failure in many different gate jobs. The usual error message is: + lib/neutron_plugins/ovn_agent:start_ovn:714 : wait_for_db_file /var/lib/ovn/ovnsb_db.db + lib/neutron_plugins/ovn_agent:wait_for_db_file:175 : local count=0 + lib/neutron_plugins/ovn_agent:wait_for_db_file:176 : '[' '!' -f /var/lib/ovn/ovnsb_db.db ']' + lib/neutron_plugins/ovn_agent:start_ovn:716 : is_service_enabled tls-proxy + functions-common:is_service_enabled:2089 : return 0 + lib/neutron_plugins/ovn_agent:start_ovn:717 : sudo ovn-nbctl --db=unix:/var/run/ovn/ovnnb_db.sock set-ssl /opt/stack/data/CA/int-ca/private/devstack-cert.key /opt/stack/data/CA/int-ca/devstack-cert.crt /opt/stack/data/CA/int-ca/ca-chain.pem ovn-nbctl: unix:/var/run/ovn/ovnnb_db.sock: database connection failed (No such file or directory) + lib/neutron_plugins/ovn_agent:start_ovn:1 : exit_trap A few example logs: https://zuul.opendev.org/t/openstack/build/ec852d75c8094afcb4140871bc9ffa36 https://zuul.opendev.org/t/openstack/build/eae988aa8cd24c78894a3d3438392357 The search expression 'message:"ovnnb_db.sock: database connection failed"' gives me 1200+ hits in https://opensearch.logs.openstack.org for the last 2 weeks. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2002629/+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
