February 2021 - openstack-discuss

[oslo] February 15th meeting is canceled
by Herve Beraud 12 Feb '21

12 Feb '21

Hello Osloers, I will be on PTO next Monday so I won't be around to run the meeting. If someone else from the Oslo team wants to run it, please feel free. See you on Tuesday -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[stein][kolla][haproxy] Waiting for virtual ip to appear
by roshan anvekar 12 Feb '21

12 Feb '21

Hi Folks, I am deploying a multinode Openstack cluster using kolla-ansible. *Network composition:* *Bond0: *network_interface/kolla_internal_vip_address *Bond1.101: *kolla_external_vip_address/interface Bond1 also had br-ex ovs bridge configured on it directly. *Bond2: *storage interface With this config I am trying to deploy through kolla. The deployment repeatedly fails at HAproxy: waiting for internal IP to appear or mariadb trying to be active via haproxy. Not sure what's the cause of this. I have given unique keepalive_id too. Generated proper passwords as required by stein. Haproxy is not generating any logs too yet. Any help would be appreciated. Regards, Roshan

2 2

[victoria][octavia] Operating status OFFLINE
by Malik Obaid 12 Feb '21

12 Feb '21

Hi, I have configured Octavia using Openstack Victoria release on Ubuntu 20.04. Everything is working as expected like loadbalancing, healthmonitoring etc. The issue I am facing is that the operating_status of Loadbalancer, listener, pool and its members always stay OFFLINE. I am new to Openstack and would really appreciate your help in this regard. ------------------------------------------------------------------------- loadbalancer status: { "loadbalancer": { "id": "b33d7de7-4bf6-4815-a151-5ca7a7a3a40e", "name": "testlb", "operating_status": "OFFLINE", "provisioning_status": "ACTIVE", "listeners": [ { "id": "03972160-dd11-4eac-855b-870ee9ee909b", "name": "testlistener", "operating_status": "OFFLINE", "provisioning_status": "ACTIVE", "pools": [ { "id": "5ad57d34-a9e7-4aa1-982d-e528b38c84ed", "name": "testpool", "provisioning_status": "ACTIVE", "operating_status": "OFFLINE", "health_monitor": { "id": "3524ea0f-ce2b-4957-9967-27d71033f964", "name": "testhm", "type": "HTTP", "provisioning_status": "ACTIVE", "operating_status": "ONLINE" }, "members": [ { "id": "25b94432-6464-4245-a5db-6ecedb286721", "name": "", "operating_status": "OFFLINE", "provisioning_status": "ACTIVE", "address": "192.168.100.44", "protocol_port": 80 }, { "id": "9157600c-280e-4eb9-a9aa-6b683da76420", "name": "", "operating_status": "OFFLINE", "provisioning_status": "ACTIVE", "address": "192.168.100.90", "protocol_port": 80 } ] } ] } ] } } ---------------------------------------------------------------------------- ------------ octavia.conf #create new [DEFAULT] # RabbitMQ connection info transport_url = rabbit://openstack:password@172.16.30.46 [api_settings] # IP address this host listens bind_host = 172.16.30.46 bind_port = 9876 auth_strategy = keystone api_base_uri = http://172.16.30.46:9876 # MariaDB connection info [database] connection = mysql+pymysql://octavia:password@172.16.30.45/octavia [health_manager] bind_ip = 172.16.30.46 bind_port = 5555 controller_ip_port_list = 127.0.0.1:5555, 172.16.30.46:5555 #healthcheck_enabled = True [healthcheck] backends = octavia_db_check #debug = true # Keystone auth info [keystone_authtoken] www_authenticate_uri = http://172.16.30.46:5000 auth_url = http://172.16.30.46:5000 memcached_servers = 172.16.30.46:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = octavia password = servicepassword # specify certificates created on [2] [certificates] ca_private_key = /etc/octavia/certs/private/server_ca.key.pem ca_certificate = /etc/octavia/certs/server_ca.cert.pem server_certs_key_passphrase = insecure-key-do-not-use-this-key ca_private_key_passphrase = not-secure-passphrase # specify certificates created on [2] [haproxy_amphora] server_ca = /etc/octavia/certs/server_ca-chain.cert.pem client_cert = /etc/octavia/certs/private/client.cert-and-key.pem # specify certificates created on [2] [controller_worker] client_ca = /etc/octavia/certs/client_ca.cert.pem amp_image_tag = Amphora # specify [flavor] ID for Amphora instance amp_flavor_id = 200 # specify security group ID Amphora instance amp_secgroup_list = 4fcb5a29-06b3-4a5d-8804-23c4670c200e # specify network ID to boot Amphora instance (example below specifies public network [public]) amp_boot_network_list = 7d6af354-206f-4c30-a0d6-dcf0f7f35f08 network_driver = allowed_address_pairs_driver compute_driver = compute_nova_driver amphora_driver = amphora_haproxy_rest_driver [oslo_messaging] topic = octavia_prov # Keystone auth info [service_auth] auth_url = http://172.16.30.46:5000 memcached_servers = 172.16.30.46:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = octavia password = servicepassword ----------------------------------------------------------------------- Regards, Malik Obaid

