- openstack-discuss - lists.openstack.org

[tc] weekly update
by Mohammed Naser 15 Feb '21

15 Feb '21

Hi everyone, Here’s an update on what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Patches ## Open Reviews - Cool-down cycle goal https://review.opendev.org/c/openstack/governance/+/770616 - Retire tempest-horizon https://review.opendev.org/c/openstack/governance/+/774379 - monasca-log-api & monasca-ceilometer does not make releases https://review.opendev.org/c/openstack/governance/+/771785 - Add assert:supports-api-interoperability tag to neutron https://review.opendev.org/c/openstack/governance/+/773090 - Add assert:supports-api-interoperability to cinder https://review.opendev.org/c/openstack/governance/+/773684 # Other Reminders - Our next [TC] weekly meeting is scheduled for February 18th at 1500 UTC. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, February 17th, at 2100 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

[neutron] CI meeting - Tuesday 16.02.2021
by Slawek Kaplonski 15 Feb '21

15 Feb '21

Hi, I will not be available to chair CI meeting tomorrow. So let's cancel it this week. See You online and on the meeting next week :) -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[neutron] Team meeting - Tuesday 16.02.2021 cancelled
by Slawek Kaplonski 15 Feb '21

15 Feb '21

Hi, I will not be available to chair team meeting tomorrow. So lets cancel it this week. See You online and on the meeting next week :) -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

Nova-compute 20.4.0-ubuntu1~cloud0 fails to start
by Eyle Brinkhuis 15 Feb '21

15 Feb '21

Hi, Deploying a new testbed, we experience an issue with nova-compute (using canonical charmed openstack Train). We use networking-vpp, that uses python-etcd. After installation of openstack, and configuration of the networking-vpp setup, we cannot start nova-compute anymore: Feb 15 09:35:19 sr635-1 nova-compute[131674]: Traceback (most recent call last): Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/bin/nova-compute", line 6, in <module> Feb 15 09:35:19 sr635-1 nova-compute[131674]: from nova.cmd.compute import main Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/nova/cmd/__init__.py", line 16, in <module> Feb 15 09:35:19 sr635-1 nova-compute[131674]: import nova.monkey_patch # noqa Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/nova/monkey_patch.py", line 98, in <module> Feb 15 09:35:19 sr635-1 nova-compute[131674]: _monkey_patch() Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/nova/monkey_patch.py", line 67, in _monkey_patch Feb 15 09:35:19 sr635-1 nova-compute[131674]: import oslo_service # noqa Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/oslo_service/__init__.py", line 16, in <module> Feb 15 09:35:19 sr635-1 nova-compute[131674]: from oslo_log import log as logging Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/oslo_log/log.py", line 41, in <module> Feb 15 09:35:19 sr635-1 nova-compute[131674]: from oslo_config import cfg Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/oslo_config/cfg.py", line 53, in <module> Feb 15 09:35:19 sr635-1 nova-compute[131674]: from oslo_config import types Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/oslo_config/types.py", line 28, in <module> Feb 15 09:35:19 sr635-1 nova-compute[131674]: from debtcollector import removals Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/debtcollector/__init__.py", line 20, in <module> Feb 15 09:35:19 sr635-1 nova-compute[131674]: 'debtcollector').version_string() Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/pbr/version.py", line 467, in version_string Feb 15 09:35:19 sr635-1 nova-compute[131674]: return self.semantic_version().brief_string() Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/pbr/version.py", line 462, in semantic_version Feb 15 09:35:19 sr635-1 nova-compute[131674]: self._semantic = self._get_version_from_pkg_resources() Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/pbr/version.py", line 439, in _get_version_from_pkg_resources Feb 15 09:35:19 sr635-1 nova-compute[131674]: import pkg_resources Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3250, in <module> Feb 15 09:35:19 sr635-1 nova-compute[131674]: @_call_aside Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3234, in _call_aside Feb 15 09:35:19 sr635-1 nova-compute[131674]: f(*args, **kwargs) Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3263, in _initialize_master_working_set Feb 15 09:35:19 sr635-1 nova-compute[131674]: working_set = WorkingSet._build_master() Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 574, in _build_master Feb 15 09:35:19 sr635-1 nova-compute[131674]: ws = cls() Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 567, in __init__ Feb 15 09:35:19 sr635-1 nova-compute[131674]: self.add_entry(entry) Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 623, in add_entry Feb 15 09:35:19 sr635-1 nova-compute[131674]: for dist in find_distributions(entry, True): Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2065, in find_on_path Feb 15 09:35:19 sr635-1 nova-compute[131674]: for dist in factory(fullpath): Feb 15 09:35:19 sr635-1 nova-compute[131674]: File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2127, in distributions_from_metadata Feb 15 09:35:19 sr635-1 nova-compute[131674]: if len(os.listdir(path)) == 0: Feb 15 09:35:19 sr635-1 nova-compute[131674]: PermissionError: [Errno 13] Permission denied: '/usr/local/lib/python3.6/dist-packages/python_etcd-0.4.5.dist-info' Feb 15 09:35:19 sr635-1 systemd[1]: nova-compute.service: Main process exited, code=exited, status=1/FAILURE Meanwhile, in a different deployment, which runs nova-compute 20.3.0-ubuntu1~cloud0, we do not experience this issue. Permissions of all the packages in /usr/local/lib/python3.6/dist-packages/ are all identical. When we remove all packages once again (python-etcd etc), nova-compute is able to start without any issue. Anyone experiencing the same, or has a workaround? Eyle

2 2

Proposing Flavio Fernandes (flaviof) for ovsdbapp core
by Terry Wilson 15 Feb '21

15 Feb '21

Flavio has been helping out with ovsdbapp a great deal and I would like to nominate him for ovsdbapp-core. He's written some great code and reviews and will be an asset to the team. Historically, I've just added people who were contributing directly, but seeing as ovsdbapp has moved past 1.0 I thought I'd go ahead and follow official procedures this time. ;) Existing team members, please respond with +1/-1. Thanks! Terry

5 6

[neutron] Bug Deputy Report Feb 8 - 15
by Jakub Libosvar 15 Feb '21

15 Feb '21

