- openstack-discuss - lists.openstack.org

Guidance Required for OVN-BGP-Agent Configuration with EVPN Mode
by AkashMadan Talebailkar 26 Jan '25

26 Jan '25

Dear Community, I hope this email finds you well. I came across this insightful discussion on the OpenStack forum regarding the OVN-BGP-Agent Discussio<https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030080.…>n. We are doing research on openstack capability and would greatly appreciate your guidance. We are utilizing the OVN mechanism driver along with the OVN-BGP-Agent<https://github.com/openstack/ovn-bgp-agent/tree/master> in EVPN mode. Our objective is to establish BGP-EVPN between our leaf switch and the OpenStack controller. The OVN-BGP-Agent should advertise the IP and MAC addresses of VMs to its BGP peers. Please find attached the following details for your reference: bgp-agent.conf Agent configuration OVN_DB configuration Result We installed the OVN-BGP-Agent and FRR on the controller. Below are the steps we followed: Network Setup: Created a tenant network (NET) with a subnet of 121.168.0.0/24. Created a provider network (EXNET) with a subnet of 192.27.5.0/24. Router Configuration: Set up a router (newrouter) with an external network (EXNET) and unchecked SNAT. Added the NET interface to the router. OVN Database Configuration: Configured the OVN Northbound DB (detailed in the attachment). VM Creation: Deployed a VM in NET with the VM's IP 121.168.0.202 PFA for the agent configuration and FRR configuration done once agent VM has been created. Despite following the steps above, the VM IP is not visible in FRR, PFA for the result. Consequently, we are unable to advertise its route via BGP-EVPN. We kindly request your guidance to identify any potential misconfigurations or missing steps. Thank you for your time and support. Best regards, Akash Talebailkar Palc Networks akashmadan.t(a)palcnetworks.com +91 9035376555

2 1

[manila][cephfs][kollla-ansible]cannot create access rule on share
by Nguyễn Hữu Khôi 25 Jan '25

25 Jan '25

