September 2021 - openstack-discuss

MTU configuration for instances
by shubjero 14 Sep '21

14 Sep '21

Hey Openstackers, I am trying to determine how to configure/manipulate an OpenStack instances MTU configuration upon deployment/creation. I know that in neutron.conf you can set the 'global_physnet_mtu = value' and 'path_mtu = value' in ml2_conf.ini. In our case we are setting these to 9000 as the physical interfaces of our control plane and compute nodes are all using 9000 mtu however the bonded interfaces for our various networks are 8900. With this mtu configured, we've noticed that our OpenStack neutron networks within a tenancy are auto-selecting a mtu of 8958 as from what I've read it will take the 9000 mtu and minus the approriate overhead to pass the underlying physical network properly but I think because our bonded interfaces are 8900 this has started to introduce some problems in instances with operating systems that hard code the MTU from Neutron networks. When an instance gets deployed it may (Ubuntu 20.04) or may not (Ubuntu 18.04) retrieve the network mtu from neutron metadata service and builds it in to the netplan configuration as provided below. My question is, where in Neutron could I configure a lower MTU for the instances? I am not sure if I should change my global_physnet_mtu and path_mtu to 8900 OR some other configuration option? Thanks all! ---- # curl --silent http://169.254.169.254/openstack/2018-08-27/network_data.json | jq . { "links": [ { "id": "tap4318b50a-76", "vif_id": "4318b50a-7685-4777-917f-eea947aa1cb6", "type": "ovs", "mtu": 8958, <--- Matches the MTU of the underlying OpenStack network attached to this instance "ethernet_mac_address": "fa:16:3e:a4:19:44" } ], "networks": [ { "id": "network0", "type": "ipv4_dhcp", "link": "tap4318b50a-76", "network_id": "4acb077c-0656-4731-ba42-031a22af7931" } ], "services": [] } ---- # cat /etc/netplan/50-cloud-init.yaml # This file is generated from information provided by the datasource. Changes # to it will not persist across an instance reboot. To disable cloud-init's # network configuration capabilities, write a file # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following: # network: {config: disabled} network: version: 2 ethernets: ens3: dhcp4: true match: macaddress: fa:16:3e:a4:19:44 mtu: 8958 <--- MTU gets hard-coded in the config for Ubuntu 20.04 but not Ubuntu 18.04. set-name: ens3

2 1

[TripleO] Reviving the TripleO review priorities etherpad
by James Slagle 13 Sep '21

13 Sep '21

I'd like to see about helping to focus our review priorities by reviving the tripleo-review-priorities etherpad: https://etherpad.opendev.org/p/tripleo-review-priorities I deleted all the old cruft, and created some new high level topics. There are likely others as well. I'll start by filling in some links to what I think the highest priority items are, but I could use help to create an accurate list of where the core team should focus. I'd like to get some feedback on the approach in the #tripleo meeting tomorrow as well. Let me know any thoughts. -- -- James Slagle --

1 0

[neutron] Bug deputy report for week of September 6
by Lajos Katona 13 Sep '21

13 Sep '21