Hi everyone, I was bug deputy for the last week. It's been mostly business as usual but I'd like to highlight this bug that needs an assignee: https://bugs.launchpad.net/neutron/+bug/1915341 The problem seems to be with LinuxBridge agent after it's restarted, which is not tested on the gate AFAIK. I don't have an LB environment thus I couldn't confirm but would be great if somebody who maintains and is interested in LB can confirm. Here is the full weekly report: Critical * Neutron run with uwsgi is broken with oslo_policy 3.6.2 - https://bugs.launchpad.net/neutron/+bug/1915494 - Assigned to: Slawek Kaplonski * neutron-linuxbridge-agent not starting due to nf_tables rules - https://bugs.launchpad.net/neutron/+bug/1915341 - Needs an assignee High * test_create_router_set_gateway_with_fixed_ip fails in dvr-ha job - https://bugs.launchpad.net/neutron/+bug/1915271 - In progress: https://review.opendev.org/c/openstack/neutron/+/774785 - Assigned to: Oleg Bondarev * Metadata over IPv6 don't works with L3ha routers - https://bugs.launchpad.net/neutron/+bug/1915495 - Assigned to: Slawek Kaplonski Medium * Split logfiles for neutron-functional-with-uwsgi job are empty - https://bugs.launchpad.net/neutron/+bug/1915272 - In progress: https://review.opendev.org/c/openstack/neutron/+/774865 - Assigned to: Bernard Cafarelli * Resource name and collection name for address groups are incorrectly defined in neutron-lib - https://bugs.launchpad.net/neutron/+bug/1915310 - Fix committed: https://review.opendev.org/c/openstack/neutron-lib/+/774924 - Assigned to: Miguel Lavalle * DeviceManager's fill_dhcp_udp_checksums assumes IPv6 available - https://bugs.launchpad.net/neutron/+bug/1915480 - Needs an assignee Low * Openvswitch firewall - removing and adding security group breaks connectivity - https://bugs.launchpad.net/neutron/+bug/1915530 - Assigned to: Slawek Kaplonski RFEs * [RFE] There should be a way to set ethertype for the vlan_transparent networks - https://bugs.launchpad.net/neutron/+bug/1915151 Kuba

1 1

[tc][heat][tacker] Discusssion about heat-translater and tosca-parser maintenance
by TAKAHASHI TOSHIAKI(高橋　敏明) 14 Feb '21

14 Feb '21

Hi, I'm a tacker team member. I'd like to discuss how to maintain heat-translator[1] and tosca-parser[2] repositories. These 2 repositories have not been updated so actively, but tacker often requires code updates for these repositories. Recently, patch merge progress of tacker and these repo do not sometimes match, which affects the development of tacker. For example, our some functional tests on zuul fail because these master codes are not updated. Therefore, tacker members would like to take part more in these 2 developments. Tacker members have already started code reviews, patch posts, etc. If possible, we want some Tacker members to join the core team in the near future. How about this? [1] https://opendev.org/openstack/heat-translator [2] https://opendev.org/openstack/tosca-parser Regards, Toshiaki

5 9

[ironic] A new project for useful deploy steps?
by Dmitry Tantsur 14 Feb '21

14 Feb '21

Hi all, We have finally implemented in-band deploy steps (w00t!), and people started coming up with ideas. I have two currently: 1) configure arbitrary kernel command line arguments via grub 2) write NetworkManager configuration (for those not using cloud-init) I'm not sure how I feel about putting these in IPA proper, seems like we may go down a rabbit hole here. But what about a new project (ironic-python-agent-extras?) with a hardware manager providing a collection of potentially useful deploy steps? Or should we nonetheless just put them in IPA with priority=0? Opinions welcome. Dmitry -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

4 6

[Interop, Users] listing interop results
by Kanevsky, Arkady 12 Feb '21

12 Feb '21

Dell Customer Communication - Confidential Team, We are reviewing our openstack interop program. We have 3 base "certifications" for interop that cloud vendors can submit and foundation list on marketplace https://www.openstack.org/marketplace/ : 1. Openstack Powered Storage 2. OpenStack Powered Compute 3. OpenStack Powered Platform (combines both compute and storage) These can be viewed as the core. And there are 3 add-on programs for specific projects of openstack: 1. DNS (Designate) 2. Orchestration (Heat) 3. Shared-File-System (Manila) We have 4 categories of clouds that use interop programs and list their offering with interoperability results and logo: 1. Remotely managed private clouds - https://www.openstack.org/marketplace/remotely-managed-private-clouds/ * The latest interop guidelines listed there is 2019.11 and most are from 2017-2018 * All used OpenStack Powered Platform * Vexxhost listed without listing what guidelines they used. (Jimmy can you pull what they had submitted and update their entry) 2. Distros and Appliances - https://www.openstack.org/marketplace/distros/ : * These seems to be updated most often. Several used the latest 2020.06 guidelines * There are usage of all 3 core logos. * No add-on logos listed 3. Hosted Private Clouds - https://www.openstack.org/marketplace/hosted-private-clouds/ : * There is one entry that uses 2020.06 guidelines but most are 2016-2018. * Most for Powered Platform and one for Powered Compute 4. Public Cloud - https://www.openstack.org/marketplace/public-clouds/ : * There is one entry that uses 2020.06 guidelines but most are 2016-2018. * Mixture of Powered Platform and Powered Compute I will skip the question on the value of Marketplace program as it will be discussed separately in newly formed temporary WG under foundation to review/define Open Infrastructure Branding and Trademark policy. We need to address the issue on how to list add-ons for current openstack marketplace program. The simplest way is to add to "TESTED" OpenStack Powered Platform/Compute/Storage also add-ons that vendors passed. In the detailed section we already listing what APIs and services supported and which version. So do not see any changes needed there. Comments and suggestions please? Thanks, Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell EMC office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

4 6

[Neutron] Distributed Virtual Routing with OVN as Backend
by Taha Adel 12 Feb '21

12 Feb '21

Hello OpenStack Community, Let me introduce myself in brief first. My name is Taha and I'm a communications and electronics engineering student in the fourth year. My graduation project is to build a cloud infrastructure suited for Institutions and Universities to fully utilize the idle physical resources on the campus. I'm using OpenStack Platform as the cloud orchestrator, and I have a question regarding the Networking service in the cloud, Neutron. In my project, I want to use Distributed Virtual Routing for Layer three forwarding, floating IPs, and SNAT to limit the management overhead in the could and simplify the architecture. This design should end up with one controller node and a bunch of distributed compute nodes across the university. In my design, all compute nodes are attached to the provider network to allow N/S traffic in a distributed manner. The problem here is that I read in the OpenStack documentation that the SNAT traffic should always traverse through a centralized gateway node, and I need SNAT traffic as well as the other N/S traffic to be distributed across the compute nodes. So, the question here, is there any configuration that should let me fulfill this requirement? Sorry for taking so long, and I appreciate your help in advance. Best regards. Taha Adel عدم التعرض للفيروسات www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2 1