1 0

Openstack cannot access to the Internet
by Jaime 12 Feb '21

12 Feb '21

# Openstack instances cannot access Internet [linuxbridge] I am having serious issues in the deployment of the Openstack scenario related to the Linux Bridge. This is the scenario: - Controller machine: - Management Interface `enp2s0`: 138.100.10.25. - Compute machine: - Management Interface `enp2s0`: 138.100.10.26. - Provider Interface `enp0s20f0u4`: 138.100.10.27. Openstack Train scenario has been successfully deployed in Centos 8, choosing networking option 2 (self-service network). To verify the functionality, an image has been uploaded, created an Openstack flavor and security group, and launched a couple of cirrOS instances for connection testing. We have created a provider network following [this tutorial](https://docs.openstack.org/newton/install-guide-rdo/launch-instan… and a selfservice network following [this one](https://docs.openstack.org/newton/install-guide-rdo/launch-instance-ne…. The network scenario is the next one: As can be seen in the network topology, an external network 138.100.10.0/21 (provider) and an internal network 192.168.1.1 (selfservice) have been created, connected through a router by the interfaces 138.100.10.198 and 192.168.1.1, both active. Our problem is that our Linux bridge is not working as expected: the Openstack cirrOS instances has no internet access. This is the controller `ip a` and `brctl show` command output: This is the compute `ip a` and `brctl show` command output: (The output of `ovs-vsctl show` command is empty in both machines). **Are the Linux Bridges correctly created?** These are the Linux bridge configuration files: * Controller `/etc/neutron/plugins/ml2/linuxbridge_agent.ini`: ``` [linux_bridge] physical_interface_mappings = provider:enp2s0 # enp2s0 is the interface associated to 138.100.10.25 [vxlan] enable_vxlan = true local_ip = 138.100.10.25 # controller has only 1 IP l2_population = true ``` * Compute `/etc/neutron/plugins/ml2/linuxbridge_agent.ini`: ``` [linux_bridge] physical_interface_mappings = provider:enp0s20f0u4 # interface associated to 138.100.10.26 [vxlan] enable_vxlan = true local_ip = 138.100.10.27 l2_population = true ``` An **observation** to keep in mind is that compute management interface (`138.100.10.26`) is inaccessible from anywhere, which I think is not correct since this prevents us, for example, from accessing the instance console through the URL. I have made some conection tests and these are the results: - There is **connection** between Cirros A and Cirros B (in both directions). - There is **connection** between Cirros A/B and self-service gateway (192.168.1.1) (in both directions). - There is **connection** between Cirros A/B and provider gateway (138.100.10.198) (in both directions). - There is **connection** between Cirros A/B and controller management interface (138.100.10.25) (in both directions). - There is **no connection** between Cirros A/B and compute management interface (138.100.10.26). This interface is not accessible. - There is **connection** between Cirros A/B and compute provider interface (138.100.10.27) (in both directions). I do not know if there is a problem on Linux bridge configuration files, or maybe I need another network interface on controller machine.

3 3

[tripleo][ci] post failures, storage related
by Wesley Hayutin 11 Feb '21

11 Feb '21