Hi Neutron Team I was bug deputy in neutron last week. Summary ======= One bug needs more attention but that is for Rocky, and seems like ovs-agent ovs communication issue ( https://bugs.launchpad.net/neutron/+bug/1943112 ) And one question regarding Neutron standalone use with OVN perhaps ( https://bugs.launchpad.net/neutron/+bug/1943355 ) The employee of the week is ralonsoh :-) Needs attention ================ * openstack rocky version, neutron is throwing the following error : ovs|00002|ovsdb_idl|WARN|transaction error: {"details":"Transaction causes multiple rows in \"Manager\" table to have identi https://bugs.launchpad.net/neutron/+bug/1943112 * Can We Use Openstack Neutron as standalone component? https://bugs.launchpad.net/neutron/+bug/1943355 This one is more like a question, not an actual bug, or a bug for documentation. Bugs with assignees =================== * [OVN] "DHCP_Options" is not updated when the metadata port IPs are https://bugs.launchpad.net/neutron/+bug/1942794 Assigned to ralonsoh, patch: https://review.opendev.org/c/openstack/neutron/+/807692 * [OVN] Metadata ports owner is "network:distributed" only since Wallaby release https://bugs.launchpad.net/neutron/+bug/1942866 Assigned to ralonsoh, patch: https://review.opendev.org/c/openstack/neutron/+/807707 * [OVN] "neutron-ovn-tempest-ovs-master-fedora" CI job failing since 2021-08-24 https://bugs.launchpad.net/neutron/+bug/1942913 Assigned to ralonsoh, patches: https://review.opendev.org/c/openstack/neutron/+/808109 & https://review.opendev.org/c/openstack/tempest/+/808081 * [OVN][FT] During the OvnNorthd stop, the unix file could not exist https://bugs.launchpad.net/neutron/+bug/1943029 Assigned to ralonsoh, patch: https://review.opendev.org/c/openstack/neutron/+/807862 * Replace "Inspector.from_engine()" with "sqlalchemy.inspect()" https://bugs.launchpad.net/neutron/+bug/1943155 Assigned to ralonsoh, patch: https://review.opendev.org/c/openstack/neutron/+/808103 RFEs ==== No new RFE for this week.

1 0

OpenInfra Live - September 16 at 9am CT
by Ashlee Ferguson 13 Sep '21

13 Sep '21

Hi everyone, This week’s OpenInfra Live episode is brought to you by the OpenInfra Community. Since the Paris Summit in 2014, the OpenInfra Foundation has hosted our annual Superuser Awards to recognize organizations that have used open infrastructure to meaningfully improve their business while contributing back to the community. Past winners will join us for this episode to discuss where they are now, what is next, and tips for organizations applying for this year's awards. Episode: Superusers: Where are they now? Date and time: September 16 at 9am CT (1400 UTC) You can watch us live on: YouTube: https://www.youtube.com/watch?v=nUwgBdx0lSw <https://www.youtube.com/watch?v=nUwgBdx0lSw> LinkedIn: https://www.linkedin.com/feed/update/urn:li:ugcPost:6841804188478009344/ <https://www.linkedin.com/feed/update/urn:li:ugcPost:6841804188478009344/> Facebook: https://www.facebook.com/104139126308032/posts/4319519031436666/ <https://www.facebook.com/104139126308032/posts/4319519031436666/> WeChat: recording will be posted on OpenStack WeChat after the live stream Speakers: Jared Baker (The Ontario Institute for Cancer Research (OICR)) Belmiro Moreira (CERN) Mohammed Naser (VEXXHOST) Xiaoguang, Zhang and Zhiqiang Yu (China Mobile) Think your organization or someone you know could be a Superuser? Nominations <https://openinfrafoundation.formstack.com/forms/superuserawards_2021> for the 2021 Superuser Awards are open! Have an idea for a future episode? Share it now at ideas.openinfra.live <https://openinfrafoundation.formstack.com/forms/openinfralive>. Thanks, Ashlee

1 0

[Image Encryption] Meeting today cancelled
by Josephine Seifert 13 Sep '21

13 Sep '21

Hello, unfortunately I have to cancel the meeting today. Next meeting will be Monday 20th. greetings Josephine (Luzi)

1 0

[designate][interop] test_create_all_recordset_types ddt issue
by Martin Kopec 13 Sep '21

13 Sep '21

Hi designate team, I'm reaching out because we have encountered a problem with one of the tests [1]. We track the following name [2]: designate_tempest_plugin.tests.api.v2.test_recordset.RecordsetsTest.test_create_all_recordset_types That test name is actually incorrect due to the ddt and the real name of the test is created dynamically based on the test data passed via ddt. We have a consistency check which is supposed to verify that the test names tracked in our guidelines match the ones in Tempest/tempest plugins, however, there was a bug - we are fixing that by [3]. The question is, should interop track all the permutations of the test? See [4]. [1] https://opendev.org/openstack/designate-tempest-plugin/src/commit/da27a70ae… [2] https://opendev.org/osf/interop/src/commit/d8eac71fa507c68e9c1f83a19dd77af8… [3] https://review.opendev.org/c/osf/interop/+/806598 [4] https://review.opendev.org/c/osf/interop/+/807586 Thank you, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

5 7

Instances cannot ping each other and cannot ping virtual-router
by wodel youchi 13 Sep '21

13 Sep '21

Hi, I deployed OpenStack Train using TripleO using this tutorial : https://kdjlab.com/deploying-rdo-in-a-cohesive-manner/ and the documentation of TripleO. I deployed it with DVR. In my deployment I am using virtual machines with nested-kvm. The deployment went well, I am using network isolation like this : - nic1 : provisioning - nic2 and nic3 (bond0) storage and storage mgmt networks, each one in it's VLAN - nic3 and nic5 (bond1) tenant, api and *external* (10.0.2.0/24 VLAN2100) networks, each one in it's VLAN In my physical host (the bare metal KVM) I created a bridge which handles the provisioning, tenant, api and external networks. I created a private tenant network (172.16.100.0/24). openstack network create private neutron subnet-create private 172.16.100.0/24 --name private-sub --dns-nameserver 172.16.0.252 I created a public network and I attached it to the external network using the same VLAN tag (10.0.2.0/24 VLAN 2100, pool: 10.0.2.100-10.0.2.120) : *openstack network create --provider-network-type vlan --provider-physical-network datacentre --provider-segment 2100 --external public* neutron subnet-create public 10.0.2.0/24 --name public-sub --disable-dhcp --allocation-pool=start=10.0.2.100,end=10.0.2.120 --gateway=10.0.2.1 --dns-nameserver 172.16.0.252 I created a vrouter, one port in the public network and the other in the private network. I created two cirrus instances, each one got it's ip address from the private network. I found : cirrus-1 : 172.16.100.81 cirrus-2 : 172.16.100.103 vrouter : 172.16.100.1 private : 10.0.2.101 external neutron:dhcp : 172.16.100.2 The problems : - The instances cannot ping each other. - The instances cannot ping the vrouter. - I cannot ping the public vrouter interface. But both instances can ping neutron:dhcp Could someone help me dig into this. Thanks in advance, Regards.

1 1

Openstack nova live migration pain
by hai wu 13 Sep '21

13 Sep '21

This is Openstack train release. Nova live migration is extremely painful to deal with. Everytime we complete a live migration, nova-compute service on the source host would still be up and runnning, but it would always fail to further increment the report_count database field in nova database, host heartbeat purpose, thus controller would think the hypervisor host failed via its is_up() function checking on report_count and updated_at fields iirc. So we end up having to manually migrate one vm at a time, then restart service, then manually migrate the next vm .. Any ideas? I already tried setting debug=True for nova.conf even for database tracing, but thus far I could not find any obvious error message. Each time the live migration (no shared storage) would succeed, but each time we will have to restart nova-compute service. This is so bad .. Any suggestions on this would be highly appreciated. Thanks, Hai

4 12

[largescale-sig] Next meeting: Sept 15th, 15utc
by Thierry Carrez 13 Sep '21

13 Sep '21

Hi everyone, The Large Scale SIG meeting is back this Wednesday in #openstack-operators on OFTC IRC, at 15UTC. You can doublecheck how that time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210915T15 A number of topics have already been added to the agenda, including discussing the topic of our next OpenInfra.Live show! Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 0

[kolla][operators] Kolla Ansible will switch to use Quay.io by default (instead of Docker Hub)
by Radosław Piliszek 13 Sep '21

13 Sep '21

Dear Kolla Operators, This is a heads-up message that Kolla Ansible will switch to using Quay.io instead of Docker Hub by default. [1] This was agreed at the last meeting unless we find obstacles not to do it. But it seems it's even a better option for our users from China. [2] Therefore the patch [1] has been proposed and will likely be merged and probably backported to stable branches too. The main reasoning behind this change is that users suffer from Docker Hub's limits. [3] You may have noticed we started (a long time ago) publishing weekly, instead of daily, to Docker Hub to mitigate the issue to some extent. However, we had to switch our CI to Quay.io anyway to really be able to work on the project rather than pray for luck with Docker Hub. Quay.io has been great for us in general so we decided to make the same switch for users. Oh, and, by the way, we publish to Quay.io daily. ;-) If you use your own, local registry, then you are most likely unaffected but make sure you set both `kolla_registry` AND `kolla_namespace` as we have to override both. Finally, kind reminder that operators of multinode and production clusters are strongly advised to set up their own, local registries. The docs show a simple minimal example of that. [4] (use option 1 from the current page as possibility of option 2 will be gone with the switch to quay.io). Thank you for reading up to this point! [1] https://review.opendev.org/c/openstack/kolla-ansible/+/808486 [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-September/02481… [3] https://bugs.launchpad.net/kolla-ansible/+bug/1942134 [4] https://docs.openstack.org/kolla-ansible/wallaby/user/multinode.html#deploy… -yoctozepto

2 2