January 2025 - openstack-discuss - lists.openstack.org

Discussion of OpenStack development getting Error.
by Kiran Raja 05 Feb '25

05 Feb '25

Hi Team, We have deployed Open stack and when we are trying to access Neutron Gateway from the Controller node we are unable to access, but It is access able from Namespace Created in neutron , please help me on neutron configuration we are using Self-provision Network Option. root@controller:~# openstack router list +--------------------------------------+--------------+--------+-------+----------------------------------+-------------+-------+ | ID | Name | Status | State | Project | Distributed | HA | +--------------------------------------+--------------+--------+-------+----------------------------------+-------------+-------+ | 16d92543-e9a3-4e97-bdb0-ccb3a8b8dd99 | Admin_Router | ACTIVE | UP | 523711770d5243dd9af5b2356b540b07 | False | False | +--------------------------------------+--------------+--------+-------+----------------------------------+-------------+-------+ root@controller:~# ip netns exec qrouter-16d92543-e9a3-4e97-bdb0-ccb3a8b8dd99 ip route default via 172.16.86.1 dev qg-afb1772f-2f proto static 172.16.86.0/24 dev qg-afb1772f-2f proto kernel scope link src 172.16.86.49 root@controller:~# ip netns exec qrouter-16d92543-e9a3-4e97-bdb0-ccb3a8b8dd99 route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 172.16.86.1 0.0.0.0 UG 0 0 0 qg-afb1772f-2f 172.16.86.0 0.0.0.0 255.255.255.0 U 0 0 0 qg-afb1772f-2f root@controller:~# ip netns exec qrouter-16d92543-e9a3-4e97-bdb0-ccb3a8b8dd99 ping 172.16.86.1 PING 172.16.86.1 (172.16.86.1) 56(84) bytes of data. ^C --- 172.16.86.1 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2042ms root@controller:~# ip netns exec qrouter-16d92543-e9a3-4e97-bdb0-ccb3a8b8dd99 ip address 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 13: qg-afb1772f-2f: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether fa:16:3e:d1:58:50 brd ff:ff:ff:ff:ff:ff inet 172.16.86.49/24 brd 172.16.86.255 scope global qg-afb1772f-2f valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fed1:5850/64 scope link valid_lft forever preferred_lft forever root@controller:~# ip netns exec qrouter-16d92543-e9a3-4e97-bdb0-ccb3a8b8dd99 ping 172.16.86.49 PING 172.16.86.49 (172.16.86.49) 56(84) bytes of data. 64 bytes from 172.16.86.49: icmp_seq=1 ttl=64 time=0.073 ms 64 bytes from 172.16.86.49: icmp_seq=2 ttl=64 time=0.113 ms ^C --- 172.16.86.49 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1003ms rtt min/avg/max/mdev = 0.073/0.093/0.113/0.020 ms root@controller:~# ping 172.16.86.49 PING 172.16.86.49 (172.16.86.49) 56(84) bytes of data. ^C --- 172.16.86.49 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1048ms root@controller:~# ip netns exec qrouter-16d92543-e9a3-4e97-bdb0-ccb3a8b8dd99 ip address 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 13: qg-afb1772f-2f: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether fa:16:3e:d1:58:50 brd ff:ff:ff:ff:ff:ff inet 172.16.86.49/24 brd 172.16.86.255 scope global qg-afb1772f-2f valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fed1:5850/64 scope link valid_lft forever preferred_lft forever 15: qr-6be4aabd-b9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether fa:16:3e:df:a9:ad brd ff:ff:ff:ff:ff:ff inet 172.16.100.1/24 brd 172.16.100.255 scope global qr-6be4aabd-b9 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fedf:a9ad/64 scope link valid_lft forever preferred_lft forever root@controller:~# ping 172.16.86.1 PING 172.16.86.1 (172.16.86.1) 56(84) bytes of data. 64 bytes from 172.16.86.1: icmp_seq=1 ttl=64 time=0.204 ms ^C --- 172.16.86.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.204/0.204/0.204/0.000 ms root@controller:~# 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 noprefixroute valid_lft forever preferred_lft forever 2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:0c:29:25:f8:21 brd ff:ff:ff:ff:ff:ff altname enp3s0 inet 172.16.85.11/24 brd 172.16.85.255 scope global ens160 valid_lft forever preferred_lft forever inet6 fe80::20c:29ff:fe25:f821/64 scope link valid_lft forever preferred_lft forever 3: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP group default qlen 1000 link/ether 00:0c:29:25:f8:2b brd ff:ff:ff:ff:ff:ff altname enp11s0 inet6 fe80::20c:29ff:fe25:f82b/64 scope link valid_lft forever preferred_lft forever 4: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 2e:14:3b:10:5d:42 brd ff:ff:ff:ff:ff:ff 5: br-tun: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 02:fb:f2:93:65:46 brd ff:ff:ff:ff:ff:ff inet6 fe80::fb:f2ff:fe93:6546/64 scope link valid_lft forever preferred_lft forever 6: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 00:0c:29:25:f8:2b brd ff:ff:ff:ff:ff:ff inet6 fe80::20c:29ff:fe25:f82b/64 scope link valid_lft forever preferred_lft forever 7: br-int: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 72:cb:66:8a:21:4c brd ff:ff:ff:ff:ff:ff inet6 fe80::70cb:66ff:fe8a:214c/64 scope link valid_lft forever preferred_lft forever root@controller:~# ovs-vsctl show 77dc413c-c4a0-4c7a-b3e2-3ba8ecf5bee7 Manager "ptcp:6640:127.0.0.1" is_connected: true Bridge br-int Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port br-int Interface br-int type: internal Port qg-afb1772f-2f tag: 2 Interface qg-afb1772f-2f type: internal Port qr-6be4aabd-b9 tag: 3 Interface qr-6be4aabd-b9 type: internal Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port tap93e5731e-d9 tag: 2 Interface tap93e5731e-d9 type: internal Port tap52dcef2e-c9 tag: 3 Interface tap52dcef2e-c9 type: internal Port int-br-ex Interface int-br-ex type: patch options: {peer=phy-br-ex} Bridge br-tun Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port br-tun Interface br-tun type: internal Bridge br-ex Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port phy-br-ex Interface phy-br-ex type: patch options: {peer=int-br-ex} Port br-ex Interface br-ex type: internal Port ens192 Interface ens192 ovs_version: "3.4.0" Thanks and Regards CH Kiran Raja M: +91 9959503256 [cid:1df6874c-4456-494d-9e7c-aa3aed63e7af]<https://pidatacenters.com/> [cid:693f6ef0-1ee9-4ea9-a345-8488a3aa8c2b]<https://harbour1.in/> kiran.raja(a)pidatacenters.com<mailto:kiran.raja@pidatacenters.com> [cid:0770d139-f2b6-424b-a451-6ad2a391a96b]