FYI.. There is currently an issue w/ the log storage upstream across all openstack jobs it seems. Working w/ infra atm. See #openstack-infra for details Related tracking bug: https://bugs.launchpad.net/tripleo/+bug/1915415 Thanks all! We'll keep you posted.

3 3

[cinder] festival of XS reviews 19 Feb 2021
by Brian Rosmaita 11 Feb '21

11 Feb '21

Hello Cinder community members, At the R-9 mid-cycle yesterday, Eric pointed out that we have a bunch of XS reviews piling up that we should be able to knock out fairly quickly, and either Alan or Jay suggested that we steal the "review jam" idea from the ironic team. So we will hold a Cinder Festival of XS Reviews on Friday next week. what: Cinder Festival of XS Reviews when: Friday 19 February 2021 from 1400-1600 UTC where: https://bluejeans.com/3228528973 See you there! brian

1 0

[tripleo] next irc meeting Tuesday Feb 16 @ 1400 UTC in #tripleo
by Marios Andreou 11 Feb '21

11 Feb '21

Reminder that the next TripleO irc meeting is: ** Tuesday 16 February at 1400 UTC in #tripleo ** ** https://wiki.openstack.org/wiki/Meetings/TripleO ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add anything you want to hilight at https://etherpad.opendev.org/p/tripleo-meeting-items This can include recently completed things, ongoing review requests, blocking issues, or anything else tripleo you'd like to share. Our last meeting was on Feb 02 - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-02-02-14.… Hope you can make it on Tuesday, thanks, marios

1 0

[tripleo][ci] socializing upstream job removal ( master upgrade, scenario010 )
by Wesley Hayutin 11 Feb '21

11 Feb '21

Greetings, Expect to see several of these emails as we propose additional items to reduce the upstream resource footprint of TripleO. The intent of the email is to broadcast our general intent regarding specific ci jobs with some details regarding the how and when things will happen. Expect jobs to be removed in a staged pragmatic manner. Historical Context [1] Please feel free to respond to this thread with your opinions. Summary: First stage of TripleO's job reduction will be to remove most TripleO upgrade jobs on master and remove all scenario010 octavia jobs from upstream. *Upgrade jobs in master:* All the upgrade jobs in master are non-voting based on policy and to give the upgrade developers time to compensate for new developments and features. The feedback provided by CI can still occur in our periodic jobs in RDO's software factory zuul. Upgrade jobs will remain running in periodic but removed from upstream. Specifically: ( master ) tripleo-ci-centos-8-standalone-upgrade tripleo-ci-centos-8-undercloud-upgrade tripleo-ci-centos-8-scenario000-multinode-oooq-container-upgrades I'll note there is interest in keeping the undercloud-upgrade, however we are able to remove all the upgrade jobs for a branch in the upstream we can also remove a content-provider job. I would encourage folks to consider undercloud-upgrade for periodic only. *Scenario010 - Octavia:* Scenario010 octavia has been non-voting and not passing at a high enough rate [2] to justify the use of upstream resources. I would propose we only run these jobs in the periodic component and integration lines in RDO softwarefactory. Specifically: ( all branches ) tripleo-ci-centos-8-scenario010-ovn-provider-standalone tripleo-ci-centos-8-scenario010-standalone Please review and comment. The CI team will start taking action on these two items in one week. Thank you! [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020235… [2] http://dashboard-ci.tripleo.org/d/iEDLIiOMz/non-voting-jobs?orgId=1&from=no…

6 6

Openstack instances cannot access to Internet [linuxbridge]
by Jaime 11 Feb '21

11 Feb '21