[openstack-ansible] Check current state of Keystone DB: HAProxy galera-clustercheck fails if external_vip is used
by Philipp Wörner 12 Feb '21

12 Feb '21

Dear all, unfortunately we are facing an problem while setting up Openstack (described at the end of the mail). Last year we had no issue with our configuration. I found the problem why the playbook stops and a temporary workaround. But I dont know the root cause, maybe you can help me with some advice. Thank you in advance! Have a sunny weekend and best regards, Philipp Where setup-openstack.yml stops: TASK [os_keystone : Check current state of Keystone DB] **************************************************************************** **************************************************************************** ****************************** fatal: [infra1_keystone_container-01c233df]: FAILED! => {"changed": true, "cmd": ["/openstack/venvs/keystone-21.2.3.dev4/bin/keystone-manage", "db_sync", "--check"], "delta": "0:01:42.166790", "end": "2021-02-11 13:01:06.282388", "failed_when_result": true, "msg": "non-zero return code", "rc": 1, "start": "2021-02-11 12:59:24.115598", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []} Reason: This is caused because HAProxy thinks the service is not available caused by the health check against port 9200. If I test the cluster-check-service manually, I see the external_vip isnt allowed. root@bc1bl11:/home/ubuntu# telnet -b <internal_vip> 192.168.110.235 9200 Trying 192.168.110.235... Connected to 192.168.110.235. Escape character is '^]'. HTTP/1.1 200 OK Content-Type: text/plain Connection: close Content-Length: 40 Percona XtraDB Cluster Node is synced. Connection closed by foreign host. root@bc1bl11:/home/ubuntu# telnet -b <external_vip> 192.168.110.235 9200 Trying 192.168.110.235... Connected to 192.168.110.235. Escape character is '^]'. Connection closed by foreign host. Workaround: After manually modifying the service-configuration and adding the external_vip to the whitelist everything works and the OSA-playbook succeeds as well: root@infra1-galera-container-492e1206:/# cat /etc/xinetd.d/mysqlchk # default: on # description: mysqlchk # Ansible managed service mysqlchk { disable = no flags = REUSE socket_type = stream port = 9200 wait = no user = nobody server = /usr/local/bin/clustercheck log_on_failure += USERID only_from = 192.168.110.200 192.168.110.235 192.168.110.211 127.0.0.1 per_source = UNLIMITED } Question: I am wondering now why haproxy uses the external_vip to check the mysql-service and why I am facing this problem now because last year everything was fine with our configuration. We just moved the external_vip from the NIC to the bridge in the netplan-config and the external_vip is now in the same network as the internal_vip. Here is also a snipped of our haproxy config: root@bc1bl11:/home/ubuntu# cat /etc/haproxy/haproxy.cfg # Ansible managed global log /dev/log local0 chroot /var/lib/haproxy user haproxy group haproxy daemon maxconn 4096 stats socket /var/run/haproxy.stat level admin mode 600 ssl-default-bind-options force-tlsv12 tune.ssl.default-dh-param 2048 defaults log global option dontlognull option redispatch option forceclose retries 3 timeout client 50s timeout connect 10s timeout http-request 5s timeout server 50s maxconn 4096 frontend galera-front-1 bind 192.168.110.211:3306 option tcplog timeout client 5000s acl white_list src 127.0.0.1/8 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 tcp-request content accept if white_list tcp-request content reject mode tcp default_backend galera-back backend galera-back mode tcp balance leastconn timeout server 5000s stick store-request src stick-table type ip size 256k expire 30m option tcplog option httpchk HEAD / HTTP/1.0\r\nUser-agent:\ osa-haproxy-healthcheck # server infra1_galera_container-492e1206 192.168.110.235:3306 server infra1_galera_container-492e1206 192.168.110.235:3306 check port 9200 inter 12000 rise 1 fall 1

2 1

[neutron][ovn] ipv6 in virtual networks
by Piotr Misiak 12 Feb '21

12 Feb '21

Hi all, I have a test env with OpenStack Ussuri and OVN deployed by kolla-ansible. I'm struggling with IPv6 VMs addressing. Has anyone deployed such configuration successfully? What is working: - SLAAC for VMs IPv6 addressing - VMs configure IPv6 addresses and can ping each other via IPv6 - VMs can ping virtual router's fe80:: address - OVN is sending ICMPv6 RA packets periodically on virtual private networks What is not working: - VMs can't ping virtual router's private network IPv6 address specified in virtual network configuration in Neutron (IPv6 GUA), I see ICMPv6 echo request packets on tapXXXXX interfaces with a correct DEST MAC, but there are no responses. - Routing is not working at all Besides those, I can't imagine how upstream router will know how to reach a particular private network with GUA IPv6 addresses (to which virtual router send packets to reach a particular private network?). I have a standard external network with IPv6 GUA /64 subnet and virtual routers which connects private networks with IPv6 GUA /64 subnets with external network. I thought that OVN virtual router will send ICMPv6 RA packets on external network with reachable prefixes and upstream router will learn routing info from those but I don't see any RA packets sent by OVN on external network, I see only RA packets from an upstream router. How this should work and be configured? How to configure GUA IPv6 addresses on virtual private networks? Is it supported by Neutron/OVN? Looking forward any responses regarding this area because documentation does not exist technically. Thanks!

3 5

[kolla][osa] Host network configuration tools
by Mark Goddard 12 Feb '21

12 Feb '21

Hi, We're working on adding Ubuntu support to Kayobe, and are at the stage of deciding on which tool to use for host network configuration. The Ansible role we use supports /etc/network/interfaces, but we're thinking it might be sensible to choose something more modern before we get locked in. There are 3 reasonable options, as far as we can tell: * netplan: installed by default on 20.04 server images. Seems like a fairly simple solution, but I have read some reports of missing features. * systemd-networkd: the default renderer for netplan. Standard systemd style interface. We might get around the missing features by using this directly. * NetworkManager: the default on Ubuntu desktop, but have heard it can be a bit heavy and does too much without being asked to. I've also heard that more recent versions are improved. The main reason we would go this route would be for consistency with CentOS/RHEL. Any feedback of experience with these and their suitability for use in OpenStack cloud infrastructure would be appreciated. Thanks, Mark

4 3

[all][interop] Reforming the refstack maintainers team
by Ghanshyam Mann 12 Feb '21

12 Feb '21