Hello. I setup manila with cephfs driver-CephFS NFS shares and I use NFS-Ganesha based “ceph nfs” service. This is my configuration: [DEFAULT] debug = true enabled_share_protocols = NFS,CIFS,CEPHFS [cephfsnfs1] driver_handles_share_servers = False share_backend_name = CEPHFSNFS1 share_driver = manila.share.drivers.cephfs.driver.CephFSDriver cephfs_protocol_helper_type = NFS cephfs_conf_path = /etc/ceph/ceph.conf cephfs_auth_id = manila cephfs_cluster_name = az1 cephfs_filesystem_name = cephfs I can create a share but cannot set access rule for it and I encountered this error in manila-share.log: 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.10/site-packages/manila/share/drivers/ganesha/manager.py", line 472, in add_export 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server self._dbus_send_ganesha("AddExport", "string:" + path, 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.10/site-packages/manila/share/drivers/ganesha/manager.py", line 410, in _dbus_send_ganesha 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server self.execute("dbus-send", "--print-reply", "--system", 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.10/site-packages/manila/share/drivers/ganesha/manager.py", line 240, in _execute 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server raise exception.GaneshaCommandFailure( 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server manila.exception.GaneshaCommandFailure: Ganesha management command failed. 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server Command: sudo manila-rootwrap /etc/manila/rootwrap.conf dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.AddExport string:/etc/ganesha/export.d/share-5d49f7c6-27a0-43c3-931d-56486b8f3d51.conf string:EXPORT(Export_Id=106) 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server Exit code: 96 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server Stdout: '' 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server Stderr: '/var/lib/kolla/venv/bin/manila-rootwrap: Executable not found: dbus-send (filter match = dbus-addexport)\n' One more thing, when I run openstack share export location list myshare I see lab-control01:/volumes/_nogroup/5d49f7c6-27a0-43c3-931d-56486b8f3d51/fb094ad8-9200-4c93-b800-304178f51136 lab-control01 is my openstack controller, is it right because nfs service is on ceph cluster. Thank you. Nguyen Huu Khoi

1 1

[all][PTLs][release] OpenStack 2025.2 Flamingo release schedule plan
by Elõd Illés 24 Jan '25

24 Jan '25

Hi everyone, Let me inform you that 2025.2 Flamingo release schedule plan can be reviewed: https://review.opendev.org/c/openstack/releases/+/939528 (or for better reading you can take a look at the generated preview for Patch Set 1 [1] but note that the link **only** works for Patch Set 1!) [1] https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/… Cheers, Előd Illés irc: elodilles @ #openstack-release

1 0

[kolla-ansible] Multipath unsuccesfull in nova
by Kamil Madac 24 Jan '25

24 Jan '25

Hello, I have a openstack deployed with kolla-ansible 2024.2. I'm trying to configure cinder and nova to use multipath when attaching volumes from the Hitachi SAN array. Without multipathing everything works good. When I enabled multipath in kolla-ansible (enable_multipathd: "yes"), deployment is without errors, volume can be created, but attachment of volume ends up with error in nova_compute container: ... 2025-01-22 12:16:02.962 2 ERROR nova.virt.block_device [instance: 714bd6f8-49e5-406f-b608-b7aaded2e728] raise exc_type(*result[2]) 2025-01-22 12:16:02.962 2 ERROR nova.virt.block_device [instance: 714bd6f8-49e5-406f-b608-b7aaded2e728] oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. 2025-01-22 12:16:02.962 2 ERROR nova.virt.block_device [instance: 714bd6f8-49e5-406f-b608-b7aaded2e728] Command: multipath -C dm-0 2025-01-22 12:16:02.962 2 ERROR nova.virt.block_device [instance: 714bd6f8-49e5-406f-b608-b7aaded2e728] Exit code: 1 2025-01-22 12:16:02.962 2 ERROR nova.virt.block_device [instance: 714bd6f8-49e5-406f-b608-b7aaded2e728] Stdout: '' 2025-01-22 12:16:02.962 2 ERROR nova.virt.block_device [instance: 714bd6f8-49e5-406f-b608-b7aaded2e728] Stderr: '3601817.750747 | /etc/multipath.conf does not exist, blacklisting all devices.\n3601817.750753 | You can run "/sbin/mpathconf --enable" to create\n3601817.750754 | /etc/multipath.conf. See man mpathconf(8) for more details\n3601817.751393 | sdd: error 2 in pathinfo, discarding path\n3601817.751501 | sde: error 2 in pathinfo, discarding path\n3601817.751504 | 360060e8012b142005040b14200000ee2: removing empty pathgroup 0\n3601817.751505 | dm-0: no usable paths found\n' When I manually added /etc/multipath.conf to nova_compute container, the attachment passed without any issues. I do not want to build special image only because of that single config file. My question is, how to make kolla-ansible to copy/add /etc/multipath.conf file into nova_compute service? Is there any mechanism for that? Thanks. Kamil Madac

3 4

[nova][neutron][ops] disabling the heal instance info cache periodic
by Sean Mooney 23 Jan '25

23 Jan '25

hi folks o/ This is a short PSA and request for comments The nova and neutron teams have discussed the existence and importantly the default behavior of nova's "heal instance info cache periodic" on an off for the better part of the last 4+ years but we never had time to take any action on it until now. Context for those who are not aware of it, nova has an instance info cache which we use to cache networking information such as ip address related to ports associated with an instance. This was introduced in the Essex release when nova networks was being replaced with quantum/neutron. Its rater fitting but over due that in the Epoxy release we are now turning this off. for more context i have captured some of the important point in the release note of the proposed change https://review.opendev.org/c/openstack/nova/+/939476/2/releasenotes/notes/d… But ill provide a TL;DR here. By default, as of essex, [compute]heal_instance_info_cache_interval defaulted to 60. it has been possible to disable this by setting the value to <=0 (recommended to use -1 by convention). when the periodic is enabled, every nova compute agent loop over the instance on the current host, retrieves all there ports form neutron and fully rebuilds the cache(as of stein). on a small cloud (less then 50 computes) this has minimal impact on the performance of the neutron server, on moderate to large clouds this creates 10s of MB of constant db read load. This has several side-effects: - first it creates unnecessary load on the neutron api and neutron db/network backend in creasing latency and reducing overall performance. - second, it create unnecessary load on rabbitmq as each compute service need to do an RPC to update the info cache(every 60 seconds). - third both of the first two waste power doing extra work that is not needed. - finally as of Icehouse this periodic has been optional because we added the os-server-external-events api so that neutron can tell nova if there has been a change to refresh the cache as needed. With that in mind hte nova team is proposing that we disable this going forward, for this release i have not deprecated the periodic so operators can re-enable it if they find its required for any reason. in the 2026.1 release we will likely revisit this based on operator feedback/bug reports. In this weeks team meeting we agree to wait 2 more weeks to get feedback from OPS if they had any concerns with this change hence this email. If anyone knows of a reason why we should not proceed with this default change feel free to let us know via this email thread or the gerrit review https://review.opendev.org/c/openstack/nova/+/939476 regards sean

2 1

April 2025 PTG Dates & Team Signup Kickoff
by Kendall Nelson 23 Jan '25

23 Jan '25

Hello Everyone, I am pleased to announce the next OpenInfra PTG[1] will be taking place April 7-11, 2025! Registration will open soon! To sign up your team, you must complete the survey[2] by February 21st at 7:00 UTC. We NEED accurate contact information (email and and IRC nickname ideally) for the moderator of your team’s sessions. This is because the survey information will be used to organize the schedule signups which will be done via the PTGBot. If you are not on IRC, please get setup[3] on the OFTC network and join #openinfra-events. You are also encouraged to familiarize yourself with the PTGBot documentation[4] as well. If you have any questions, please reach out to ptg(a)openinfra.dev! Information about signing up for time slots will be sent to moderators after the team signup deadline. Continue to visit openinfra.org/ptg for updates. -Kendall (diablo_rojo) [1] PTG Site: https://openinfra.org/ptg/ [2] Team Survey: https://openinfrafoundation.formstack.com/forms/ptg_april_2025_survey [3] Setup IRC: https://docs.openstack.org/contributors/common/irc.html [4] PTGBot README: https://opendev.org/openstack/ptgbot/src/branch/master/README.rst

1 0

[neutron] Drivers meeting canceled Friday, January 24th
by Brian Haley 23 Jan '25

23 Jan '25

Hello Neutrinos: I'm going to cancel tomorrow's drivers meeting as there is no agenda. Just a reminder there are still open specs that need review, list is at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[cinder] 2025.1 Midcycle reminder
by Jon Bernard 23 Jan '25

23 Jan '25

Hello all, this is a reminder that our midcycle meeting will take the place of next week's upstream meeting on 29 Jan. I've allocated 2 hours (as opposed to our usual 1) in case additional time is needed. The etherpad we'll be using is here [1]. See you all then! [1]: https://etherpad.opendev.org/p/cinder-epoxy-midcycles -- Jon

1 0

[Neutron][operators] LinuxBridge to OVN Outreach
by Daniel Failing 23 Jan '25

23 Jan '25

Dear operators of Neutron deployments using LinuxBridge, This mail is to target operators who plan to move away from neutron LinuxBridge as well. In our setup we are currently planing to move away from LinuxBridge and use OVN instead. Based on the last PTGs survey with quite a few deployments using LinuxBridge and it being marked experimental for some time, we feel there could be a common ground and pain points. We were wondering how many other operators have the same problems and want to share knowledge and if necessary consolidate code written for a potential migration. Knowing there are quite some different deployments, we most likely will not be able to find the golden solution that works for everyone, but we could strive for not making the same mistakes multiple times in different deployments. We are located in European timezones, if there are others interested in a zoom/jitsi call, please let me know your timezones/time preferences, so we find a good slot. Otherwise I can propose one of the following dates already: Friday, Jan 24st 2 or 3pm UTC Tuesday, Jan 28st 10am UTC Tuesday, Jan 28st 3:30pm UTC Wednesday, Jan 29st 10am UTC Friday, Jan 31st 2 or 3pm UTC Best, Daniel CERN Cloud Infrastructure [1] original thread: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

3 3

[openstack-ansible]:Wallaby to Xena Upgrade
by Rambo Rambo 23 Jan '25

23 Jan '25

Hi Team I am planning openstack-ansible wallaby to Xena upgrade. Distribution: openstack-ansible Release: Wallaby (current) ==> Xena (Planned) I was checking the release notes of Xena and could see that there is introduction of SSL in several services with nova for live migrations one of them. https://docs.openstack.org/releasenotes/openstack-ansible/xena.html As per the release notes: - Nova now defaults to to using the “QEMU-native TLS” feature for live migrations, rather than the deprecated SSH method. A pre-existing PKI (Public Key Infrastructure) setup is required. QEMU-native TLS requires all compute hosts to accept TCP connections on port 16514 and port range 49152 to 49261. More information can be found here: https://docs.openstack.org/nova/latest/admin/secure-live-migration-with-qem… Can you please confirm what steps are required to setup this PKI before doing the upgrade or it will be taken care by internal-pki using openstack-ansible upgrade method? Is there any option to skip this QEMU-native TLS for live-migrations and keep the orginal ssh based live-migrations? Regards

2 5