3 3

VPNaaS
by Vincent Godin 04 Feb '25

04 Feb '25

Hello, The VPNaaS provided with Openstack is a Site-to-Site VPN made to interconnect two tenants or an external gateway with a tenant network. I would like to know if there are plans to offer a VPNaaS more like a Remote VPN. This would allow Openstack users to administer their instances securely. A user could mount this VPN from a roaming device, be assigned a local IP address, and then administer the instances of his tenant. Regards Vincent

3 2

[watcher] core team expansion
by Sean Mooney 04 Feb '25

04 Feb '25

Hi everyone, As you may be aware a number of us from Redhat have been trying to revitalize the Watcher project. To enable that one of the changes that we previously discussed on the mailing list and ptg was the expansion of the core team. https://etherpad.opendev.org/p/r.79644f8f3cd04686c4f45c10aa35d8ac#L46 https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… In November the initial phase of that proposal was completed and I took an action to follow up in Q1 to see what steps are needed to rebuild a healthy core team. based on the activity of the last 90 days and the progress of work I think it is time to expand the core teams once again to enable effective maintenance and development of watcher https://openstack.biterg.io/app/dashboards#/view/95487340-6762-11e9-a198-67…:'Gerrit%20Approvals%20panel%20by%20Bitergia',filters:!(('$state':(store:appState),meta:(alias:Bots,disabled:!f,index:gerrit,key:author_bot,negate:!t,params:(query:!t),type:phrase),query:(match:(author_bot:(query:!t,type:phrase)))),('$state':(store:appState),meta:(alias:!n,disabled:!f,index:gerrit,key:project,negate:!f,params:(query:watcher),type:phrase),query:(match_phrase:(project:watcher)))),fullScreenMode:!f,options:(darkTheme:!f,hidePanelTitles:!f,useMargins:!t),query:(language:lucene,query:''),timeRestore:!f,title:'Gerrit%20Approvals',viewMode:view) tiny url version of ^ https://tinyurl.com/439wzbdk https://www.stackalytics.io/?module=watcher-group the current core teams are as follows * watcher-core https://review.opendev.org/admin/groups/77cd139bd57514e98e5e694a82f7e261b47… * watcher-dashboard-core https://review.opendev.org/admin/groups/bcc8588732437ceea3533249313e6e96148… * watcher-specs-core https://review.opendev.org/admin/groups/747af616eb8748aee5b17d9493f9ebbc49e… * watcher-tempest-core https://review.opendev.org/admin/groups/09a91d8e24af9ce44b80062c4851a1d2fa3… starting in order watcher-core: https://tinyurl.com/2p8sr7u4 https://www.stackalytics.io/?module=opendev.org/openstack/watcher - add Marios Andreou - add Douglas Viroel Marios and Doug both have past experience as core reviews in other OpenStack projects (triple-o and Manilla), over the last 90 days, they have engaged in reviews of bug fixes and the development of the new Prometheus data source. watcher-dashboard-core: https://tinyurl.com/4259h8nz https://www.stackalytics.io/?module=opendev.org/openstack/watcher-dashboard - add Marios Andreou - add Douglas Viroel as with Watcher itself Doug and Marios have spent time looking at the open review for the watcher-dashboard. watcher-spec-core: is tricky as we have effective only had one spec this cycle that was written by Marios with some minor patches for ci. As watcher core is a member of watcher-spec-core, Marios and Doug will inherit review rights on the specs repo. At this time I do not see a need to make any other changes to the group membership. watcher-tempest-core: https://tinyurl.com/4nbctef8 https://www.stackalytics.io/?module=opendev.org/openstack/watcher-tempest-p… - add Chandan Kumar - add Douglas Viroel - remove Martin Kopec As many of you may know Martin has taken up a new role in Redhat outside of OpenStack and will no longer be working directly on OpenStack. Over the last 90 days, Martin and Gmann have modernized the tempest plugin significantly paying down much of the tech debt. I want to thank them for the efforts they put in to help revive Watcher this cycle and if they return to the OpenStack community in the future I will gladly welcome them back. In their stead, I am proposing adding Chandan and Doug to augment the existing core group. As agreed in the Watcher team meeting earlier today we will review this mail thread in the next Watcher IRC meeting next week. I would like to invite others to provide feedback on this proposal over the next week. In the next PTG, I will also raise the composition of the core teams for discussion. It is my hope that with these additions we will have at least 3 active reviews on all deliverables of the watcher project mitigating the current bus factor and accelerating development. Regards Sean.