Hello Everyone, As Goutham mentioned in a separate ML thread[2] that there is no active maintainer for refstack repo which we discussed in today's interop meeting[1]. We had a few volunteers who can help to maintain the refstack and other interop repo which is good news. I would like to call for more volunteers (new or existing ones), if you are interested to help please do reply to this email. The role is to maintain the source code of the below repos. I will propose the ACL changes in infra sometime next Friday (18th dec) or so. For easy maintenance, we thought of merging the below repo core group into a single group called 'refstack-core' - openstack/python-tempestconf - openstack/refstack - openstack/refstack-client - x/ansible-role-refstack-client (moving to osf/ via https://review.opendev.org/765787) Current Volunteers: - martin (mkopec(a)redhat.com) - gouthamr (gouthampravi(a)gmail.com) - gmann (gmann(a)ghanshyammann.com) - Vida (vhariria(a)redhat.com) - interop-core (we will add this group also which has interop WG chairs so that it will be easy to maintain in the future changes) NOTE: there is no change in the 'interop' repo group which has interop guidelines and doc etc. [1] https://etherpad.opendev.org/p/interop [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019263… -gmann

8 12

[release] Release countdown for week R-8 Feb 15 - Feb 19
by Herve Beraud 12 Feb '21

12 Feb '21

Hello everyone, General Information ------------------- The following cycle-with-intermediary deliverables have not done any intermediary release yet during this cycle. The cycle-with-rc release model is more suited for deliverables that plan to be released only once per cycle. To start the discussion, we have proposed changes[1] that update the release model for the following deliverables: Swift ( https://review.opendev.org/c/openstack/releases/+/774682 ) [1] https://review.opendev.org/q/topic:%22switch-to-rc%22 PTLs and release liaisons for each of those deliverables can either +1 the release model change, or -1 the change if they expect a release soon. We also published a proposed release schedule for the upcoming Xena cycle: https://review.opendev.org/c/openstack/releases/+/772357 Unless new comments are posted on that review that make us reconsider, we will approve this Xena release schedule by February 18. Upcoming Deadlines & Dates -------------------------- Cross-project events: - Non-client library freeze: 04 March, 2021 (R-6 week) - Client library freeze: 11 March, 2021 (R-5 week) - Wallaby-3 milestone: 11 March, 2021 (R-5 week) Project-specific events: - Cinder Driver Features Declaration: 18 February, 2021 (R-8) - Oslo Feature Freeze: 25 February, 2021 (R-7) Thanks for your attention, -- 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

[neutron] Drivers meeting agenda - Friday 12.02.2021
by Slawek Kaplonski 12 Feb '21

12 Feb '21

Hi, For the tomorrow's drivers meeting we have 1 RFE to discuss: * https://bugs.launchpad.net/neutron/+bug/1915151 - [RFE] There should be a way to set ethertype for the vlan_transparent networks Please take a look at it and ask/prepare questions for it to be discussed during the meeting :) If anyone has anything else which would like to discuss, please add it to the "On demand" section at [1]. [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda -- Slawek Kaplonski Principal Software Engineer Red Hat

2 1

[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 11 Feb '21

11 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 11 Feb '21

11 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

[stein][neutron][vlan provider network] How to configure br-ex on virtual interface
by roshan anvekar 11 Feb '21

11 Feb '21

Hello, Below is my scenario. I am trying to use a single physical bonded interface ( example: bond1) both for external TLS access traffic and for provider network too ( These are 2 different vlan networks with separate vlan ids) . Bond0 is used as api_interface for management traffic. Bond2 is used for storage traffic. For this I created 2 virtual interfaces on this bond1 and used it accordingly while deploying through kolla-ansible. Before deployment the gateways for both vlan networks were accessible. Post deployment I see that qdhcp-id router is created on one of the controllers. Post creation of this DHCP agent, the gateway is inaccessible. Also the vms created are not getting IPs through DHCP agent so failing to be accessible. I had configured br-ex on virtual interface of provider vlan network and not on physical interface directly. Please let me know if I am going wrong in my network configurations. Regards, Roshan

3 4

[ironic] [release] [kolla] RFC: stop doing Extended Maintenance for Bifrost
by Dmitry Tantsur 11 Feb '21

11 Feb '21

Hi all, Since Bifrost is an installation project that supports several distributions, maintaining its stable branches is a never ending nightmare. We have *nearly* fixed Ussuri (thank you Riccardo!) and just started looking into Train (thank you Iury and Mark), I'm sure we cannot keep EM branches in a decent shape. Personally I feel that Bifrost is more geared towards consumers staying close to master, but my gut feeling may not necessarily match the reality. Based on the above, I'm proposing: 1) EOL all old branches from Ocata to Stein on Bifrost. 2) No longer create EM branches, EOL immediately after a branch leaves the regular maintenance. Opinions? Dmitry P.S. Adding kolla because of a potential impact. -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

3 4

[cinder] wallaby R-9 mid-cycle summary available
by Brian Rosmaita 10 Feb '21

10 Feb '21

In case you missed the exciting cinder R-9 virtual mid-cycle session (held yesterday or earlier today depending on where you are) I've posted a summary: https://wiki.openstack.org/wiki/CinderWallabyMidCycleSummary It will eventually include a link to the recording (in case you want to see what you missed or if you want to re-live the excitement). cheers, brian

1 0

bootstrap errors in OSA installation in CentOS 8.3
by Amey Abhyankar 10 Feb '21

10 Feb '21

