[Yahoo-eng-team] [Bug 1725587] Re: rally create_and_list_floating_ips task fails with duplicate IpamAllocation
I don't see this error in any recent rally runs, so will close. Please
re-open if you see it again.
** 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/1725587
Title:
rally create_and_list_floating_ips task fails with duplicate
IpamAllocation
Status in neutron:
Invalid
Bug description:
Description
===
environment
---
* RDO OpenStack Ocata
* neutron conf:
service_plugins = router
ml2 mechanism_drivers = openvswitch
external network ex-network with a subnet 111.0.0.0/16
* rally 0.9.1
create_and_list_floating_ips.json
{
"NeutronNetworks.create_and_list_floating_ips": [
{
"args": {
"floating_network": "ex-network",
"floating_ip_args": {}
},
"runner": {
"type": "constant",
"times": 500,
"concurrency": 100
},
"context": {
"users": {
"tenants": 2,
"users_per_tenant": 3
},
"quotas": {
"neutron": {
"floatingip": -1
}
}
},
"sla": {
"failure_rate": {
"max": 0
}
}
}
]
}
rally result
Total durations
ActionMin (sec) Median (sec)90%ile (sec)95%ile (sec)
Max (sec) Avg (sec) Success Count
neutron.create_floating_ip4.2 18.946 71.561 91.803 131.663 29.769
94.2% 500
-> neutron.list_networks 0.991 1.837 10.769 11.56 12.955 3.366
94.2% 500
neutron.list_floating_ips 0.162 0.951.672 1.884 3.009 1.007
100.0% 471
total 4.396 20.196 71.896 92.886 131.663 30.717 94.2% 500
-> duration 4.396 20.196 71.896 92.886 131.663 30.717 94.2% 500
-> idle_duration 0 0 0 0 0 0 94.2%
500
html report here: https://pastebin.com/9bLJVhfS
neutron-server log
--
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api
[req-f4c8db2c-d80d-475a-b408-6eafd6701b62 07a6aba4b1a44dbc9453bfbe4a65
bb0f198d854c440d8f7c0beb27eaae2b - - -] DB exceeded retry limit.
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api Traceback (most recent call
last):
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api File
"/usr/lib/python2.7/site-packages/oslo_db/api.py", line 139, in wrapper
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api return f(*args, **kwargs)
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api File
"/usr/lib/python2.7/site-packages/neutron/db/api.py", line 131, in wrapped
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api traceback.format_exc())
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api self.force_reraise()
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
force_reraise
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api six.reraise(self.type_,
self.value, self.tb)
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api File
"/usr/lib/python2.7/site-packages/neutron/db/api.py", line 126, in wrapped
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api return f(*dup_args,
**dup_kwargs)
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api File
"/usr/lib/python2.7/site-packages/neutron/plugins/ml2/plugin.py", line 1192, in
create_port
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api result, mech_context =
self._create_port_db(context, port)
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api File
"/usr/lib/python2.7/site-packages/neutron/plugins/ml2/plugin.py", line 1163, in
_create_port_db
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api port_db =
self.create_port_db(context, port)
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api File
"/usr/lib/python2.7/site-packages/neutron/db/db_base_plugin_v2.py", line 1221,
in create_port_db
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api context, port, port_id)
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api File
"/usr/lib/python2.7/site-packages/neutron/db/ipam_pluggable_backend.py", line
191, in allocate_ips_for_port_and_store
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api revert_on_fail=False)
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api self.force_reraise()
2017-10-21 10:50:50.445 20020 ERROR oslo_db.api
[Yahoo-eng-team] [Bug 1712065] Re: can we configure multiple external networks in newton or ocata release
We are many releases past Ocata and this issue has already been addressed. ** 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/1712065 Title: can we configure multiple external networks in newton or ocata release Status in neutron: Invalid Bug description: http://blog.oddbit.com/2014/05/28/multiple-external-networks-wit/ As per the above blog we can configure multiple external networks on neutron l3 agent. But will this work on the new release of openstack(ovs with gre) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1712065/+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 1714416] Re: Incorrect response returned for invalid Accept header
** Changed in: neutron Status: New => Won't Fix -- 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/1714416 Title: Incorrect response returned for invalid Accept header Status in Cinder: Won't Fix Status in Glance: Invalid Status in OpenStack Heat: Won't Fix Status in OpenStack Identity (keystone): Won't Fix Status in masakari: Won't Fix Status in neutron: Won't Fix Status in OpenStack Compute (nova): Won't Fix Bug description: As of now, when user passes 'Accept' header in request other than JSON and XML using curl command then it returns 200 OK response with json format data. In api-ref guide [1] also it's not clearly mentioned about what response it should return if invalid value for 'Accept' header is specified. IMO instead of 'HTTP 200 OK' it should return 'HTTP 406 Not Acceptable' response. Steps to reproduce: Request: curl -g -i -X GET http://controller/volume/v2/c72e66cc4f1341f381e0c2eb7b28b443/volumes/detail -H "User-Agent: python-cinderclient" -H "Accept: application/abc" -H "X-Auth-Token: cd85aff745ce4dc0a04f686b52cf7e4f" Response: HTTP/1.1 200 OK Date: Thu, 31 Aug 2017 07:12:18 GMT Server: Apache/2.4.18 (Ubuntu) x-compute-request-id: req-ab48db9d-f869-4eb4-95f9-ef8e90a918df Content-Type: application/json Content-Length: 2681 x-openstack-request-id: req-ab48db9d-f869-4eb4-95f9-ef8e90a918df Connection: close [1] https://developer.openstack.org/api-ref/block-storage/v2/#list-volumes-with-details To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1714416/+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 1717245] Re: openstack router set --external-gateway creates port without tenant-id
** Changed in: neutron
Status: Confirmed => 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/1717245
Title:
openstack router set --external-gateway creates port without tenant-id
Status in neutron:
Invalid
Bug description:
Adding an external gateway to router creates port without tenant-id.
It also creates a security group without tenant-id and its rules are
also without tenant-id.
http://paste.openstack.org/show/621108/
Relevant call from the log:
REQ: curl -g -i -X PUT
http://10.195.115.111:9696/v2.0/routers/a6f357f7-2383-4e77-9b8a-98a634214aeb -H
"User-Agent: openstacksdk/0.9.13 keystoneauth1/2.18.0 python-requests/2.11.1
CPython/2.7.5" -H "Content-Type: application/json" -H "X-Auth-Token:
{SHA1}3f452ec3ac595bbba2e2a916349ce340aaa2eecb" -d '{"router":
{"external_gateway_info": {"network_id":
"bd8f1306-2a90-476e-b55c-01d327032d7c"}}}'
RESP: [200] Content-Type: application/json Content-Length: 603
X-Openstack-Request-Id: req-b992ecf6-4c17-4d3f-9cbc-be391cdb41d4 Date: Thu, 14
Sep 2017 12:01:28 GMT
RESP BODY: {"router": {"status": "ACTIVE", "external_gateway_info":
{"network_id": "bd8f1306-2a90-476e-b55c-01d327032d7c", "enable_snat": true,
"external_fixed_ips": [{"subnet_id": "88112ad5-d671-4e60-b347-362401606389",
"ip_address": "10.195.115.108"}]}, "description": "", "tags": [], "tenant_id":
"94ef30f2b49f420bae3cae2761b9e8d9", "created_at": "2017-09-14T11:19:35Z",
"admin_state_up": true, "distributed": false, "updated_at":
"2017-09-14T12:01:28Z", "revision_number": 25, "routes": [], "project_id":
"94ef30f2b49f420bae3cae2761b9e8d9", "id":
"a6f357f7-2383-4e77-9b8a-98a634214aeb", "name": "test-router"}}
The port needs to have tenant-id. The security group is not used
anywhere, so there's no point in creating it.
Version: Ocata
Linux distro: CentOS Linux release 7.3.1611
Deployment: Apex from OPNFV, which uses RDO
UPDATE: I've noticed this also happens to ports which correspond to floating
ips:
[root@overcloud-controller-0 ~]# neutron port-list
neutron CLI is deprecated and will be removed in the future. Use openstack
CLI instead.
+--+--+--+---+---+
| id | name | tenant_id
| mac_address | fixed_ips
|
+--+--+--+---+---+
| 0a068ffa-2188-4625-93bc-32fcb4900187 | |
| fa:16:3e:f8:ec:ef | {"subnet_id": "88112ad5-d671-4e60-b347-362401606389",
"ip_address": "10.195.115.100"} |
| 12485af0-a9aa-484c-acf3-2ea74718015d | |
94ef30f2b49f420bae3cae2761b9e8d9 | fa:16:3e:f6:8c:9f | {"subnet_id":
"8854242b-3306-402f-b1a3-d1fab2ecd781", "ip_address": "192.168.20.7"} |
| 46973789-8363-4e3b-9e66-59241d0a8224 | |
| fa:16:3e:3a:d0:c8 | {"subnet_id": "88112ad5-d671-4e60-b347-362401606389",
"ip_address": "10.195.115.103"} |
| 47b7b6c9-6f35-4e1d-ad57-905351285138 | |
94ef30f2b49f420bae3cae2761b9e8d9 | fa:16:3e:5d:79:28 | {"subnet_id":
"8854242b-3306-402f-b1a3-d1fab2ecd781", "ip_address": "192.168.20.11"} |
| 550d3f6d-967a-4087-b0a0-c3eacf5c588c | |
94ef30f2b49f420bae3cae2761b9e8d9 | fa:16:3e:f4:b2:00 | {"subnet_id":
"8854242b-3306-402f-b1a3-d1fab2ecd781", "ip_address": "192.168.20.2"} |
| fe34fd72-1251-4887-8b14-dbfdc4d3f3a7 | |
94ef30f2b49f420bae3cae2761b9e8d9 | fa:16:3e:4b:8d:fb | {"subnet_id":
"8854242b-3306-402f-b1a3-d1fab2ecd781", "ip_address": "192.168.20.1"} |
+--+--+--+---+---+
[root@overcloud-controller-0 ~]# neutron floatingip-list
neutron CLI is deprecated and will be removed in the future. Use openstack
CLI instead.
+--+--+--+-+--+
| id | tenant_id|
fixed_ip_address | floating_ip_address | port_id |
+--+--+--+-+--+
| 2d02e69d-cc83-4f66-beee-d4f1899fccfb | 94ef30f2b49f420bae3cae2761b9e8d9 |
192.168.20.7 | 10.195.115.100 | 12485af0-a9aa-484c-acf3-2ea74718015d |
[Yahoo-eng-team] [Bug 1703099] Re: Wiki Document Needs to be Updated
Looking at the parent page, https://wiki.openstack.org/wiki/Neutron I can see there is a note about the wiki being obsolete and to instead use https://docs.openstack.org/neutron/latest/ For that reason I'll close this since it would apply here as well. ** Changed in: neutron Status: New => 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/1703099 Title: Wiki Document Needs to be Updated Status in neutron: Won't Fix Bug description: The OpenStack wiki for Neutron with DVR available at https://wiki.openstack.org/wiki/Neutron/DVR needs to be updated as it still refers to the Juno release. Under the "Executive Summary" section, here is what it says: "The sole objective of this document is to set the context behind why the Neutron community focused some of its efforts on improving certain routing capabilities offered by the open source framework, and what users can expect to see when they get their hands on its latest release, aka Juno." To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1703099/+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 1709104] Re: cloud-init with only ipv6 Failes to POST encrypted password
As metadata over IPv6 is supported in the master branch, will close this as there is a workaround now. ** Changed in: neutron Status: New => 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/1709104 Title: cloud-init with only ipv6 Failes to POST encrypted password Status in neutron: Won't Fix Bug description: Release = newton When launching a Windows instance utilizing an IPv6-only network, cloudinit fails to post the encrypted (generated) password to the metadata service due to the absence of the metadata service on non- dual-stack/IPv4 probably To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1709104/+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 2003553] [NEW] Some port attributes are ignored in bulk port create: allowed_address_pairs, extra_dhcp_opts
Public bug reported:
It seems the bulk port create API ignores some of the port attributes it
receives:
export TOKEN="$( openstack token issue -f value -c id )"
# bulk equivalent of
# openstack --debug port create port0 --network private --allowed-address
ip-address=10.0.0.1,mac-address=01:23:45:67:89:ab
curl -s -H "Content-Type: application/json" -H "X-Auth-Token: $TOKEN" -d
"{\"ports\":[{\"name\":\"port0\",\"network_id\":\"$( openstack net show private
-f value -c id
)\",\"allowed_address_pairs\":[{\"ip_address\":\"10.0.0.1\",\"mac_address\":\"01:23:45:67:89:ab\"}]}]}"
-X POST http://127.0.0.1:9696/networking/v2.0/ports | json_pp
...
"allowed_address_pairs" : [],
...
# bulk equivalent of
# openstack --debug port create port0 --network private --extra-dhcp-option
name=domain-name-servers,value=10.0.0.1,ip-version=4
curl -s -H "Content-Type: application/json" -H "X-Auth-Token: $TOKEN" -d
"{\"ports\":[{\"name\":\"port0\",\"network_id\":\"$( openstack net show private
-f value -c id
)\",\"extra_dhcp_opts\":[{\"opt_name\":\"domain-name-servers\",\"opt_value\":\"10.0.0.1\",\"ip_version\":\"4\"}]}]}"
-X POST http://127.0.0.1:9696/networking/v2.0/ports | json_pp
...
"extra_dhcp_opts" : [],
...
neutron b71b25820be6d61ed9f249eddf32bfa49ac76524
** Affects: neutron
Importance: Undecided
Assignee: Bence Romsics (bence-romsics)
Status: New
** Tags: api
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2003553
Title:
Some port attributes are ignored in bulk port create:
allowed_address_pairs, extra_dhcp_opts
Status in neutron:
New
Bug description:
It seems the bulk port create API ignores some of the port attributes
it receives:
export TOKEN="$( openstack token issue -f value -c id )"
# bulk equivalent of
# openstack --debug port create port0 --network private --allowed-address
ip-address=10.0.0.1,mac-address=01:23:45:67:89:ab
curl -s -H "Content-Type: application/json" -H "X-Auth-Token: $TOKEN" -d
"{\"ports\":[{\"name\":\"port0\",\"network_id\":\"$( openstack net show private
-f value -c id
)\",\"allowed_address_pairs\":[{\"ip_address\":\"10.0.0.1\",\"mac_address\":\"01:23:45:67:89:ab\"}]}]}"
-X POST http://127.0.0.1:9696/networking/v2.0/ports | json_pp
...
"allowed_address_pairs" : [],
...
# bulk equivalent of
# openstack --debug port create port0 --network private --extra-dhcp-option
name=domain-name-servers,value=10.0.0.1,ip-version=4
curl -s -H "Content-Type: application/json" -H "X-Auth-Token: $TOKEN" -d
"{\"ports\":[{\"name\":\"port0\",\"network_id\":\"$( openstack net show private
-f value -c id
)\",\"extra_dhcp_opts\":[{\"opt_name\":\"domain-name-servers\",\"opt_value\":\"10.0.0.1\",\"ip_version\":\"4\"}]}]}"
-X POST http://127.0.0.1:9696/networking/v2.0/ports | json_pp
...
"extra_dhcp_opts" : [],
...
neutron b71b25820be6d61ed9f249eddf32bfa49ac76524
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2003553/+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 2003532] [NEW] Floating IP stuck in snat-ns after binding host to associated fixed IP
Public bug reported: We encountered a problem when the floating IP is not removed from the snat-ns when FIP is moving from the centralized to the distributed state (i.e. when the host is binding to the associated fixed IP address). This happens when the the fixed IP was originally created with a non-empty device_owner field. Steps to reproduce. Create a router, a port on a private network, and a FIP with this port as a fixed IP port: [root@devstack0 ~]# openstack router create --distributed r1 --external-gateway public [root@devstack0 ~]# openstack router add subnet r1 private [root@devstack0 ~]# openstack port create my-port --network private --device-owner compute:nova +--+---+ | Field| Value | +--+---+ | device_owner | compute:nova | | fixed_ips| ip_address='192.168.10.133', subnet_id='8ec1cd23-363a-474c-a53f-bab4692c312f' | +--+---+ [root@devstack0 ~]# openstack floating ip create public --port my-port -c floating_ip_address +-+---+ | Field | Value | +-+---+ | floating_ip_address | 10.136.17.171 | +-+---+ [root@devstack0 ~]# The FIP is added to the snat-ns: [root@devstack0 ~]# ip netns exec snat-b961c902-8cd9-4c5c-a03c-6595368a2314 ip a ... 38: qg-6a663b96-e1: mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether fa:16:3e:bf:85:ab brd ff:ff:ff:ff:ff:ff inet 10.136.17.175/20 brd 10.136.31.255 scope global qg-6a663b96-e1 valid_lft forever preferred_lft forever inet 10.136.17.171/32 brd 10.136.17.171 scope global qg-6a663b96-e1 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:febf:85ab/64 scope link valid_lft forever preferred_lft forever ... [root@devstack0 ~]# Create a VM with `my-port` and boot it on an another node: [root@devstack0 ~]# openstack server create vm --port my-port --image cirros-0.5.2-x86_64-disk --flavor 1 --host devstack2 Check FIP state on the node with VM (OK): [root@devstack2 ~]# ip netns exec qrouter-b961c902-8cd9-4c5c-a03c-6595368a2314 ip rule ... 65426: from 192.168.10.133 lookup 16 3232238081: from 192.168.10.1/24 lookup 3232238081 [root@devstack2 ~]# Check the FIP on the node with the snat-ns (not OK, it's still here): [root@devstack0 ~]# ip netns exec snat-b961c902-8cd9-4c5c-a03c-6595368a2314 ip a ... 38: qg-6a663b96-e1: mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether fa:16:3e:bf:85:ab brd ff:ff:ff:ff:ff:ff inet 10.136.17.175/20 brd 10.136.31.255 scope global qg-6a663b96-e1 valid_lft forever preferred_lft forever inet 10.136.17.171/32 brd 10.136.17.171 scope global qg-6a663b96-e1 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:febf:85ab/64 scope link valid_lft forever preferred_lft forever ... [root@devstack0 ~]# We found that FIP status "moving" notification is not sent to snat nodes in this scenario, see [1]. There was also some small discussion about why the notification should be sent only when changing from empty to a non-empty device_owner [2]. It looks like such behavior can be considered as a bug. [1] https://opendev.org/openstack/neutron/src/commit/c1eff1dd440b2243a4a31cf3c3af06a01e899f1d/neutron/db/l3_dvrscheduler_db.py#L647 [2] https://review.opendev.org/c/openstack/neutron/+/609924/10/neutron/db/l3_dvrscheduler_db.py#503 ** 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/2003532 Title: Floating IP stuck in snat-ns after binding host to associated fixed IP Status in neutron: New Bug description: We encountered a problem when the floating IP is not removed from the snat-ns when FIP is moving from the centralized to the distributed state (i.e. when the host is binding to the associated fixed IP address). This happens when the the fixed IP was originally created with a non-empty device_owner field. Steps to reproduce. Create a router, a port on a private network, and a FIP with this port as a fixed IP port: [root@devstack0 ~]# openstack router create --distributed r1 --external-gateway public [root@devstack0 ~]# openstack router add subnet r1 private [root@devstack0 ~]# openstack port create my-port --network private --device-owner compute:nova +--+---+ | Field| Value
[Yahoo-eng-team] [Bug 2003534] [NEW] neutron-keepalived-state-change unconditional debug mode
Public bug reported:
In line
https://opendev.org/openstack/neutron/src/branch/master/neutron/agent/l3/keepalived_state_change.py#L172
there is a `conf.set_override('debug', True)` which enables debug mode
for neutron-keepalived-state-change.
This means any setup by the operator in the configuration file is
ignored.
In certain scenarios the log can flood the system with messages like the
following:
Jan 18 00:16:57 cloudnet1005 neutron-keepalived-state-change: 2023-01-18
00:16:57.922 3355 DEBUG neutron.agent.linux.ip_lib [-] IP monitor
qrouter-d93771ba-2711-4f88-804a-8df6fd03978a; Adding IP address:
{'family': 2, '__pad': (), 'ifindex': 3, 'state': 16, 'flags': 0,
'ndm_type': 1, 'attrs': [('NDA_DST', '172.16.7.73'), ('NDA_LLADDR',
'fa:16:3e:5f:59:1d'), ('NDA_PROBES', 1), ('NDA_CACHEINFO',
{'ndm_confirmed': 4582, 'ndm_used': 241, 'ndm_updated': 0, 'ndm_refcnt':
2})], 'header': {'length': 76, 'type': 28, 'flags': 0,
'sequence_number': 0, 'pid': 0, 'error': None, 'target':
'qrouter-d93771ba-2711-4f88-804a-8df6fd03978a', 'stats': Stats(qsize=0,
delta=0, delay=0)}, 'event': 'RTM_NEWNEIGH'} to the queue.
read_ip_updates /usr/lib/python3/dist-
packages/neutron/agent/linux/ip_lib.py:1482
** 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/2003534
Title:
neutron-keepalived-state-change unconditional debug mode
Status in neutron:
New
Bug description:
In line
https://opendev.org/openstack/neutron/src/branch/master/neutron/agent/l3/keepalived_state_change.py#L172
there is a `conf.set_override('debug', True)` which enables debug mode
for neutron-keepalived-state-change.
This means any setup by the operator in the configuration file is
ignored.
In certain scenarios the log can flood the system with messages like
the following:
Jan 18 00:16:57 cloudnet1005 neutron-keepalived-state-change:
2023-01-18 00:16:57.922 3355 DEBUG neutron.agent.linux.ip_lib [-] IP
monitor qrouter-d93771ba-2711-4f88-804a-8df6fd03978a; Adding IP
address: {'family': 2, '__pad': (), 'ifindex': 3, 'state': 16,
'flags': 0, 'ndm_type': 1, 'attrs': [('NDA_DST', '172.16.7.73'),
('NDA_LLADDR', 'fa:16:3e:5f:59:1d'), ('NDA_PROBES', 1),
('NDA_CACHEINFO', {'ndm_confirmed': 4582, 'ndm_used': 241,
'ndm_updated': 0, 'ndm_refcnt': 2})], 'header': {'length': 76, 'type':
28, 'flags': 0, 'sequence_number': 0, 'pid': 0, 'error': None,
'target': 'qrouter-d93771ba-2711-4f88-804a-8df6fd03978a', 'stats':
Stats(qsize=0, delta=0, delay=0)}, 'event': 'RTM_NEWNEIGH'} to the
queue. read_ip_updates /usr/lib/python3/dist-
packages/neutron/agent/linux/ip_lib.py:1482
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2003534/+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 2003455] [NEW] [ovn] MTU issues due to centralized vlan provider networks
Public bug reported: After this change was added [1] the traffic gets centralized not only for vlan tenant networks, but also for vlan provider networks. This means that extra reduction on the MTU size needs to be done to account for the geneve encapsulation due to traffic going through the networker node instead of directly from the node [1] https://opendev.org/openstack/networking-ovn/commit/1440207c0d568068a37a306a7f03a81ad58e468f ** Affects: neutron Importance: Undecided Assignee: Luis Tomas Bolivar (ltomasbo) Status: New ** Changed in: neutron Assignee: (unassigned) => Luis Tomas Bolivar (ltomasbo) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2003455 Title: [ovn] MTU issues due to centralized vlan provider networks Status in neutron: New Bug description: After this change was added [1] the traffic gets centralized not only for vlan tenant networks, but also for vlan provider networks. This means that extra reduction on the MTU size needs to be done to account for the geneve encapsulation due to traffic going through the networker node instead of directly from the node [1] https://opendev.org/openstack/networking-ovn/commit/1440207c0d568068a37a306a7f03a81ad58e468f To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2003455/+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