1 1

[ironic]About the OS supported by Diskimage-builder
by Junya Noguchi (Fujitsu) 03 Feb '25

03 Feb '25

To whom it may concern. My name is Junya Noguchi. I have some questions about the supported OS for Diskimage-builder operation. Please respond. References https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html Does it mean that the OS that says "work but receive only limited testing and support" works but is not supported? References https://docs.openstack.org/diskimage-builder/latest/ This document describes RHEL and other operating systems that are not supported in the previous question. Are these operating systems supported? Also, are there any plans to support more operating systems in the future? Best regards, Junya Noguchi

5 7

[neutron] neutron-core/networking-ovn-core consolidation
by Brian Haley 03 Feb '25

03 Feb '25

Hello Neutrinos: I noticed the other day we still have the networking-ovn-core group [0] included in the neutron-core group [1], a left-over from when we merged the OVN code into the Neutron repo in Ussuri. Most people in the networking-ovn-core group no longer contribute to Neutron, except for one - Terry Wilson (otherwiseguy). In order to cleanup a little I'm going to consolidate things and add Terry as a member of the neutron-core group, and remove the import. Since he has basically been operating as a Neutron core reviewer already for years, I don't think we need to vote on this. So welcome officially Terry! -Brian, Neutron PTL [0] https://review.opendev.org/admin/groups/ecdeda6cb5657af51f20b282cd0525cb7e6… [1] https://review.opendev.org/admin/groups/38