Hello, I am trying to configure deployment host by referring following guide =https://docs.openstack.org/project-deploy-guide/openstack-ansible/victoria/deploymenthost.html # dnf install https://repos.fedorapeople.org/repos/openstack/openstack-victoria/rdo-relea… # dnf install git chrony openssh-server python3-devel sudo # dnf group install "Development Tools" # git clone -b 22.0.0.0rc1 https://opendev.org/openstack/openstack-ansible /opt/openstack-ansible # scripts/bootstrap-ansible.sh [ after executing this command, I am getting errors. Attaching sample error] ------------------------------------------------- hs will be added later\\n --pathspec-from-file <file>\\n read pathspec from file\\n --pathspec-file-nul with --pathspec-from-file, pathspec elements are separated with NUL character\\n'\"], [\"Role {'name': 'os_ironic', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-os_ironic', 'version': '67733c8f0cb13c467eb10f256a93d878c56d4743', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/os_ironic'} failed after 2 retries\\n\"], [\"Role {'name': 'os_cinder', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-os_cinder', 'version': '00a38c6584c09168faad135f10d265ad9c86efba', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/os_cinder'} failed after 2 retries\\n\"], [\"Role {'name': 'lxc_hosts', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-lxc_hosts', 'version': 'b3bff3289ac2e9510be81f562f6d35500ac47723', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/lxc_hosts'} failed after 2 retries\\n\"], [\"Role {'name': 'rsyslog_client', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-rsyslog_client', 'version': 'd616af7883bd6e7a208be3a4f56d129bc2aa92ca', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/rsyslog_client'} failed after 2 retries\\n\"], [\"Role {'name': 'openstack_openrc', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-openstack_openrc', 'version': '242772e99978fe9cd3c50b5b40d5637833f38beb', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/openstack_openrc'} failed after 2 retries\\n\"], [\"Role {'name': 'os_ceilometer', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-os_ceilometer', 'version': '6df1fb0fc5610c2f317b5085188b0a60346e7111', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/os_ceilometer'} failed after 2 retries\\n\"], [\"Failed to reset /etc/ansible/roles/os_keystone\\nCmd('git') failed due to: exit code(129)\\n cmdline: git reset --force --hard f1625b38a820dd51cffa66141053a836211695dc\\n stderr: 'error: unknown option `force'\\nusage: git reset [--mixed | --soft | --hard | --merge | --keep] [-q] [<commit>]\\n or: git reset [-q] [<tree-ish>] [--] <pathspec>...\\n or: git reset [-q] [--pathspec-from-file [--pathspec-file-nul]] [<tree-ish>]\\n or: git reset --patch [<tree-ish>] [--] [<pathspec>...]\\n\\n -q, --quiet be quiet, only report errors\\n --mixed reset HEAD and index\\n --soft reset only HEAD\\n --hard reset HEAD, index and working tree\\n --merge reset HEAD, index and working tree\\n --keep reset HEAD but keep local changes\\n --recurse-submodules[=<reset>]\\n control recursive updating of submodules\\n -p, --patch select hunks interactively\\n -N, --intent-to-add record only the fact that removed paths will be added later\\n --pathspec-from-file <file>\\n read pathspec from file\\n --pathspec-file-nul with --pathspec-from-file, pathspec elements are separated with NUL character\\n'\"], [\"Role {'name': 'openstack_hosts', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-openstack_hosts', 'version': '8ab8503a15ad5cfe504777647922be301ddac911', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/openstack_hosts'} failed after 2 retries\\n\"], [\"Role {'name': 'os_sahara', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-os_sahara', 'version': '0f9e76292461a5532f6d43927b71ab9fff692dd5', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/os_sahara'} failed after 2 retries\\n\"], [\"Role {'name': 'os_tempest', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-os_tempest', 'version': '49004fb05fa491275848a07020a36d4264ab6d49', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/os_tempest'} failed after 2 retries\\n\"], [\"Role {'name': 'ceph-ansible', 'scm': 'git', 'src': 'https://github.com/ceph/ceph-ansible', 'version': '7d088320df1c4a6ed458866c61616a21fddccfe8', 'trackbranch': 'stable-5.0', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/ceph-ansible'} failed after 2 retries\\n\"], [\"Role {'name': 'galera_server', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-galera_server', 'version': '0b853b1da7802f6fac8da309c88886186f6a15a6', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/galera_server'} failed after 2 retries\\n\"], [\"Role {'name': 'os_nova', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-os_nova', 'version': '43b1b62f22b47e3148adcc4cd2396a4e29522e9b', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/os_nova'} failed after 2 retries\\n\"], [\"Role {'name': 'os_keystone', 'scm': 'git', 'src': 'https://opendev.org/openstack/openstack-ansible-os_keystone', 'version': 'f1625b38a820dd51cffa66141053a836211695dc', 'trackbranch': 'stable/victoria', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 10, 'dest': '/etc/ansible/roles/os_keystone'} failed after 2 retries\\n\"]]\n", "module_stdout": "", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1} PLAY RECAP ****************************************************************************************************************************************************************************************** localhost : ok=4 changed=0 unreachable=0 failed=1 skipped=8 rescued=0 ignored=0 ++ exit_fail 405 0 ++ set +x Last metadata expiration check: 2:12:54 ago on Wed 10 Feb 2021 01:34:28 PM IST. Package iproute-5.3.0-5.el8.x86_64 is already installed. Dependencies resolved. Nothing to do. Complete! Failed to get DNSSEC supported state: Unit dbus-org.freedesktop.resolve1.service not found. which: no lxc-ls in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin) which: no lxc-checkconfig in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin) which: no networkctl in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin) [WARNING]: Skipping callback plugin '/dev/null', unable to load which: no btrfs in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin :/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin) which: no btrfs in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin :/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin) which: no zfs in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/ usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin) ++ info_block 'Error Info - 405' 0 ++ echo ---------------------------------------------------------------------- ---------------------------------------------------------------------- ++ print_info 'Error Info - 405' 0 ++ PROC_NAME='- [ Error Info - 405 0 ] -' ++ printf '\n%s%s\n' '- [ Error Info - 405 0 ] -' ------------------------------ -------------- - [ Error Info - 405 0 ] --------------------------------------------- ++ echo ---------------------------------------------------------------------- ---------------------------------------------------------------------- ++ exit_state 1 ++ set +x ---------------------------------------------------------------------- - [ Run Time = 163 seconds || 2 minutes ] ---------------------------- ---------------------------------------------------------------------- ---------------------------------------------------------------------- - [ Status: Failure ] ------------------------------------------------ ---------------------------------------------------------------------- Pls suggest how to fix these issues thanks. Regards, Amey.

2 4

[baremetal-sig][ironic] Tue Feb 9, 2021, 2pm UTC: Deploy Steps in Ironic
by Arne Wiebalck 10 Feb '21

10 Feb '21

Dear all, The Bare Metal SIG will meet tomorrow Tue Feb 9, 2021 at 2pm UTC on zoom. This time there will be a 10 minute "topic-of-the-day" presentation by Dmitry Tantsur (dtansur) on: 'An Introduction to Deploy Steps in Ironic' If you've never found the time to understand what deploy steps are and how they are useful, this is your chance to hear it from one of the experts! You can find all the details for this meeting on the SIG's etherpad: https://etherpad.opendev.org/p/bare-metal-sig Everyone is welcome, don't miss out! Cheers, Arne

2 1

[charms] OpenStack Charms 21.01 release is now available
by Peter Matulis 10 Feb '21

10 Feb '21

