[Yahoo-eng-team] [Bug 1905268] [NEW] port list performance for trunks can be optimized
Public bug reported: Use case: many trunk ports each with many subports. Problem: port list takes much time. Reason: for each port trunk extension adds a DB call to retrieve subports mac addresses. Solution: retrieve subports info once when having a full list of trunk ports and hence full list of subport IDs. ** Affects: neutron Importance: Wishlist Assignee: Oleg Bondarev (obondarev) Status: Confirmed ** Tags: loadimpact -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1905268 Title: port list performance for trunks can be optimized Status in neutron: Confirmed Bug description: Use case: many trunk ports each with many subports. Problem: port list takes much time. Reason: for each port trunk extension adds a DB call to retrieve subports mac addresses. Solution: retrieve subports info once when having a full list of trunk ports and hence full list of subport IDs. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1905268/+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 1905271] [NEW] [OVS] Polling cycle continuously interrupted by L2 population (when enabled)
Public bug reported: The aim of this bug is just to document known issue when using L2 population and OVS agent. L2 population is needed, for example, when using tunnel protocol and DVR. If the OVS agent (compute node) is overloaded (too many ports VS one single threaded OVS agent), the polling cycle takes too much time (several minutes). During the processing time, the L2 population interruptions can delay even more the polling cycle conclusion. Although it is important to attend to the L2 population requests, it is more important to finish the port bindings first. Any additional processing, like attending to the L2 population requests, should be done at the end of the OVS agent polling cycle. ** 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/1905271 Title: [OVS] Polling cycle continuously interrupted by L2 population (when enabled) Status in neutron: New Bug description: The aim of this bug is just to document known issue when using L2 population and OVS agent. L2 population is needed, for example, when using tunnel protocol and DVR. If the OVS agent (compute node) is overloaded (too many ports VS one single threaded OVS agent), the polling cycle takes too much time (several minutes). During the processing time, the L2 population interruptions can delay even more the polling cycle conclusion. Although it is important to attend to the L2 population requests, it is more important to finish the port bindings first. Any additional processing, like attending to the L2 population requests, should be done at the end of the OVS agent polling cycle. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1905271/+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 1904751] Re: Neutron – it’s possible to delete router’s port related to external gateway
I tested this locally and it works for me, meaning I'm not able to
delete such a router interface. I also checked the patch
https://review.opendev.org/#/c/763198/ and it doesn't reach the part
where it tries to delete the interface, it fails much earlier:
2020-11-18 21:09:23.518 94641 INFO tempest.lib.common.rest_client
[req-ac30968f-2c73-469d-9b73-9aeee999a02a ] Request
(RoutersNegativePolicyTest:test_remove_associated_ports): 400 PUT
https://10.209.129.60:9696/v2.0/routers/1cef36f8-c0ea-43a9-a5ea-af8ea1efae42/add_router_interface
1.635s
2020-11-18 21:09:23.519 94641 DEBUG tempest.lib.common.rest_client
[req-ac30968f-2c73-469d-9b73-9aeee999a02a ] Request - Headers: {'Content-Type':
'application/json', 'Accept': 'application/json', 'X-Auth-Token': ''}
Body: {"subnet_id": "9804a35c-0d7e-4db0-95cf-b7c6485b295e"}
Response - Headers: {'date': 'Wed, 18 Nov 2020 21:09:23 GMT', 'server':
'Apache/2.4.41 (Ubuntu)', 'content-type': 'application/json', 'content-length':
'162', 'x-openstack-request-id': 'req-ac30968f-2c73-469d-9b73-9aeee999a02a',
'connection': 'close', 'status': '400', 'content-location':
'https://10.209.129.60:9696/v2.0/routers/1cef36f8-c0ea-43a9-a5ea-af8ea1efae42/add_router_interface'}
Body: b'{"NeutronError": {"type": "BadRequest", "message": "Bad router
request: Router already has a port on subnet
9804a35c-0d7e-4db0-95cf-b7c6485b295e.", "detail": ""}}' _log_request_full
/opt/stack/tempest/tempest/lib/common/rest_client.py:449
** 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/1904751
Title:
Neutron – it’s possible to delete router’s port related to external
gateway
Status in neutron:
Invalid
Bug description:
### Scenario ###
Create a router, set external gateway and add internal interface.
List router’s ports and try to delete them.
There is a patch you can use in order to reproduce the problem:
https://review.opendev.org/#/c/763198/
Note: it's also possible to reroduce the same problem with scenario script
(includes VM creation and connectivity check before and after deleting router's
port). As expected after port deletion connectivity check fails!
Just upload bug.py into the /home/stack/neutron-tempest-plugin on your
undercloud host and run it with:
python3 -m testtools.run
neutron_tempest_plugin.scenario.bug.RoutersTest.test_delete_router
### Actual result ###
Port related to external gateway is successfully deleted.
### Expected ###
Should fail
### Test patch output in tempest.log ###
It's possible to see that the list containing routers port IDs is changed
from:
['74abfbfa-3e60-4b6f-971c-5224dd74db2f',
'af0a74a0-2b14-499a-a871-96e5d804da15']
to:
['74abfbfa-3e60-4b6f-971c-5224dd74db2f']
means that the port was deleted.
2020-11-18 10:41:47.998 95480 INFO tempest.lib.common.rest_client
[req-cca60a65-1ce0-46f4-8d58-b5177f256115 ] Request
(RoutersNegativePolicyTest:test_remove_associated_ports): 200 GET
http://10.0.0.109:9696/v2.0/routers/0e7fbc2d-d42b-43d2-873f-5311af9e5c96 0.446s
2020-11-18 10:41:51.676 95480 INFO tempest.lib.common.rest_client
[req-1ab5e603-95f9-4cc0-9497-11346dae7c51 ] Request
(RoutersNegativePolicyTest:test_remove_associated_ports): 200 PUT
http://10.0.0.109:9696/v2.0/routers/0e7fbc2d-d42b-43d2-873f-5311af9e5c96 3.676s
2020-11-18 10:41:55.970 95480 INFO tempest.lib.common.rest_client
[req-e51bc925-41d3-46f3-81a3-ff80e5735e9f ] Request
(RoutersNegativePolicyTest:test_remove_associated_ports): 200 PUT
http://10.0.0.109:9696/v2.0/routers/0e7fbc2d-d42b-43d2-873f-5311af9e5c96/add_router_interface
4.292s
2020-11-18 10:41:56.046 95480 INFO tempest.lib.common.rest_client
[req-2fa43806-cbcb-4d3a-93cc-019c98ad2b94 ] Request
(RoutersNegativePolicyTest:test_remove_associated_ports): 200 GET
http://10.0.0.109:9696/v2.0/ports?router_id=0e7fbc2d-d42b-43d2-873f-5311af9e5c96
0.075s
2020-11-18 10:41:56.047 95480 INFO
neutron_tempest_plugin.api.test_routers_negative [-]
test_remove_associated_ports ['74abfbfa-3e60-4b6f-971c-5224dd74db2f',
'af0a74a0-2b14-499a-a871-96e5d804da15']
2020-11-18 10:41:56.128 95480 INFO tempest.lib.common.rest_client
[req-fbed6aa9-0d27-47ec-9614-38f72b1ace20 ] Request
(RoutersNegativePolicyTest:test_remove_associated_ports): 200 GET
http://10.0.0.109:9696/v2.0/ports/74abfbfa-3e60-4b6f-971c-5224dd74db2f 0.080s
2020-11-18 10:41:56.129 95480 INFO
neutron_tempest_plugin.api.test_routers_negative [-]
test_remove_associated_portsresponse: {'content-type': 'application/json',
'content-length': '898', 'x-openstack-request-id':
'req-fbed6aa9-0d27-47ec-9614-38f72b1ace20', 'date': 'Wed, 18 Nov 2020 15:41:56
GMT', 'connection': 'close', 'status': '200', 'content-location':
'http://10.0.0.109:9696/v2.0/ports/74abfbfa-3e60-4b6f-971c-5224dd74db2f'}
2020-11-18 10:41:56.424 95480 INFO tempest.lib
[Yahoo-eng-team] [Bug 1905276] [NEW] Overriding hypervisor name for resource provider always requires a complete list of interfaces/bridges
Public bug reported: In some deployments, hostnames can be different between hosts and resource provider records. For example in deployment managed by TripleO we use short host name (without domain name) in host, while we use FQDN for resource provider records (this comes from the FQDN set to the host option in nova.conf). This causes an issue with the way how currently neutron looks up the root resource provider because placment API requires the exact hostname and doesn't automatically translate short name and FQDN. To fix the issue we need to set the resource_provider_hypervisors option[1] now but it is very redundant to list up all devices or bridges in this option to override hostnames for the devices/bridges by the same value. [1] https://review.opendev.org/#/c/696600/ ** Affects: neutron Importance: Undecided Status: New ** Summary changed: - Overriding defualt hypervisor name always requires a complete list of interfaces/bridges + Overriding hypervisor name for resource provider management always requires a complete list of interfaces/bridges ** Summary changed: - Overriding hypervisor name for resource provider management always requires a complete list of interfaces/bridges + Overriding hypervisor name for resource provider always requires a complete list of interfaces/bridges -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1905276 Title: Overriding hypervisor name for resource provider always requires a complete list of interfaces/bridges Status in neutron: New Bug description: In some deployments, hostnames can be different between hosts and resource provider records. For example in deployment managed by TripleO we use short host name (without domain name) in host, while we use FQDN for resource provider records (this comes from the FQDN set to the host option in nova.conf). This causes an issue with the way how currently neutron looks up the root resource provider because placment API requires the exact hostname and doesn't automatically translate short name and FQDN. To fix the issue we need to set the resource_provider_hypervisors option[1] now but it is very redundant to list up all devices or bridges in this option to override hostnames for the devices/bridges by the same value. [1] https://review.opendev.org/#/c/696600/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1905276/+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 1904751] Re: Neutron – it’s possible to delete router’s port related to external gateway
OK, In fact I didn't mention a few important things, sorry for that :-((
1) Tested on: RHOS-16.1-RHEL-8-20201110.n.1
2) This bug is about API only, you aren't able to delete the External Gateway
using Openstack CLI commands, so I guess that this is why Jacub wasn't able to
reproduce the issue.
I've tried to dig out and to see why the test patch failed much more
earlier (as mentioned by Jacub) without success, but I saw that it
failed on line:102, actually this line is just adding a port to the
router and this port is failed to be deleted latter on as expected (not
problematical port), so I decided to comment out this line as
problematical port is related to External Gateway.
New patch is available and should fail for you with:
testtools.matchers._impl.MismatchError:
['82dc1b3f-ef20-4694-a6fe-6acd08d4916c'] != []: The number of ports before and
after delete is expected to be the same number!
This message indicates that the only port that was associated with
router (External Gateway Port) was actually removed without any problem.
** Changed in: neutron
Status: Invalid => 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/1904751
Title:
Neutron – it’s possible to delete router’s port related to external
gateway
Status in neutron:
New
Bug description:
### Scenario ###
Create a router, set external gateway and add internal interface.
List router’s ports and try to delete them.
There is a patch you can use in order to reproduce the problem:
https://review.opendev.org/#/c/763198/
Note: it's also possible to reroduce the same problem with scenario script
(includes VM creation and connectivity check before and after deleting router's
port). As expected after port deletion connectivity check fails!
Just upload bug.py into the /home/stack/neutron-tempest-plugin on your
undercloud host and run it with:
python3 -m testtools.run
neutron_tempest_plugin.scenario.bug.RoutersTest.test_delete_router
### Actual result ###
Port related to external gateway is successfully deleted.
### Expected ###
Should fail
### Test patch output in tempest.log ###
It's possible to see that the list containing routers port IDs is changed
from:
['74abfbfa-3e60-4b6f-971c-5224dd74db2f',
'af0a74a0-2b14-499a-a871-96e5d804da15']
to:
['74abfbfa-3e60-4b6f-971c-5224dd74db2f']
means that the port was deleted.
2020-11-18 10:41:47.998 95480 INFO tempest.lib.common.rest_client
[req-cca60a65-1ce0-46f4-8d58-b5177f256115 ] Request
(RoutersNegativePolicyTest:test_remove_associated_ports): 200 GET
http://10.0.0.109:9696/v2.0/routers/0e7fbc2d-d42b-43d2-873f-5311af9e5c96 0.446s
2020-11-18 10:41:51.676 95480 INFO tempest.lib.common.rest_client
[req-1ab5e603-95f9-4cc0-9497-11346dae7c51 ] Request
(RoutersNegativePolicyTest:test_remove_associated_ports): 200 PUT
http://10.0.0.109:9696/v2.0/routers/0e7fbc2d-d42b-43d2-873f-5311af9e5c96 3.676s
2020-11-18 10:41:55.970 95480 INFO tempest.lib.common.rest_client
[req-e51bc925-41d3-46f3-81a3-ff80e5735e9f ] Request
(RoutersNegativePolicyTest:test_remove_associated_ports): 200 PUT
http://10.0.0.109:9696/v2.0/routers/0e7fbc2d-d42b-43d2-873f-5311af9e5c96/add_router_interface
4.292s
2020-11-18 10:41:56.046 95480 INFO tempest.lib.common.rest_client
[req-2fa43806-cbcb-4d3a-93cc-019c98ad2b94 ] Request
(RoutersNegativePolicyTest:test_remove_associated_ports): 200 GET
http://10.0.0.109:9696/v2.0/ports?router_id=0e7fbc2d-d42b-43d2-873f-5311af9e5c96
0.075s
2020-11-18 10:41:56.047 95480 INFO
neutron_tempest_plugin.api.test_routers_negative [-]
test_remove_associated_ports ['74abfbfa-3e60-4b6f-971c-5224dd74db2f',
'af0a74a0-2b14-499a-a871-96e5d804da15']
2020-11-18 10:41:56.128 95480 INFO tempest.lib.common.rest_client
[req-fbed6aa9-0d27-47ec-9614-38f72b1ace20 ] Request
(RoutersNegativePolicyTest:test_remove_associated_ports): 200 GET
http://10.0.0.109:9696/v2.0/ports/74abfbfa-3e60-4b6f-971c-5224dd74db2f 0.080s
2020-11-18 10:41:56.129 95480 INFO
neutron_tempest_plugin.api.test_routers_negative [-]
test_remove_associated_portsresponse: {'content-type': 'application/json',
'content-length': '898', 'x-openstack-request-id':
'req-fbed6aa9-0d27-47ec-9614-38f72b1ace20', 'date': 'Wed, 18 Nov 2020 15:41:56
GMT', 'connection': 'close', 'status': '200', 'content-location':
'http://10.0.0.109:9696/v2.0/ports/74abfbfa-3e60-4b6f-971c-5224dd74db2f'}
2020-11-18 10:41:56.424 95480 INFO tempest.lib.common.rest_client
[req-61c2a22a-0db2-4cbb-a934-671e979d6b44 ] Request
(RoutersNegativePolicyTest:test_remove_associated_ports): 409 DELETE
http://10.0.0.109:9696/v2.0/ports/74abfbfa-3e60-4b6f-971c-5224dd74db2f 0.294s
2020-11-18 10:41:56.425 95480 ERROR
neutron_tempest_plugin.api.test_routers_negative [-]
test_remove_associated_portsConflict with state of target resource
2020-11-18 10:41:56.504 95480 INFO tempest.lib.common.rest_c
[Yahoo-eng-team] [Bug 1761798] Re: live migration intermittently fails in CI with "VQ 0 size 0x80 Guest index 0x12c inconsistent with Host index 0x134: delta 0xfff8"
Source node
https://zuul.opendev.org/t/openstack/build/d50877ae15db4022b82f4bb1d1d52cea/log/logs/subnode-2/libvirt/qemu/instance-001a.txt
2020-11-20 14:25:24.887+: starting up libvirt version: 6.0.0,
package: 0ubuntu8.4~cloud0 (Openstack Ubuntu Testing Bot Tue, 15 Sep 2020 20:36:28 +), qemu version:
4.2.1Debian 1:4.2-3ubuntu6.7~cloud0, kernel: 4.15.0-124-generic,
hostname: ubuntu-bionic-ovh-bhs1-0021872195
LC_ALL=C \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
HOME=/var/lib/libvirt/qemu/domain-19-instance-001a \
XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-19-instance-
001a/.local/share \
XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-19-instance-001a/.cache
\
XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-19-instance-
001a/.config \
QEMU_AUDIO_DRV=none \
/usr/bin/qemu-system-x86_64 \
-name guest=instance-001a,debug-threads=on \
-S \
-object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-19
-instance-001a/master-key.aes \
-machine pc-i440fx-4.2,accel=tcg,usb=off,dump-guest-core=off \
-cpu qemu64,hypervisor=on,lahf-lm=on \
-m 128 \
-overcommit mem-lock=off \
-smp 1,sockets=1,cores=1,threads=1 \
-uuid 2c468d92-4b19-426a-8c25-16b4624c21a4 \
-smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack
Nova,version=22.1.0,serial=2c468d92-4b19-426a-
8c25-16b4624c21a4,uuid=2c468d92-4b19-426a-
8c25-16b4624c21a4,family=Virtual Machine' \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=35,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc \
-no-shutdown \
-boot strict=on \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-blockdev
'{"driver":"file","filename":"/opt/stack/data/nova/instances/_base/61bd5e531ab4c82456aa5300ede7266b3610be79
","node-name":"libvirt-2-storage","cache":{"direct":true,"no-
flush":false},"auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"libvirt-2-format","read-
only":true,"cache":{"direct":true,"no-
flush":false},"driver":"raw","file":"libvirt-2-storage"}' \
-blockdev
'{"driver":"file","filename":"/opt/stack/data/nova/instances/2c468d92-4b19
-426a-8c25-16b4624c21a4/disk","node-
name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false
},"auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"libvirt-1-format","read-
only":false,"cache":{"direct":true,"no-
flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-2-format"}'
\
-device virtio-blk-
pci,scsi=off,bus=pci.0,addr=0x4,drive=libvirt-1-format,id=virtio-
disk0,bootindex=1,write-cache=on \
-netdev tap,fd=37,id=hostnet0 \
-device virtio-net-
pci,host_mtu=1400,netdev=hostnet0,id=net0,mac=fa:16:3e:43:11:f4,bus=pci.0,addr=0x3
\
-add-fd set=2,fd=39 \
-chardev pty,id=charserial0,logfile=/dev/fdset/2,logappend=on \
-device isa-serial,chardev=charserial0,id=serial0 \
-vnc 127.0.0.1:0 \
-device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \
-incoming defer \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \
-object rng-random,id=objrng0,filename=/dev/urandom \
-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x6 \
-sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
\
-msg timestamp=on
char device redirected to /dev/pts/2 (label charserial0)
virtio: bogus descriptor or out of resources
2020-11-20 14:25:39.911+: initiating migration
2020-11-20T14:26:21.409517Z qemu-system-x86_64: terminating on signal 15
from pid 17395 (/usr/sbin/libvirtd)
2020-11-20 14:26:21.610+: shutting down, reason=destroyed
Target node
https://zuul.opendev.org/t/openstack/build/d50877ae15db4022b82f4bb1d1d52cea/log/logs/libvir
t/qemu/instance-001a.txt
2020-11-20 14:25:11.589+: starting up libvirt version: 6.0.0,
package: 0ubuntu8.4~cloud0 (Openstack Ubuntu Testing Bot Tue, 15 Sep 2020 20:36:28 +), qemu version:
4.2.1Debian 1:4.2-3ubuntu6.7~cloud0, kernel: 4.15.0-124-generic,
hostname: ubuntu-bionic-ovh-bhs1-0021872194
LC_ALL=C \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
HOME=/var/lib/libvirt/qemu/domain-10-instance-001a \
XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-10-instance-
001a/.local/share \
XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-10-instance-001a/.cache
\
XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-10-instance-
001a/.config \
QEMU_AUDIO_DRV=none \
/usr/bin/qemu-system-x86_64 \
-name guest=instance-001a,debug-threads=on \
-S \
-object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-10
-instance-001a/master-key.aes \
-machine pc-i440fx-4.2,accel=tcg,usb=off,dump-guest-core=off \
-cpu qemu64 \
-m 128 \
-overcommit mem-lock=off \
-smp 1,sockets=1,cores=1,threads=1 \
-uuid 2c468d92-4b19-426a-8c25-16b4624c21a4 \
-smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack
Nova,version=22.1.0,serial=2c468d92-4b19-426a-
8c25-16b4624c21a4,uuid=2c468d92-4b19-426a-
8c25-16b4624c21
[Yahoo-eng-team] [Bug 1905295] [NEW] [RFE] Allow multiple external gateways on a router
Public bug reported:
I'd like to bring the following idea to the drivers' meeting. If this
still looks like a good idea after that discussion, I'll open a spec so
this can be properly commented on in gerrit. Until then feel free to
comment here of course.
# Problem Description
A general router can be configured to connect and route to multiple
external networks for higher availability and/or to balance the load.
However the current Neutron API syntax allows exactly one external
gateway for a router.
https://docs.openstack.org/api-ref/network/v2/?expanded=create-router-
detail#create-router
{
"router": {
"name": "router1",
"external_gateway_info": {
"network_id": "ae34051f-aa6c-4c75-abf5-50dc9ac99ef3",
"enable_snat": true,
"external_fixed_ips": [
{
"ip_address": "172.24.4.6",
"subnet_id": "b930d7f6-ceb7-40a0-8b81-a425dd994ccf"
}
]
},
"admin_state_up": true
}
}
However consider the following (simplified) network architecture as an
example:
R3 R4
|X|
R1 R2
|X|
C1 C2 ...
(Sorry, my original, nice ascii art was eaten by launchpad. I hope this
still conveys what I mean.)
Where C1, C2, ... are compute nodes, R1 and R2 are OpenStack-managed
routers, while R3 and R4 are provider edge routers. Between R1-R2 and
R3-R4 Equal Cost Multipath (ECMP) routing is used to utilize all links
in an active-active manner. In such an architecture it makes sense to
represent R1 and R2 as 2 logical routers with 2-2 external gateways, or
in some cases (depending on other architectural choices) even as 1
logical router with 4 external gateways. But with the current API that
is not possible.
# Proposed Change
Extend the router API object with a new attribute
'additional_external_gateways', for example:
{
"router" : {
"name" : "router1",
"admin_state_up" : true,
"external_gateway_info" : {
"enable_snat" : false,
"external_fixed_ips" : [
{
"ip_address" : "172.24.4.6",
"subnet_id" : "b930d7f6-ceb7-40a0-8b81-a425dd994ccf"
}
],
"network_id" : "ae34051f-aa6c-4c75-abf5-50dc9ac99ef3"
},
"additional_external_gateways" : [
{
"enable_snat" : false,
"external_fixed_ips" : [
{
"ip_address" : "172.24.5.6",
"subnet_id" : "62da64b0-29ab-11eb-9ed9-3b1175418487"
}
],
"network_id" : "592d4716-29ab-11eb-a7dd-4f4b5e319915"
},
...
]
}
}
Edited via the following HTTP PUT methods with diff semantics:
PUT /v2.0/routers/{router_id}/add_additional_external_gateways
PUT /v2.0/routers/{router_id}/remove_additional_external_gateways
We keep 'external_gateway_info' for backwards compatibility. When
additional_external_gateways is an empty list, everything behaves as
before. When additional_external_gateways are given, then the actual
list of external gateways is (in Python-like pseudo-code):
[external_gateway_info] + additional_external_gateways.
Unless otherwise specified all non-directly connected external IPs are
routed towards the original external_gateway_info. However this behavior
may be overriden by either using (static) extraroutes, or by running ()
routing protocols and routing towards the external gateway where a
particular route was learned from.
# Alternatives
1) Using 4 logical routers with 1 external gateway each. However in this
case the API misses the information which (2 or 4) logical routers
represent the same backend router.
2) Using a VRRP HA router. However this provides a different level of
High Availability plus it is active-passive instead of active-active.
3) Adding router interfaces (since their number is not limited in the
API) instead of external gateways. However this creates confusion by
blurring the line of what is internal and what is external to the cloud
deployment.
** Affects: neutron
Importance: Wishlist
Assignee: Bence Romsics (bence-romsics)
Status: New
** Tags: rfe
** Description changed:
I'd like to bring the following idea to the drivers' meeting. If this
still looks like a good idea after that discussion, I'll open a spec so
this can be properly commented on in gerrit. Until then feel free to
comment here of course.
# Problem Description
A general router can be configured to connect and route to multiple
external networks for higher availability and/or to balance the load.
However the current Neutron API syntax allows exactly one external
gateway for a router.
https://docs.openstack.org/api-ref/network/v2/?expanded=create-router-
detail#create-router
{
- "router": {
- "name": "router1",
- "external_gateway_info": {
- "network_id": "ae34051f-aa6c-4c75-abf5-50dc9ac99ef3",
- "en
[Yahoo-eng-team] [Bug 1848851] Re: move fwaas_v2_log constants to neutron-lib
Marking 'Won't Fix" because fo the deprecation of the neutron-fwaas project. ** 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/1848851 Title: move fwaas_v2_log constants to neutron-lib Status in neutron: Won't Fix Bug description: sg logging constants has been moved to neutron-lib,related patches[1] https://review.opendev.org/#/c/645885/ I think fw logging constants can alse be moved to neutron-lib. In addtion. FIREWALL_LOG_DRIVER_NAME(TODO) can also be moved to neutron-lib. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1848851/+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 1905358] [NEW] cloud-init fails to configure a bond on CentOS 8
Public bug reported: On a test system I configured a machine with a bond. Curtin successfully installed CentOS 8 but the deployment failed in MAAS. When I dug in it is because the bond never comes up so the machine has no way to communicate with MAAS. I can deploy the same machine with a bond on CentOS 7 or Ubuntu. I can also deploy with CentOS 8 using DHCP, static IP, or a bridge, just not a bond. MAAS: 2.9.0-rc1 CentOS 8 image from images.maas.io cloud-init-19.4-1.el8.7.noarch ** 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/1905358 Title: cloud-init fails to configure a bond on CentOS 8 Status in cloud-init: New Bug description: On a test system I configured a machine with a bond. Curtin successfully installed CentOS 8 but the deployment failed in MAAS. When I dug in it is because the bond never comes up so the machine has no way to communicate with MAAS. I can deploy the same machine with a bond on CentOS 7 or Ubuntu. I can also deploy with CentOS 8 using DHCP, static IP, or a bridge, just not a bond. MAAS: 2.9.0-rc1 CentOS 8 image from images.maas.io cloud-init-19.4-1.el8.7.noarch To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1905358/+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