6 5

OpenStack BoF at FOSDEM
by Amy Marrich 03 Feb '25

03 Feb '25

Hey all, Sorry for the late promotion but we will be having an OpenStack BoF at FOSDEM[0] on Saturday at 16:00 in room AW1.121. Hope to see you there! Amy 0 - https://fosdem.org/2025/schedule/event/fosdem-2025-4885-openstack-community…

3 3

[glance][security][vmt] propose Cyril Roelandt for glance coresec
by Brian Rosmaita 31 Jan '25

31 Jan '25

I'd like to propose an update to the Glance Core Security Contacts team [0], which handles embargoed security issues for Glance project deliverables. The OpenStack Vulnerability Management Team prefers to keep the project core security teams small (because otherwise it kind of defeats the point of having embargoed private security issues). Thus, the changes I propose will keep the glance-coresec team at its current size: Add: Cyril Roelandt (croelandt on IRC). Cyril has been a Glance core since June 2021 and is a thorough and respected reviewer and developer; he also organizes the recurring Glance Review Party. Remove: Erno Kuvaja (jokke on IRC). Erno has been focusing his time away from Glance. On behalf of the Glance project team, I thank Erno for his past service on glance-coresec, and note that Erno continues to participate in the Glance project as a "regular" glance core. If you have any concerns about this change, please communicate them to me or Pranali Deore (Glance PTL) before 23:59 UTC on Wednesday, 29 January 2025. cheers, brian [0] https://launchpad.net/~glance-coresec

1 1

[manila] driver_handles_share_servers not recognized as boolean
by Francesco Di Nucci 31 Jan '25

31 Jan '25

Hi all, I'm running OpenStack 2024.1 Caracal, configured through Puppet, and I'm having an issue with Manila. /etc/manila/manila.conf contains the line "driver_handles_share_servers = True", but setup fails, "/var/log/manila/share.log" reports that "Config opt 'driver_handles_share_servers' has improper value - 'None'. Please define it as boolean." Has anyone encountered this? Where else should I define this? Thanks in advance -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email: francesco.dinucci(a)na.infn.it

3 9

[all] Is oslo.vmware still relevant?
by Herve Beraud 31 Jan '25

31 Jan '25

Hey folks, I observed that oslo.vmware has not received any significant modifications since almost 4 years ago [1]. The only changes proposed to oslo.vmware since a while are just related to infra changes (python versions, tox versions, etc...). Due to the recent news about vmware [2], I wonder if oslo.vmware is still a relevant library in our context and I wonder if it is worth spending time on maintaining it. Do you think we should deprecate and retire this library? Thanks in advance for your opinions. [1] https://opendev.org/openstack/oslo.vmware/commits/branch/master [2] the broadcom story -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

5 6

[neutron] Drivers meeting agenda for Friday, January 31st
by Brian Haley 30 Jan '25

30 Jan '25

Hello Neutrinos: Sorry for the late notice but this is the agenda for tomorrow's drivers meeting: * [RFE] Allow rebalancing of OVN LRPs * https://bugs.launchpad.net/neutron/+bug/2096704 * We quickly discussed this in our weekly meeting and it seemed like a good idea See you then, -Brian

1 0