The 21.01 release of the OpenStack Charms is now available. This release brings several new features to the existing OpenStack Charms deployments for Queens, Rocky, Stein, Train, Ussuri, Victoria and many stable combinations of Ubuntu + OpenStack. Please see the Release Notes for full details: https://docs.openstack.org/charm-guide/latest/2101.html == Highlights == * Cinder-Ceph - Image mirroring The cinder-ceph charm now supports image replication to a second Ceph cluster. * Ironic charms Three new tech-preview charms are now available for the deployment of OpenStack Ironic. Ironic provisions bare metal machines, as opposed to virtual machines. * Glance multi-backend usage When multiple storage backends are used with Glance, the glance charm now supports the CLI Glance client option (--store) that enables an operator to specify, at image upload time, which backend will be used to store the image. * Documentation updates Ongoing improvements to the OpenStack Charms Deployment Guide, the OpenStack Charm Guide, and the charm READMEs. * Trusty series deprecation The ‘trusty’ series is no longer actively tested and is now EOL in terms of bug fixes for the OpenStack charms. == OpenStack Charms team == The OpenStack Charms team can be contacted on the #openstack-charms IRC channel on Freenode. == Thank you == Lots of thanks to the below 33 contributors who squashed 52 bugs, enabled new features, and improved the documentation! Alex Kavanagh Alvaro Uria Andrea Ieri Arif Ali Aurelien Lourot Billy Olsen Corey Bryant David Ames Dmitrii Shcherbakov Dongdong Tao Edward Hope-Morley Eric Desrochers Felipe Reyes Frode Nordahl Gabriel Samfira Garrett Thompson Giuseppe Petralia Hemanth Nakkina Ioanna Alifieraki Ionut Balutoiu Jarred Wilson Liam Young Linda Guo Marius Oprin Martin Fiala Martin Kalcok Peter Matulis Peter Sabaini Ponnuvel Palaniyappan Robert Gildein Rodrigo Barbieri Trent Lloyd Xav Paice -- OpenStack Charms Team

1 0

[release] Proposing Előd Illés (elod) for Release Management Core
by Herve Beraud 10 Feb '21

10 Feb '21

Hi, Előd has been working on Release management for quite some time now and in that time has shown tremendous growth in his understanding of our processes and on how deliverables work on Openstack. I think he would make a good addition to the core team. Existing team members, please respond with +1/-1. If there are no objections we'll add him to the ACL soon. :-) Thanks. -- 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-----

5 5

[QA] Migrate from testr to stestr
by Martin Kopec 10 Feb '21

10 Feb '21

Hi everyone, testr unit test runner (testrepository package [1]) hasn't been updated for years, therefore during Shanghai PTG [2] we came up with an initiative to migrate from testr to stestr (testr's successor) [3] unit test runner. Here is an etherpad which tracks the effort [4]. However as there is still quite a number of the projects which haven't migrated, we would like to kindly ask you for your help. If you are a maintainer of a project which is mentioned in the etherpad [4] and it's not crossed out yet, please migrate to stestr. [1] https://pypi.org/project/testrepository/ [2] https://etherpad.opendev.org/p/shanghai-ptg-qa [3] https://pypi.org/project/stestr/ [4] https://etherpad.opendev.org/p/enkM4eeDHObSloTjPGAu Have a nice day, -- Martin Kopec Software Quality Engineer Red Hat EMEA <https://www.redhat.com> <https://red.ht/sig>

6 5

[nova] Rescue booting on wrong disk
by Arnaud Morin 10 Feb '21

10 Feb '21

Hey all, >From time to time we are facing an issue when puting instance in rescue with the same image as the one the instance was booted. E.G. I booted an instance using Debian 10, disk are: debian@testarnaud:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 486K 0 rom vda 254:0 0 10G 0 disk └─vda1 254:1 0 10G 0 part / debian@testarnaud:~$ cat /etc/fstab # /etc/fstab: static file system information. UUID=5605171d-d590-46d5-85e2-60096b533a18 / ext4 errors=remount-ro 0 1 I rescued the instance: $ openstack server rescue --image bc73a901-6366-4a69-8ddc-00479b4d647f testarnaud Then, back in the instance: debian@testarnaud:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 486K 0 rom vda 254:0 0 2G 0 disk └─vda1 254:1 0 2G 0 part vdb 254:16 0 10G 0 disk └─vdb1 254:17 0 10G 0 part / Instance booted on /dev/vdb1 instead of /dev/vda1 Is there anything we can configure on nova side to avoid this situation? Thanks -- Arnaud Morin

4 3

[cinder][ceph] improving storage latency
by Ionut Biru 10 Feb '21

10 Feb '21

Hi guys, Currently in one locations we have the underlay for ceph running over tcp ip with solarflare networking cards attached to 40G switches. We use OSA to deploy openstack and we follow their network layout e.g br-storage. 3 nodes with mixed storage type, ssd and hdd. We want to deploy a new ceph cluster in a new region but we want to improve our ceph installation overlay to have lower latency. What do you guys use in your infrastructure? -- Ionut Biru - https://fleio.com

1 0

[largescale-sig] OpenStack DB Archiver
by Arnaud Morin 10 Feb '21

10 Feb '21

Hello large-scalers! TLDR: we opensource a tool to help reducing size of databases. See https://github.com/ovh/osarchiver/ Few months ago, we released a tool, name osarchiver, which we are using on our production environment (at OVH) to help reduce the size of our tables in mariadb (or mysql) In fact, some tables are well know to grow very quickly. We use it, for example, to clean the OpenStack mistral database from old tasks, actions and executions which are older than a year. Another use case could be to archive some data in another table (e.g. with _archived as suffix) if they are 6 months old, and delete this data after 1 year. The source code of this tool is available here: https://github.com/ovh/osarchiver/ We were wondering if some other users would be interested in using the tool, and maybe move it under the opendev governance? Feel free to contact us and/or answer this thread. Cheers, -- Arnaud, Pierre-Samuel and OVH team

12 18

[cinder] wallaby new driver - kioxia kumoscale
by Brian Rosmaita 09 Feb '21

09 Feb '21

I'm proposing that we extend the wallaby new driver merge deadline for the kioxia kumoscale driver to Friday 12 February 2021 to give the reviewers who committed to reviewing the patches at the cinder meeting last week [0] time to complete their reviews of the driver [1] and os-brick [2] changes. The Kioxia 3rd party CI is running and responding to patches, and the dev team has been very responsive to reviews and posted revisions quickly. This extension past the standing Milestone-2 deadline for new drivers is due to limited review bandwidth this cycle which I am attributing to stress caused by the ongoing pandemic, so this should not be considered a precedent applicable to new drivers proposed for future releases. If you have comments or concerns about this proposal, please respond to this email so we can discuss at the virtual mid-cycle meeting tomorrow. And if you have committed to reviewing one of the patches and have not done it yet, please review as soon as possible! cheers, brian [0] http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-02-03-14.00… [1] https://review.opendev.org/c/openstack/cinder/+/768574 [2] https://review.opendev.org/c/openstack/os-brick/+/768575