I am having serious issues in the deployment of the Openstack scenario related to the Linux Bridge. This is the scenario: - Controller machine: - Management Interface `enp2s0`: 138.100.10.25. - Compute machine: - Management Interface `enp2s0`: 138.100.10.26. - Provider Interface `enp0s20f0u4`: 138.100.10.27. Openstack Train scenario has been successfully deployed in Centos 8, choosing networking option 2 (self-service network). To verify the functionality, an image has been uploaded, created an Openstack flavor and security group, and launched a couple of cirrOS instances for connection testing. We have created a provider network following [this tutorial](https://docs.openstack.org/newton/install-guide-rdo/launch-instan… and a selfservice network following [this one](https://docs.openstack.org/newton/install-guide-rdo/launch-instance-ne…. The network scenario is the next one: As can be seen in the network topology, an external network 138.100.10.0/21 (provider) and an internal network 192.168.1.1 (selfservice) have been created, connected through a router by the interfaces 138.100.10.198 and 192.168.1.1, both active. Our problem is that our Linux bridge is not working as expected: the Openstack cirrOS instances has no internet access. This is the controller `ip a` and `brctl show` command output: ``` [upm@modena ~]$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master brq84f65ccb-c9 state UP group default qlen 1000 link/ether 24:4b:fe:7c:78:b8 brd ff:ff:ff:ff:ff:ff 3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:15:5b:02 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:15:5b:02 brd ff:ff:ff:ff:ff:ff 17: tapa467f377-b1@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master brq84f65ccb-c9 state UP group default qlen 1000 link/ether d6:90:e8:fe:90:23 brd ff:ff:ff:ff:ff:ff link-netns qdhcp-84f65ccb-c945-437b-9013-9c71422bb10e 18: brq84f65ccb-c9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 24:4b:fe:7c:78:b8 brd ff:ff:ff:ff:ff:ff inet 138.100.10.25/21 brd 138.100.15.255 scope global brq84f65ccb-c9 valid_lft forever preferred_lft forever inet6 fe80::6c31:4cff:fe2d:7820/64 scope link valid_lft forever preferred_lft forever 19: tap7a390547-5b@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master brqd811bcfa-94 state UP group default qlen 1000 link/ether 26:6d:a4:fc:73:51 brd ff:ff:ff:ff:ff:ff link-netns qdhcp-d811bcfa-945a-4633-9266-60ccafa28d86 20: vxlan-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master brqd811bcfa-94 state UNKNOWN group default qlen 1000 link/ether fa:cb:4e:e2:83:46 brd ff:ff:ff:ff:ff:ff 21: brqd811bcfa-94: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000 link/ether 12:a8:05:bf:98:98 brd ff:ff:ff:ff:ff:ff inet6 fe80::88c2:ecff:fe72:761f/64 scope link valid_lft forever preferred_lft forever 22: tap3eb4fbcf-41@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master brqd811bcfa-94 state UP group default qlen 1000 link/ether 12:a8:05:bf:98:98 brd ff:ff:ff:ff:ff:ff link-netns qrouter-278c944f-7e75-4a93-affe-b9ff93f4c6a5 23: tapfd2dca1f-f7@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master brq84f65ccb-c9 state UP group default qlen 1000 link/ether 86:cc:64:22:4d:db brd ff:ff:ff:ff:ff:ff link-netns qrouter-278c944f-7e75-4a93-affe-b9ff93f4c6a5 [upm@modena ~]$ brctl show bridge name bridge id STP enabled interfaces brq84f65ccb-c9 8000.244bfe7c78b8 no enp2s0 tapa467f377-b1 tapfd2dca1f-f7 brqd811bcfa-94 8000.12a805bf9898 no tap3eb4fbcf-41 tap7a390547-5b vxlan-1 virbr0 8000.525400155b02 yes virbr0-nic ``` This is the compute `ip a` and `brctl show` command output: ```shell [upm@testarossa ~]$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 24:4b:fe:7c:79:a0 brd ff:ff:ff:ff:ff:ff inet 138.100.10.26/21 brd 138.100.15.255 scope global noprefixroute enp2s0 valid_lft forever preferred_lft forever inet6 fe80::c461:f832:d690:c0a7/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: enp0s20f0u4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master brq84f65ccb-c9 state UP group default qlen 1000 link/ether 00:e0:4c:53:44:58 brd ff:ff:ff:ff:ff:ff inet6 fe80::ecff:62cc:d9e1:2e53/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:66:84:5a brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:66:84:5a brd ff:ff:ff:ff:ff:ff 6: brqd811bcfa-94: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000 link/ether 8e:94:21:5b:dc:f4 brd ff:ff:ff:ff:ff:ff inet 138.100.10.27/21 brd 138.100.15.255 scope global noprefixroute brqd811bcfa-94 valid_lft forever preferred_lft forever 7: brq84f65ccb-c9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:e0:4c:53:44:58 brd ff:ff:ff:ff:ff:ff inet 138.100.10.27/21 brd 138.100.15.255 scope global brq84f65ccb-c9 valid_lft forever preferred_lft forever 9: tap9d1c0de6-96: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel master brqd811bcfa-94 state UNKNOWN group default qlen 1000 link/ether fe:16:3e:7d:14:63 brd ff:ff:ff:ff:ff:ff inet6 fe80::fc16:3eff:fe7d:1463/64 scope link valid_lft forever preferred_lft forever 10: tapaf15e2f0-24: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master brq84f65ccb-c9 state UNKNOWN group default qlen 1000 link/ether fe:16:3e:91:6d:ef brd ff:ff:ff:ff:ff:ff inet6 fe80::fc16:3eff:fe91:6def/64 scope link valid_lft forever preferred_lft forever 11: vxlan-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master brqd811bcfa-94 state UNKNOWN group default qlen 1000 link/ether 8e:94:21:5b:dc:f4 brd ff:ff:ff:ff:ff:ff 13: tapef3e95d6-7c: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel master brqd811bcfa-94 state UNKNOWN group default qlen 1000 link/ether fe:16:3e:91:d1:1d brd ff:ff:ff:ff:ff:ff inet6 fe80::fc16:3eff:fe91:d11d/64 scope link valid_lft forever preferred_lft forever 14: tap1a5d77c0-d4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master brq84f65ccb-c9 state UNKNOWN group default qlen 1000 link/ether fe:16:3e:4f:da:0f brd ff:ff:ff:ff:ff:ff inet6 fe80::fc16:3eff:fe4f:da0f/64 scope link valid_lft forever preferred_lft forever 15: tap792bf660-2f: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel master brqd811bcfa-94 state UNKNOWN group default qlen 1000 link/ether fe:16:3e:f1:df:5f brd ff:ff:ff:ff:ff:ff inet6 fe80::fc16:3eff:fef1:df5f/64 scope link valid_lft forever preferred_lft forever 16: tapf42b8b2f-be: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master brq84f65ccb-c9 state UNKNOWN group default qlen 1000 link/ether fe:16:3e:9e:46:bb brd ff:ff:ff:ff:ff:ff inet6 fe80::fc16:3eff:fe9e:46bb/64 scope link valid_lft forever preferred_lft forever [upm@testarossa ~]$ brctl show bridge name bridge id STP enabled interfaces brq84f65ccb-c9 8000.00e04c534458 no enp0s20f0u4 tap1a5d77c0-d4 tapaf15e2f0-24 tapf42b8b2f-be brqd811bcfa-94 8000.8e94215bdcf4 no tap792bf660-2f tap9d1c0de6-96 tapef3e95d6-7c vxlan-1 virbr0 8000.52540066845a yes virbr0-nic ``` (The output of `ovs-vsctl show` command is empty in both machines). **Are the Linux Bridges correctly created?** These are the Linux bridge configuration files: * Controller `/etc/neutron/plugins/ml2/linuxbridge_agent.ini`: ``` [linux_bridge] physical_interface_mappings = provider:enp2s0 # enp2s0 is the interface associated to 138.100.10.25 [vxlan] enable_vxlan = true local_ip = 138.100.10.25 # controller has only 1 IP l2_population = true ``` * Compute `/etc/neutron/plugins/ml2/linuxbridge_agent.ini`: ``` [linux_bridge] physical_interface_mappings = provider:enp0s20f0u4 # interface associated to 138.100.10.26 [vxlan] enable_vxlan = true local_ip = 138.100.10.27 l2_population = true ``` An **observation** to keep in mind is that compute management interface (`138.100.10.26`) is inaccessible from anywhere, which I think is not correct since this prevents us, for example, from accessing the instance console through the URL. I have made some conection tests and these are the results: * Cirros_a `ip a` command output: ``` $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast qlen 1000 link/ether fa:16:3e:91:d1:1d brd ff:ff:ff:ff:ff:ff inet 192.168.1.222/24 brd 192.168.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fe91:d11d/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ether fa:16:3e:4f:da:0f brd ff:ff:ff:ff:ff:ff ``` * Cirros_b `ip a` command output: ``` $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast qlen 1000 link/ether fa:16:3e:f1:df:5f brd ff:ff:ff:ff:ff:ff inet 192.168.1.30/24 brd 192.168.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fef1:df5f/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ether fa:16:3e:9e:46:bb brd ff:ff:ff:ff:ff:ff ``` - There is **connection** between Cirros A and Cirros B (in both directions). - There is **connection** between Cirros A/B and self-service gateway (192.168.1.1) (in both directions). - There is **connection** between Cirros A/B and provider gateway (138.100.10.198) (in both directions). - There is **connection** between Cirros A/B and controller management interface (138.100.10.25) (in both directions). - There is **no connection** between Cirros A/B and compute management interface (138.100.10.26). This interface is not accessible. - There is **connection** between Cirros A/B and compute provider interface (138.100.10.27) (in both directions). I do not know if there is a problem on linux bridge configuration files, or maybe I need another network interface on controller machine.

1 0

Openstack instances cannot access to Internet [linuxbridge]
by Jaime 11 Feb '21

11 Feb '21

I am having serious issues in the deployment of the Openstack scenario related to the Linux Bridge. This is the scenario: - Controller machine: - Management Interface `enp2s0`: 138.100.10.25. - Compute machine: - Management Interface `enp2s0`: 138.100.10.26. - Provider Interface `enp0s20f0u4`: 138.100.10.27. Openstack Train scenario has been successfully deployed in Centos 8, choosing networking option 2 (self-service network). To verify the functionality, an image has been uploaded, created an Openstack flavor and security group, and launched a couple of cirrOS instances for connection testing. We have created a provider network following [this tutorial](https://docs.openstack.org/newton/install-guide-rdo/launch-instan… and a selfservice network following [this one](https://docs.openstack.org/newton/install-guide-rdo/launch-instance-ne…. The network scenario is the next one: As can be seen in the network topology, an external network 138.100.10.0/21 (provider) and an internal network 192.168.1.1 (selfservice) have been created, connected through a router by the interfaces 138.100.10.198 and 192.168.1.1, both active. Our problem is that our Linux bridge is not working as expected: the Openstack cirrOS instances has no internet access. This is the controller `ip a` and `brctl show` command output: This is the compute `ip a` and `brctl show` command output: (The output of `ovs-vsctl show` command is empty in both machines). **Are the Linux Bridges correctly created?** These are the Linux bridge configuration files: * Controller `/etc/neutron/plugins/ml2/linuxbridge_agent.ini`: ``` [linux_bridge] physical_interface_mappings = provider:enp2s0 # enp2s0 is the interface associated to 138.100.10.25 [vxlan] enable_vxlan = true local_ip = 138.100.10.25 # controller has only 1 IP l2_population = true ``` * Compute `/etc/neutron/plugins/ml2/linuxbridge_agent.ini`: ``` [linux_bridge] physical_interface_mappings = provider:enp0s20f0u4 # interface associated to 138.100.10.26 [vxlan] enable_vxlan = true local_ip = 138.100.10.27 l2_population = true ``` An **observation** to keep in mind is that compute management interface (`138.100.10.26`) is inaccessible from anywhere, which I think is not correct since this prevents us, for example, from accessing the instance console through the URL. I have made some conection tests and these are the results: * Cirros_a `ip a` command output: * Cirros_b `ip a` command output: - There is **connection** between Cirros A and Cirros B (in both directions). - There is **connection** between Cirros A/B and self-service gateway (192.168.1.1) (in both directions). - There is **connection** between Cirros A/B and provider gateway (138.100.10.198) (in both directions). - There is **connection** between Cirros A/B and controller management interface (138.100.10.25) (in both directions). - There is **no connection** between Cirros A/B and compute management interface (138.100.10.26). This interface is not accessible. - There is **connection** between Cirros A/B and compute provider interface (138.100.10.27) (in both directions). I do not know if there is a problem on linux bridge configuration files, or maybe I need another network interface on controller machine.

1 0