1 0

[tc] weekly update
by Mohammed Naser 09 Feb '21

09 Feb '21

Hi everyone, Here's an update on what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Patches ## Open Reviews - Retire tempest-horizon https://review.opendev.org/c/openstack/governance/+/774379 - Cool-down cycle goal https://review.opendev.org/c/openstack/governance/+/770616 - monasca-log-api & monasca-ceilometer does not make releases https://review.opendev.org/c/openstack/governance/+/771785 - Add assert:supports-api-interoperability tag to neutron https://review.opendev.org/c/openstack/governance/+/773090 - Add assert:supports-api-interoperability to cinder https://review.opendev.org/c/openstack/governance/+/773684 ## Project Updates - Remove Karbor project team https://review.opendev.org/c/openstack/governance/+/767056 - Create ansible-role-pki repo https://review.opendev.org/c/openstack/governance/+/773383 - Add rbd-iscsi-client to cinder project https://review.opendev.org/c/openstack/governance/+/772597 ## General Changes - Define Xena release testing runtime https://review.opendev.org/c/openstack/governance/+/770860 - [manila] add assert:supports-api-interoperability https://review.opendev.org/c/openstack/governance/+/770859 - Define 2021 upstream investment opportunities https://review.opendev.org/c/openstack/governance/+/771707 # Other Reminders - Our next [TC] Weekly meeting is scheduled for February 11th at 1500 UTC. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, February 10th, 2100 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

[cinder] reminder: wallaby R-9 virtual mid-cycle tomorrow (wednesday)
by Brian Rosmaita 09 Feb '21

09 Feb '21

Reminder: no cinder meeting tomorrow, instead we're having a virtual mid-cycle meeting: DATE: Wednesday, 10 February 2021 TIME: 1400-1600 UTC (2 hours) LOCATION: https://bluejeans.com/3228528973 The meeting will be recorded. Topics are on the planning etherpad. (For people who have been procrastinating, there's probably room for one or two more topics.) https://etherpad.opendev.org/p/cinder-wallaby-mid-cycles cheers, brian

1 0

[stein][manila] share migration misconfiguration ?
by Ignazio Cassano 09 Feb '21

09 Feb '21

Hello All, I am trying to migrate a share between a netapp backend to another. Both backends are configured in my manila.conf. I am able to create share on both, but I am not able to migrate share between them. I am using DSSH=False. I did not understand how host and driver assisted migration work and what "data_node_access_ip" means. The share I want to migrate is on a network (10.102.186.0/24) that I can reach by my management controllers network (10.102.184.0/24). I Can mount share from my controllers and I can mount also the netapp SVM where the share is located. So in the data_node_access_ip I wrote the list of my controllers management ips. During the migrate phase I checked if my controller where manila is running mounts the share or the netapp SVM but It does not happen. Please, what is my mistake ? Thanks Ignazio

3 17

[nova][placement] adding nova-core to placement-core in gerrit
by Balazs Gibizer 09 Feb '21

09 Feb '21

Hi, Placement got back under nova governance but so far we haven't consolidated the core teams yet. Stephen pointed out to me that given the ongoing RBAC works it would be beneficial if more nova cores, with API and RBAC experience, could approve such patches. So I'm proposing to add nova-core group to the placement-core group in gerrit. This means Ghanshyam, John, Lee, and Melanie would get core rights in the placement related repositories. @placement-core, @nova-core members: Please let me know if you have any objection to such change until end of this week. cheers, gibi

6 9

[kolla] Stein base container build fails
by Eric K. Miller 08 Feb '21

08 Feb '21

Hi, I'm trying to update a few things in a Stein cluster and while building some kolla containers, I get the following error when building the base container: INFO:kolla.common.utils.openstack-base:Step 4/8 : RUN curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py && python get-pip.py && rm get-pip.py INFO:kolla.common.utils.openstack-base: ---> Running in f5c8bb3fe6f0 INFO:kolla.common.utils.openstack-base:curl (https://bootstrap.pypa.io/get-pip.py) response: 200, time: 0.423, size: 1929903 INFO:kolla.common.utils.openstack-base:Traceback (most recent call last): INFO:kolla.common.utils.openstack-base: File "get-pip.py", line 24244, in <module> INFO:kolla.common.utils.openstack-base: INFO:kolla.common.utils.openstack-base: main() INFO:kolla.common.utils.openstack-base: File "get-pip.py", line 199, in main INFO:kolla.common.utils.openstack-base: bootstrap(tmpdir=tmpdir) INFO:kolla.common.utils.openstack-base: File "get-pip.py", line 82, in bootstrap INFO:kolla.common.utils.openstack-base: from pip._internal.cli.main import main as pip_entry_point INFO:kolla.common.utils.openstack-base: File "/tmp/tmpDXRruf/pip.zip/pip/_internal/cli/main.py", line 60 INFO:kolla.common.utils.openstack-base: sys.stderr.write(f"ERROR: {exc}") INFO:kolla.common.utils.openstack-base: INFO:kolla.common.utils.openstack-base: ^ INFO:kolla.common.utils.openstack-base:SyntaxError: invalid syntax INFO:kolla.common.utils.openstack-base: INFO:kolla.common.utils.openstack-base:Removing intermediate container f5c8bb3fe6f0 ERROR:kolla.common.utils.openstack-base:Error'd with the following message ERROR:kolla.common.utils.openstack-base:The command '/bin/sh -c curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py && python get-pip.py && rm get-pip.py' returned a non-zero code: 1 Any ideas as to where the issue is? Is this a pip installer bug? Eric

2 1

[ironic] On redfish-virtual-media vs idrac-redfish-virtual-media
by Dmitry Tantsur 08 Feb '21

08 Feb '21

Hi all, Now that we've gained some experience with using Redfish virtual media I'd like to reopen the discussion about $subj. For the context, the idrac-redfish-virtual-media boot interface appeared because Dell machines need an additional action [1] to boot from virtual media. The initial position on hardware interfaces was that anything requiring OEM actions must go into a vendor hardware interface. I would like to propose relaxing this (likely unwritten) rule. You see, this distinction causes a lot of confusion. Ironic supports Redfish, ironic supports iDRAC, iDRAC supports Redfish, ironic supports virtual media, Redfish supports virtual media, iDRAC supports virtual media. BUT! You cannot use redfish-virtual-media with iDRAC. Just today I had to explain the cause of it to a few people. It required diving into how exactly Redfish works and how exactly ironic uses it, which is something we want to protect our users from. We already have a precedent [2] of adding vendor-specific handling to a generic driver. I have proposed a patch [3] to block using redfish-virtual-media for Dell hardware, but I grew to dislike this approach. It does not have precedents in the ironic code base and it won't scale well if we have to handle vendor differences for vendors that don't have ironic drivers. Based on all this I suggest relaxing the rule to the following: if a feature supported by a generic hardware interface requires additional actions or has a minor deviation from the standard, allow handling it in the generic hardware interface. Meaning, redfish-virtual-media starts handling the Dell case by checking the System manufacturer (via the recently added detect_vendor call) and loading the OEM code if it matches "Dell". After this idrac-redfish-virtual-media will stay empty (for future enhancements and to make the patch backportable). Thoughts? Dmitry [1] https://opendev.org/openstack/ironic/src/commit/6ea73bdfbb53486cf9905d21024… [2] https://review.opendev.org/c/openstack/ironic/+/757198/ [3] https://review.opendev.org/c/openstack/ironic/+/771619 -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

5 7

[TripleO] Fwd: Planned outage of review.rdoproject.org: 2021-02-11 from 14:00 to 18:00 UTC
by Nicolas Hicher 08 Feb '21

08 Feb '21

-------- Forwarded Message -------- From: Nicolas Hicher <nhicher(a)redhat.com> Subject: Planned outage of review.rdoproject.org: 2021-02-11 from 14:00 to 18:00 UTC To: dev(a)lists.rdoproject.org Message-ID: <891d4c95-0f55-3452-d0b5-54a54aab0941(a)redhat.com> Date: Mon, 8 Feb 2021 17:31:36 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Hello folks, Our cloud provider plans to do maintainance operation on 2021-02-11 from 14:00 to 18:00 UTC. Service interruption is expected, including: - Zuul CI not running jobs for gerrit, github or opendev. - RDO Trunk not building new packages. - DLRN API. - review.rdoproject.org and softwarefactory-project.io gerrit service. - www.rdoproject.org and lists.rdoproject.org. We expect that the interruption of services will be less than 4 hours. Regards, Nicolas , on behalf of the Software Factory Operation Team

1 0

RE: [kolla] Stein base container build fails
by Eric K. Miller 08 Feb '21

08 Feb '21

Looks like a Python3 error as described here: https://stackoverflow.com/questions/65896334/python-pip-broken-wiith-sys -stderr-writeferror-exc Looks like we need some way to choose to use the older version of pip using: curl https://bootstrap.pypa.io/2.7/get-pip.py -o get-pip.py instead of: curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py Eric

1 0

Rally - Unable to install rally - install_rally.sh is not available in repo
by Ankit Goel 08 Feb '21

08 Feb '21

Hello Experts, I was trying to install Openstack rally on centos 7 VM but the link provided in the Openstack doc to download the install_rally.sh is broken. Latest Rally Doc link - > https://docs.openstack.org/rally/latest/install_and_upgrade/install.html#au… Rally Install Script -> https://raw.githubusercontent.com/openstack/rally/master/install_rally.sh - > This is broken After searching on internet I could reach to the Openstack rally Repo - > https://opendev.org/openstack/rally but here I am not seeing the install_ rally.sh script and according to all the information available on internet it says we need install_ rally.sh. Thus can you please let me know what's the latest procedure to install Rally. Awaiting for your response. Thanks, Ankit Goel

4 12

[cinder] bug deputy report for week of 2021-02-01
by Sofia Enriquez 08 Feb '21

08 Feb '21

This is a bug report from 2021-01-27 to 2021-01-05. Most of this bugs were discussed at the Cinder meeting last Wednesday 2021-02-03 Critical: - High: - Medium: - https://bugs.launchpad.net/cinder/+bug/1914319: "DellEMC VNX driver: volume is not created on array but status is 'available' in openstack". Assigned to Yong Huan. - https://bugs.launchpad.net/cinder/+bug/1913578: "PowerFlex documentation contains invalid paths". Unassigned. - https://bugs.launchpad.net/python-cinderclient/+bug/1913474: "Cinderclient needs to support mv 3.63". Unassigned. Low: - https://bugs.launchpad.net/cinder/+bug/1913705: "OsProfiler does not work". Unassigned. Incomplete: - https://bugs.launchpad.net/cinder/+bug/1913363: "Multiple calls to lshost during attach operation". Assigned to Girish Chilukuri. Undecided/Unconfirmed: - https://bugs.launchpad.net/cinder/+bug/1914639: "[NetApp] Issue while trying to attach a volume using CHAP authentication". Unassigned. Not a bug: - https://bugs.launchpad.net/cinder/+bug/1914273: "After attachment-delete nova still sees volume as attached". Feel free to reply/reach me if I missed something. Regards Sofi -- L. Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[KEYSTONE][FEDERATION] Groups mapping problem when using keycloak as IDP
by Taltavull Jean-Francois 08 Feb '21

08 Feb '21

Hello, In order to implement identity federation, I've deployed (with OSA) keystone (Ussuri) as Service Provider and Keycloak as IDP. As one can read at [1], "groups" can have multiple values and each value must be separated by a ";" But, in the OpenID token sent by keycloak, groups are represented with a JSON list and keystone fails to parse it well (only the first group of the list is mapped). Have any of you already faced this problem ? Thanks ! Jean-François [1] https://docs.openstack.org/keystone/ussuri/admin/federation/mapping_combina…

2 3

[stein][hypervisor] Post successful stein deployment Openstack hypervisor list is empty
by roshan anvekar 08 Feb '21

08 Feb '21

Hi all, Scenario: I have an installation of Openstack stein through kolla-ansible. The deployment went fine and all services look good. Although I am seeing that under Admin--> Compute --> Hypervisors panel in horizon, all the controller nodes are missing. It's a blank list. Also "Openstack hypervisor list" gives an empty list. I skimmed through the logs and found no error message other than in nova-scheduler that: *Got no allocation candidates from the Placement API. This could be due to insufficient resources or a temporary occurence as compute nodes start up.* Subsequently I checked placement container logs and found no error message or anamoly. Not sure what the issue is. Any help in the above case would be appreciated. Regards, Roshan

4 9