- openstack-discuss - lists.openstack.org

[all][outreachy] ☕ Looking for at least two volunteers for a virtual coffee chat
by Sofia Enriquez 25 Jul '23

25 Jul '23

Hello, We're currently seeking two volunteers to engage in casual chats with our Outreachy interns, @Desire Barine <desirebarine16(a)gmail.com> and @toheeb.olawale.to23@gmail.com <toheeb.olawale.to23(a)gmail.com> Asking to network with someone can be intimidating. An informal chat, on the other hand, is a friendly conversation with another person about their career or role as a free software contributor. This provides valuable insight for the intern, allowing them to learn about a professional's work, career journey, and networking experiences within the free software community. After the chat, the intern can request three additional people to speak with, thus expanding their network! Here's how to conduct an informal chat: - The intern will ask you questions about your career. - The chat can take place through a half-hour gmeet session (without video) or via IRC chat. - You can share tips on maximizing networking opportunities and offer advice to those interested in exploring career prospects in open source. If you are interested in participating, please contact @Rajat Dhasmana <rdhasman(a)redhat.com> with the date and time you are available! 📖 The interns journey with Openstack has been featured on the Superuser blog: - Getting an Outreachy Internship with OpenStack <https://superuser.openinfra.dev/articles/getting-an-outreachy-internship-wi…> - What is OpenStack? A Fresh Look from a Clear Mind <https://superuser.openinfra.dev/articles/what-is-openstack-a-fresh-look-fro…> Thank you for your consideration! -- 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

Info Public Cloud SIG for openstack-discuss
by Felix Kronlage-Dammers 25 Jul '23

25 Jul '23

Hi, in the Public Cloud SIG we discussed on how to get more OpenStack Public Cloud Operators back into the Public Cloud SIG and concluded that we’ll have a lightning talk once per month as part of our Public Cloud SIG meeting. This means that once a month we will exchange the IRC-session for a videocall session (in the same timeslot). To make it easy for everyone we will paste the link at the time of the meeting onto #openstack-operators as well as it being included in the reminder mail sent to openstack-discuss@ beforehand. We will be starting with that after the current vacation period in September. We’ll be reaching out to the OpenInfra community as well as the various OpenStack based public clouds out there to get people involved :) Due to vacation the irc meeting on August 2nd (next week) will not be happening, since both Tobias and me are on vacation. felix (in the name of Tobias and myself ;) -- Felix Kronlage-Dammers Product Owner IaaS & Operations Sovereign Cloud Stack Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

[openstack][nova] Resize nova instance with PCI devices to a flavor without PCI Devices
by Ha Noi 24 Jul '23

24 Jul '23

Hello everyone, I would like to resize an instance with PCI devices (GPU Passthrough) to a flavor without PCI Devices, but nova-api return no valid host. Response: No valid host was found. No valid host found for resize (HTTP 400) (Request-ID: req-9d6cf3f9-8f6f-482f-b0b1-95ec286a0fc3) I checked nova-scheduler log: Filtering removed all hosts for the request with instance ID 'e7b607ef-6be5-4bbc-9849-e31d622ecdfe'. Filter results: ['AggregateInstanceExtraSpecsFilter: (start: 85, end: 44)', 'RetryFilter: (start: 44, end: 44)', 'AvailabilityZoneFilter: (start: 44, end: 29)', 'ComputeFilter: (start: 29, end: 29)', 'ImagePropertiesFilter: (start: 29, end: 29)', 'ServerGroupAntiAffinityFilter: (start: 29, end: 29)', 'ServerGroupAffinityFilter: (start: 29, end: 29)', 'PciPassthroughFilter: (start: 29, end: 0)'] Actually, new flavor is not contain PCI specs, But It cannot pass PCI Filter. Thanks & Regards

1 0

Nova Ussuri: DB online migration cannot migrate (some) populate_user_id
by Michel Jouvin 24 Jul '23

24 Jul '23

Hi, We upgraded one of our clouds to Ussuri (we are late!) a couple of months ago. After the upgrade 'nova-manage db online_data_migration' was run. fill_virtual_interface_list and populate_user_id where non zero and after running the command fill_virtual_interface_list was 0 but populate_user_id stayed 24. Looking in nova-manage.log, I found the follwoing message (twice every time the command is run): Some instance mappings were not migratable. This may be transient due to in-flight instance builds, or could be due to stale data that will be cleaned up after running "nova-manage db archive_deleted_rows --purge". I ran the suggest command but the result is that fill_virtual_interface_list is non zero again (15) and there is no change to populate_user_i. If I run again online_data_migration, it clears again fill_virtual_interface_list... and so on. After 2 months the situation remains the same, no increase in populate_user_id but no possibility to fix them. We were wondering if it could have been caused by the fact that we had not yet upgraded all the compute nodes when we first ran the online_data_migration. We are planning to upgrade to Victoria and we'd like to fix the situation before as we understand that online data migration not done can be blocking for the next upgrade. We don't have any clue on the reason this happened. It is a test cloud with a very low usage. On our production cloud we have a somewhat similar problem but populate_user_id=1 and running the purge doesn't increase fill_virtual_interface_list. Thanks in advance for any hint! Best regards, Michel

2 1

Re: [openstack][largescale-sig] Openstack multi region deployment
by Nguyễn Hữu Khôi 24 Jul '23

24 Jul '23

Thanks for your explanation., Very details. This time, I have not much knowledge, But I will keep build and sharing with people as the same way you help me.

1 0

[openstack][largescale-sig] Openstack multi region deployment
by Karl Kloppenborg 24 Jul '23

24 Jul '23

Hi Nguy, We’ve deployed a large multi-region openstack deployment. As a rule of thumb we’ve got a “keystone” region which is as best we can highly available and very redundant. We then have all other regions talk back to this region, we just usually call it “keystone” or “core” and it’s hidden from the UI from users. We then just run a large well kept Galara cluster to support it. --Karl. From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Date: Tuesday, 18 July 2023 at 9:25 pm To: openstack-discuss(a)lists.openstack.org <openstack-discuss(a)lists.openstack.org> Subject: openstack-discuss Digest, Vol 57, Issue 55 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. [openstack][largescale-sig] Openstack multi region deployment (Nguy?n H?u Kh?i) 2. Re: [openstack][largescale-sig] Openstack multi region deployment (Felix Huettner) 3. Re: [openstack][largescale-sig] Openstack multi region deployment (Nguy?n H?u Kh?i) 4. Re: [neutron] unmanaged router resources - OVN interconnect (Rodolfo Alonso Hernandez) ---------------------------------------------------------------------- Message: 1 Date: Tue, 18 Jul 2023 12:07:12 +0700 From: Nguy?n H?u Kh?i <nguyenhuukhoinw(a)gmail.com> To: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Subject: [openstack][largescale-sig] Openstack multi region deployment Message-ID: <CABAODReJ6QW8A4OENEjmhFCiM-15B0qc2La_aMr1EKfaENq9iw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hello guys, I am going to deploy openstack multi regions and I know that keystone replication is the most challenging. I plan to set up 2 regions which use centralize galera cluster(3 nodes). and one standby edge galera cluster(3 nodes) When region 1 is node available, I will map region 2 to use standby edge galera cluster. I hope you give me some experience and advice with multi regions. Thank you very much.

3 6

[tc] Technical Committee next weekly meeting today on July 25, 2023
by Nikolla, Kristi 24 Jul '23

24 Jul '23

Hi all, This is a reminder that the next weekly Technical Committee meeting is to be held on Tuesday, July 25, 2023 at 1800 UTC on #openstack-tc on OFTC IRC. Please find below the agenda for the meeting • Roll call • Follow up on past action items • knikolla will amend proposal for Unmaintained branches. • tc-members to review https://review.opendev.org/c/openstack/project-team-guide/+/843457 • Extended Maintenance • https://etherpad.opendev.org/p/openstack-unmaintained-workflow • https://etherpad.opendev.org/p/openstack-exteneded-maintenance • Release notes guidelines for SLURP/NON-SLURP cadence • Gate health check • Open Discussion and Reviews • https://review.opendev.org/q/projects:openstack/governance+is:open Thank you, Kristi Nikolla

1 0

Take the OpenStack User Survey!
by Helena Spease 24 Jul '23

24 Jul '23

Hello everyone, It’s User Survey season! The 2023 OpenStack User Survey is closing August 23, 2023. That’s just under a month to submit your anonymized feedback to the upstream contributors. https://www.openstack.org/user-survey/survey-2023/landing <https://www.openstack.org/user-survey/survey-2023/landing> We have posts from the OpenInfra Foundation social media channels that you can re-share to your networks to encourage them to participate in the User Survey as well. Mastodon: https://social.openinfra.dev/@OpenStack/110768926571772510 <https://social.openinfra.dev/@OpenStack/110768926571772510> Twitter: https://twitter.com/OpenStack/status/1683441577648181248 <https://twitter.com/OpenStack/status/1683441577648181248> LinkedIn: https://www.linkedin.com/posts/openstack_take-the-2023-openstack-user-surve… <https://www.linkedin.com/posts/openstack_take-the-2023-openstack-user-surve…> Evaluating another OpenInfra project? We have User Surveys for them as well! Kata Containers: https://openinfrafoundation.formstack.com/forms/kata_containers_user_survey <https://openinfrafoundation.formstack.com/forms/kata_containers_user_survey> OpenStack: https://www.openstack.org/user-survey/survey-2023/landing <https://www.openstack.org/user-survey/survey-2023/landing> StarlingX: https://openinfrafoundation.formstack.com/forms/starlingx_user_survey <https://openinfrafoundation.formstack.com/forms/starlingx_user_survey> Zuul: https://openinfrafoundation.formstack.com/forms/zuul_user_survey <https://openinfrafoundation.formstack.com/forms/zuul_user_survey> We really appreciate your participation in the User Survey and are really excited to share with you all the cool data we collect! Cheers, Helena helena(a)openinfra.dev <mailto:helena@openinfra.dev> Marketing & Community Coordinator The OpenInfra Foundation

1 0

[zun] container run database insert error
by Jaime Ibar 24 Jul '23

24 Jul '23

Hi all, I have installed and configured zun for container support, all went good and I can list the available services with > openstack appcontainer service list however when I try to launch a container with > openstack appcontainer run --name container --net network=$NET_ID cirros ping 8.8.8.8 as stated in the documentation, I get the following error in zun-api oslo_db.exception.DBReferenceError: (pymysql.err.IntegrityError) (1452, 'Cannot add or update a child row: a foreign key constraint fails (`zun`.`container_actions`, CONSTRAINT `container_actions_ibfk_1` FOREIGN KEY (`container_uuid`) REFERENCES `container` (`uuid`))') I have followed this installation guide for yoga release(the one I'm running at the moment) https://docs.openstack.org/zun/yoga/install/index.html. Did anyone see this error before? TIA -- Jaime

1 0

Ussuri: how to delete lbaas loadbalancer left over?
by Michel Jouvin 24 Jul '23

24 Jul '23

Hi, We had a few Magnum (K8s) clusters created a couple of years ago (with Rocky and Stein versions) and forgotten. We started to delete them this spring when we where running Train Neutron service. Basically we managed to do this with the following sequence: - openstack coe cluster delete xxx and waiting for DELETE_FAILED - Use openstack coe cluster show / openstack stack resource list -n2 to identify the neutron entry causing the error and pick the corresponding resource ID - Find the ports associated with the router with openstack port list --router previously_found_id - Use the port subnet to find the port corresponding lbaas load balancer ID, use the neutron CLI to delete the load balancer (deleting one by one all the dependencies preventing the load balancer removal) - Rerun openstack coe cluster delete For some reasons, we didn't cleanup all the abandoned clusters and upgraded Neutron to Ussuri. Unfortunately, since then our previous process is no longer working as it seems that the Neutron server doesn't know anymore anything about the LBAAS load balancers (and "neutron lbaas-loadbalancer list" returns nothing). In the neutron server, any attempt to delete the subnet attached to the load balancer (or to list them with Neutron CLI) results in the following errors in Neutron server.log : ------ 2023-07-07 16:27:31.139 14962 WARNING neutron.pecan_wsgi.controllers.root [req-71e712fc-d8a7-4815-90b3-b406c10e0caa a2b4a88cfee0c18702fe89ccb07ae875de3f34f3f1bb43e505fd83aebcfc094c 245bc968c1b7465dac1b93a30bf67ba9 - 1367c9a4d5da4b229c35789c271dc7aa 1367c9a4d5da4b229c35789c271dc7aa] No controller found for: lbaas - returning response code 404: pecan.routing.PecanNotFound 2023-07-07 16:27:31.140 14962 INFO neutron.pecan_wsgi.hooks.translation [req-71e712fc-d8a7-4815-90b3-b406c10e0caa a2b4a88cfee0c18702fe89ccb07ae875de3f34f3f1bb43e505fd83aebcfc094c 245bc968c1b7465dac1b93a30bf67ba9 - 1367c9a4d5da4b229c35789c271dc7aa 1367c9a4d5da4b229c35789c271dc7aa] GET failed (client error): The resource could not be found. 2023-07-07 16:27:31.141 14962 INFO neutron.wsgi [req-71e712fc-d8a7-4815-90b3-b406c10e0caa a2b4a88cfee0c18702fe89ccb07ae875de3f34f3f1bb43e505fd83aebcfc094c 245bc968c1b7465dac1b93a30bf67ba9 - 1367c9a4d5da4b229c35789c271dc7aa 1367c9a4d5da4b229c35789c271dc7aa] 157.136.249.153 "GET /v2.0/lbaas/loadbalancers?name=kube_service_964f7e76-d2d5-4126-ab11-cd689f6dd9f9_runnerdeploy-wm9sm-5h52l_hello-node-x-default-x-runnerdeploy-wm9sm-5h52l HTTP/1.1" status: 404 len: 304 time: 0.0052643 ------ Any suggestion to workaround this problem and be able to successfully delete our old Magnum clusters? Thanks in advance for any help. Best regards, Michel

2 8

vPTG October 2023 Team Signup Kickoff
by Kendall Nelson 23 Jul '23

23 Jul '23

Hi Everyone, Hopefully, you have seen by now that the next OpenInfra vPTG[1] which will take place October 23-27, 2023 virtually and registration is open[2]! *To sign up your team, you must complete the survey[3] by August 20th at 7:00 UTC.* We NEED accurate contact information (email 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 sign ups which will be done via the PTGBot. If you are not on IRC, please get setup[4] on the OFTC network and join #openinfra-events. You are also encouraged to familiarize yourself with the PTGBot documentation[5] as well. If you have any questions, please reach out! Information about signing up for time will be sent to moderators late August after the interest survey deadline on August 20. -Kendall (diablo_rojo) [1] PTG Site: https://openinfra.dev/ptg/ [2] PTG Registration: http://ptg2023.openinfra.dev/ [3] Team Survey: https://openinfrafoundation.formstack.com/forms/oct2023_ptg_team_signup [4] Setup IRC: https://docs.openstack.org/contributors/common/irc.html [5] PTGBot README: https://opendev.org/openstack/ptgbot/src/branch/master/README.rst

1 0

[openstack-ansible][wallaby deployment getting failed] error:- Service user token configuration is required for all Nova
by Danish Khan 22 Jul '23

22 Jul '23

Dear Team, I am trying to deploy openstack-ansible wallaby but it is getting failed with error: service user token configuration is required for all Nova services. For more details see the following: https://docs.openstack.org/latest/nova/admin/configuration/service-user-tok… But the mentioned webpage is not available. This is fixed in yoga but wallay is still failing. I tried to copy few variables from Yoga but that is working for me. Can someone please help me on this ? where I need to make some changes to deploy openstack-ansible wallaby? Thanks in advance :) Regards, Danish

2 1

Re: [all] [oslo.messaging] Interest in collaboration on a NATS driver
by Tobias Urdin 22 Jul '23

22 Jul '23

Hello Kai, Great to hear that you’re interested! I’m currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first). Best regards Tobias > On 30 Aug 2022, at 18:32, Kai Bojens <kb(a)kbojens.de> wrote: > > Am 29.08.22 um 15:46 schrieb Tobias Urdin: > >> If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to >> reach out. I’m hoping somebody will bite but atleast I’ve put it out there for all of you. > > Hi, > I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack. > > As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ. > > This brings me to the most important question: Where do you run and test your code? > > Greetings, > Kai

8 30

Superuser / OpenInfra Live Opportunities?
by Kristin Barrientos 21 Jul '23

21 Jul '23

Hi Everyone, OpenInfra Live is looking for ideas and participants to join a panel to discuss those topics. That being said… do you have a topic in mind that you would like to see on OpenInfra Live? We want to hear from you! Some ideas can include: Data Sovereignty Multi-Region Deployment Kolla-Ansible AI/ML And many more! If you would like to participate or have an idea, you can contact me via email (kristin(a)openinfra.dev) or reply here, and we can work on getting something started. If you would rather write a Superuser article, feel free to email me an abstract and we can go from there. I look forward to hearing everyone’s ideas! Thanks, Kristin Barrientos Marketing Coordinator OpenInfra Foundation

2 1

[neutron] Next Neutron meetings schedule
by Rodolfo Alonso Hernandez 21 Jul '23

21 Jul '23

Hello Neutrinos: Today we have the Neutron drivers meeting at 1400UTC. This is the agenda: https://wiki.openstack.org/wiki/Meetings/NeutronDrivers. We have one topic: https://bugs.launchpad.net/neutron/+bug/2027742. Next Tuesday we have cancelled the Neutron team meeting (I'll be on PTO). But remember that the Neutron CI meeting will take place at 1500UTC. Regards.

1 0

[OSA][NEUTRON] Failed to bind port XXX on host YYY for vnic_type normal using segments...
by Murilo Morais 20 Jul '23

20 Jul '23

Hey guys. I'm having problems with a new deploy. I'm relatively new to the project, so I still don't know how to guide myself in solving some errors. When I create some Network and try to upload a VM the following errors appear in the Neutron container: ############################### Jul 15 11:31:50 dcn2-neutron-server-container-a7122a16 neutron-api[5676]: 2023-07-15 11:31:50.988 5676 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection Jul 15 11:31:51 dcn2-neutron-server-container-a7122a16 neutron-api[5683]: 2023-07-15 11:31:51.009 5683 ERROR oslo.messaging._drivers.impl_rabbit [-] Connection failed: [Errno 104] ECONNRESET (retrying in 1.0 seconds): ConnectionResetError: [Errno 104] ECONNRESET Jul 15 11:31:51 dcn2-neutron-server-container-a7122a16 uwsgi[5683]: Sat Jul 15 11:31:51 2023 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /v2.0/availability_zones (ip 172.29.237.22) !!! Jul 15 11:33:53 dcn2-neutron-server-container-a7122a16 neutron-api[5676]: 2023-07-15 11:33:53.860 5676 ERROR oslo.messaging._drivers.impl_rabbit [-] Connection failed: [Errno 104] ECONNRESET (retrying in 1.0 seconds): ConnectionResetError: [Errno 104] ECONNRESET Jul 15 11:33:58 dcn2-neutron-server-container-a7122a16 neutron-api[5678]: 2023-07-15 11:33:58.733 5678 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: [Errno 104] Connection reset by peer Jul 15 11:33:58 dcn2-neutron-server-container-a7122a16 uwsgi[5678]: Sat Jul 15 11:33:58 2023 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /v2.0/subnetpools (ip 172.29.237.22) !!! Jul 15 11:33:58 dcn2-neutron-server-container-a7122a16 neutron-api[5677]: 2023-07-15 11:33:58.959 5677 INFO neutron.db.segments_db [None req-61542ff4-867d-402f-8239-b45392b2c188 f8da6c7abaa64116948db1d2aaa829f1 86e3eede43b940d69d2b43ccba1b256b - - default default] Added segment 16ec3850-a4f2-40f3-9dc8-3b4650053935 of type vlan for network 6887bbfb-4680-4ed7-910b-90a65f7731dc Jul 15 11:33:59 dcn2-neutron-server-container-a7122a16 neutron-api[5680]: 2023-07-15 11:33:59.095 5680 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: [Errno 104] Connection reset by peer Jul 15 11:33:59 dcn2-neutron-server-container-a7122a16 uwsgi[5680]: Sat Jul 15 11:33:59 2023 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /v2.0/subnets (ip 172.29.237.22) !!! Jul 15 11:33:59 dcn2-neutron-server-container-a7122a16 neutron-api[5680]: 2023-07-15 11:33:59.584 5680 WARNING neutron.api.rpc.agentnotifiers.dhcp_rpc_agent_api [None req-5ad409c5-c073-4726-bb26-5024d9c9c65b f8da6c7abaa64116948db1d2aaa829f1 86e3eede43b940d69d2b43ccba1b256b - - default default] Unable to schedule network 6887bbfb-4680-4ed7-910b-90a65f7731dc: no agents available; will retry on subsequent port and subnet creation events. Jul 15 11:33:59 dcn2-neutron-server-container-a7122a16 neutron-api[5688]: 2023-07-15 11:33:59.684 5688 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection Jul 15 11:41:32 dcn2-neutron-server-container-a7122a16 neutron-api[5680]: 2023-07-15 11:41:32.961 5680 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: Traceback (most recent call last): Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/urllib3/connection.py", line 174, in _new_conn Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: conn = connection.create_connection( Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/urllib3/util/connection.py", line 95, in create_connection Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: raise err Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/urllib3/util/connection.py", line 85, in create_connection Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: sock.connect(sa) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/eventlet/greenio/base.py", line 256, in connect Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: socket_checkerr(fd) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/eventlet/greenio/base.py", line 54, in socket_checkerr Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: raise socket.error(err, errno.errorcode[err]) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: BrokenPipeError: [Errno 32] EPIPE Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: During handling of the above exception, another exception occurred: Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: Traceback (most recent call last): Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/urllib3/connectionpool.py", line 703, in urlopen Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: httplib_response = self._make_request( Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/urllib3/connectionpool.py", line 398, in _make_request Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: conn.request(method, url, **httplib_request_kw) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/urllib3/connection.py", line 239, in request Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: super(HTTPConnection, self).request(method, url, body=body, headers=headers) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/usr/lib/python3.9/http/client.py", line 1255, in request Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: self._send_request(method, url, body, headers, encode_chunked) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/usr/lib/python3.9/http/client.py", line 1301, in _send_request Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: self.endheaders(body, encode_chunked=encode_chunked) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/usr/lib/python3.9/http/client.py", line 1250, in endheaders Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: self._send_output(message_body, encode_chunked=encode_chunked) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/usr/lib/python3.9/http/client.py", line 1010, in _send_output Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: self.send(msg) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/usr/lib/python3.9/http/client.py", line 950, in send Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: self.connect() Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/urllib3/connection.py", line 205, in connect Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: conn = self._new_conn() Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/urllib3/connection.py", line 186, in _new_conn Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: raise NewConnectionError( Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPConnection object at 0x7efd5f36ca30>: Failed to establish a new connection: [Errno 32] EPIPE Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: During handling of the above exception, another exception occurred: Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: Traceback (most recent call last): Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/requests/adapters.py", line 489, in send Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: resp = conn.urlopen( Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/urllib3/connectionpool.py", line 787, in urlopen Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: retries = retries.increment( Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/urllib3/util/retry.py", line 592, in increment Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: raise MaxRetryError(_pool, url, error or ResponseError(cause)) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='172.29.236.2', port=8780): Max retries exceeded with url: /resource_providers/dd7e74fb-b494-448e-b16a-712a7ad60e6c/aggregates (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7efd5f36ca30>: Failed to establish a new connection: [Errno 32] EPIPE')) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: During handling of the above exception, another exception occurred: Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: Traceback (most recent call last): Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/keystoneauth1/session.py", line 1022, in _send_request Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: resp = self.session.request(method, url, **kwargs) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/requests/sessions.py", line 587, in request Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: resp = self.send(prep, **send_kwargs) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/requests/sessions.py", line 701, in send Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: r = adapter.send(request, **kwargs) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/requests/adapters.py", line 565, in send Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: raise ConnectionError(e, request=request) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: requests.exceptions.ConnectionError: HTTPConnectionPool(host='172.29.236.2', port=8780): Max retries exceeded with url: /resource_providers/dd7e74fb-b494-448e-b16a-712a7ad60e6c/aggregates (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7efd5f36ca30>: Failed to establish a new connection: [Errno 32] EPIPE')) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: During handling of the above exception, another exception occurred: Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: Traceback (most recent call last): Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/eventlet/hubs/poll.py", line 111, in wait Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: listener.cb(fileno) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/neutron/common/utils.py", line 924, in wrapper Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: return func(*args, **kwargs) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/neutron/notifiers/batch_notifier.py", line 58, in synced_send Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: self._notify() Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/neutron/notifiers/batch_notifier.py", line 69, in _notify Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: self.callback(batched_events) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/neutron/services/segments/plugin.py", line 211, in _send_notifications Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: event.method(event) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/neutron/services/segments/plugin.py", line 383, in _delete_nova_inventory Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: aggregate_id = self._get_aggregate_id(event.segment_id) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/neutron/services/segments/plugin.py", line 370, in _get_aggregate_id Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: aggregate_uuid = self.p_client.list_aggregates( Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/neutron_lib/placement/client.py", line 58, in wrapper Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: return f(self, *a, **k) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/neutron_lib/placement/client.py", line 554, in list_aggregates Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: return self._get(url).json() Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/neutron_lib/placement/client.py", line 190, in _get Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: return self._client.get(url, endpoint_filter=self._ks_filter, Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/keystoneauth1/session.py", line 1141, in get Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: return self.request(url, 'GET', **kwargs) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/keystoneauth1/session.py", line 931, in request Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: resp = send(**kwargs) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: File "/openstack/venvs/neutron-26.1.3.dev1/lib/python3.9/site-packages/keystoneauth1/session.py", line 1038, in _send_request Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: raise exceptions.ConnectFailure(msg) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 neutron-api[5688]: 2023-07-15 11:41:33.144 5688 ERROR oslo.messaging._drivers.impl_rabbit [-] Connection failed: [Errno 104] ECONNRESET (retrying in 1.0 seconds): ConnectionResetError: [Errno 104] ECONNRESET Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: keystoneauth1.exceptions.connection.ConnectFailure: Unable to establish connection to http://172.29.236.2:8780/resource_providers/dd7e74fb-b494-448e-b16a-712a7ad…: HTTPConnectionPool(host='172.29.236.2', port=8780): Max retries exceeded with url: /resource_providers/dd7e74fb-b494-448e-b16a-712a7ad60e6c/aggregates (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7efd5f36ca30>: Failed to establish a new connection: [Errno 32] EPIPE')) Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 uwsgi[5688]: Removing descriptor: 13 Jul 15 11:41:33 dcn2-neutron-server-container-a7122a16 neutron-api[5689]: 2023-07-15 11:41:33.542 5689 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection Jul 15 11:42:36 dcn2-neutron-server-container-a7122a16 neutron-api[5678]: 2023-07-15 11:42:36.571 5678 ERROR oslo.messaging._drivers.impl_rabbit [-] Connection failed: [Errno 104] Connection reset by peer (retrying in 1.0 seconds): ConnectionResetError: [Errno 104] Connection reset by peer Jul 15 11:42:40 dcn2-neutron-server-container-a7122a16 neutron-api[5689]: 2023-07-15 11:42:40.942 5689 ERROR oslo.messaging._drivers.impl_rabbit [-] Connection failed: [Errno 104] Connection reset by peer (retrying in 1.0 seconds): ConnectionResetError: [Errno 104] Connection reset by peer Jul 15 11:42:41 dcn2-neutron-server-container-a7122a16 uwsgi[5683]: Sat Jul 15 11:42:41 2023 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /v2.0/subnets (ip 172.29.237.22) !!! Jul 15 11:42:42 dcn2-neutron-server-container-a7122a16 neutron-api[5688]: 2023-07-15 11:42:42.053 5688 ERROR oslo.messaging._drivers.impl_rabbit [-] Connection failed: [Errno 104] Connection reset by peer (retrying in 3.0 seconds): ConnectionResetError: [Errno 104] Connection reset by peer Jul 15 11:42:45 dcn2-neutron-server-container-a7122a16 neutron-api[5688]: 2023-07-15 11:42:45.240 5688 WARNING neutron.api.rpc.agentnotifiers.dhcp_rpc_agent_api [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-0270e149-44c9-49c4-af20-47918e00c4ea f8da6c7abaa64116948db1d2aaa829f1 86e3eede43b940d69d2b43ccba1b256b - - default default] Unable to schedule network 6887bbfb-4680-4ed7-910b-90a65f7731dc: no agents available; will retry on subsequent port and subnet creation events. Jul 15 11:42:46 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:46.563 5682 ERROR neutron.plugins.ml2.managers [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Failed to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 on host dcn2 for vnic_type normal using segments [{'id': '16ec3850-a4f2-40f3-9dc8-3b4650053935', 'network_type': 'vlan', 'physical_network': 'vlan', 'segmentation_id': 138, 'network_id': '6887bbfb-4680-4ed7-910b-90a65f7731dc'}] Jul 15 11:42:46 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:46.564 5682 INFO neutron.plugins.ml2.plugin [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Attempt 2 to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 Jul 15 11:42:46 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:46.641 5682 ERROR neutron.plugins.ml2.managers [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Failed to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 on host dcn2 for vnic_type normal using segments [{'id': '16ec3850-a4f2-40f3-9dc8-3b4650053935', 'network_type': 'vlan', 'physical_network': 'vlan', 'segmentation_id': 138, 'network_id': '6887bbfb-4680-4ed7-910b-90a65f7731dc'}] Jul 15 11:42:46 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:46.641 5682 INFO neutron.plugins.ml2.plugin [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Attempt 3 to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 Jul 15 11:42:46 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:46.695 5682 ERROR neutron.plugins.ml2.managers [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Failed to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 on host dcn2 for vnic_type normal using segments [{'id': '16ec3850-a4f2-40f3-9dc8-3b4650053935', 'network_type': 'vlan', 'physical_network': 'vlan', 'segmentation_id': 138, 'network_id': '6887bbfb-4680-4ed7-910b-90a65f7731dc'}] Jul 15 11:42:46 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:46.695 5682 INFO neutron.plugins.ml2.plugin [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Attempt 4 to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 Jul 15 11:42:46 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:46.743 5682 ERROR neutron.plugins.ml2.managers [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Failed to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 on host dcn2 for vnic_type normal using segments [{'id': '16ec3850-a4f2-40f3-9dc8-3b4650053935', 'network_type': 'vlan', 'physical_network': 'vlan', 'segmentation_id': 138, 'network_id': '6887bbfb-4680-4ed7-910b-90a65f7731dc'}] Jul 15 11:42:46 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:46.743 5682 INFO neutron.plugins.ml2.plugin [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Attempt 5 to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 Jul 15 11:42:46 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:46.798 5682 ERROR neutron.plugins.ml2.managers [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Failed to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 on host dcn2 for vnic_type normal using segments [{'id': '16ec3850-a4f2-40f3-9dc8-3b4650053935', 'network_type': 'vlan', 'physical_network': 'vlan', 'segmentation_id': 138, 'network_id': '6887bbfb-4680-4ed7-910b-90a65f7731dc'}] Jul 15 11:42:46 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:46.799 5682 INFO neutron.plugins.ml2.plugin [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Attempt 6 to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 Jul 15 11:42:46 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:46.856 5682 ERROR neutron.plugins.ml2.managers [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Failed to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 on host dcn2 for vnic_type normal using segments [{'id': '16ec3850-a4f2-40f3-9dc8-3b4650053935', 'network_type': 'vlan', 'physical_network': 'vlan', 'segmentation_id': 138, 'network_id': '6887bbfb-4680-4ed7-910b-90a65f7731dc'}] Jul 15 11:42:46 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:46.856 5682 INFO neutron.plugins.ml2.plugin [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Attempt 7 to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 Jul 15 11:42:46 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:46.904 5682 ERROR neutron.plugins.ml2.managers [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Failed to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 on host dcn2 for vnic_type normal using segments [{'id': '16ec3850-a4f2-40f3-9dc8-3b4650053935', 'network_type': 'vlan', 'physical_network': 'vlan', 'segmentation_id': 138, 'network_id': '6887bbfb-4680-4ed7-910b-90a65f7731dc'}] Jul 15 11:42:46 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:46.904 5682 INFO neutron.plugins.ml2.plugin [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Attempt 8 to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 Jul 15 11:42:46 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:46.952 5682 ERROR neutron.plugins.ml2.managers [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Failed to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 on host dcn2 for vnic_type normal using segments [{'id': '16ec3850-a4f2-40f3-9dc8-3b4650053935', 'network_type': 'vlan', 'physical_network': 'vlan', 'segmentation_id': 138, 'network_id': '6887bbfb-4680-4ed7-910b-90a65f7731dc'}] Jul 15 11:42:46 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:46.952 5682 INFO neutron.plugins.ml2.plugin [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Attempt 9 to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 Jul 15 11:42:47 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:47.000 5682 ERROR neutron.plugins.ml2.managers [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Failed to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 on host dcn2 for vnic_type normal using segments [{'id': '16ec3850-a4f2-40f3-9dc8-3b4650053935', 'network_type': 'vlan', 'physical_network': 'vlan', 'segmentation_id': 138, 'network_id': '6887bbfb-4680-4ed7-910b-90a65f7731dc'}] Jul 15 11:42:47 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:47.001 5682 INFO neutron.plugins.ml2.plugin [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Attempt 10 to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 Jul 15 11:42:47 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:42:47.056 5682 ERROR neutron.plugins.ml2.managers [req-1ded0181-a9ab-446b-b599-e8fbe86ca555 req-80894c6f-8ef3-4df7-86d1-535e20ebc2d2 33ba7b2cad184ddcacff6c1b5017a648 8ee53dea918a4570b4898dc10f542c5c - - default default] Failed to bind port caa01668-d5c0-4b37-a185-0ebc458326f7 on host dcn2 for vnic_type normal using segments [{'id': '16ec3850-a4f2-40f3-9dc8-3b4650053935', 'network_type': 'vlan', 'physical_network': 'vlan', 'segmentation_id': 138, 'network_id': '6887bbfb-4680-4ed7-910b-90a65f7731dc'}] Jul 15 11:42:54 dcn2-neutron-server-container-a7122a16 neutron-api[5676]: 2023-07-15 11:42:54.511 5676 INFO neutron.notifiers.nova [-] Nova event matching ['req-0ffbf4aa-051f-4707-afe7-2908726310c5'] response: {'server_uuid': '9f206d9f-6c96-479f-bbaa-116d967129dc', 'name': 'network-vif-deleted', 'tag': 'caa01668-d5c0-4b37-a185-0ebc458326f7', 'status': 'completed', 'code': 200} Jul 15 11:48:24 dcn2-neutron-server-container-a7122a16 neutron-api[5678]: 2023-07-15 11:48:24.062 5678 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection Jul 15 11:48:31 dcn2-neutron-server-container-a7122a16 neutron-api[5676]: 2023-07-15 11:48:31.762 5676 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection Jul 15 11:48:31 dcn2-neutron-server-container-a7122a16 neutron-api[5677]: 2023-07-15 11:48:31.828 5677 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: [Errno 104] Connection reset by peer Jul 15 11:48:31 dcn2-neutron-server-container-a7122a16 uwsgi[5677]: Sat Jul 15 11:48:31 2023 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /v2.0/subnets (ip 172.29.237.22) !!! Jul 15 11:48:32 dcn2-neutron-server-container-a7122a16 neutron-api[5686]: 2023-07-15 11:48:32.108 5686 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: [Errno 104] Connection reset by peer Jul 15 11:48:32 dcn2-neutron-server-container-a7122a16 uwsgi[5686]: Sat Jul 15 11:48:32 2023 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /v2.0/networks?limit=21&sort_dir=asc&sort_key=id&router%3Aexternal=True&shared=False (ip 172.29.237.22) !!! Jul 15 11:48:34 dcn2-neutron-server-container-a7122a16 neutron-api[5689]: 2023-07-15 11:48:34.625 5689 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection Jul 15 11:48:34 dcn2-neutron-server-container-a7122a16 neutron-api[5688]: 2023-07-15 11:48:34.641 5688 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection Jul 15 11:48:35 dcn2-neutron-server-container-a7122a16 neutron-api[5682]: 2023-07-15 11:48:35.978 5682 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection Jul 15 11:48:36 dcn2-neutron-server-container-a7122a16 neutron-api[5683]: 2023-07-15 11:48:36.052 5683 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection Jul 15 11:48:36 dcn2-neutron-server-container-a7122a16 neutron-api[5680]: 2023-07-15 11:48:36.809 5680 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: [Errno 104] Connection reset by peer Jul 15 11:48:36 dcn2-neutron-server-container-a7122a16 uwsgi[5680]: Sat Jul 15 11:48:36 2023 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /v2.0/subnetpools (ip 172.29.237.22) !!! ############################### After the errors appear, the Horizon interface reports the following error: Error: Failed to perform requested operation on instance "test", the instance has an error status: Please try again later [Error: Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance 9f206d9f-6c96-479f-bbaa-116d967129dc.]. What could be happening? I believe I'm missing something to configure, but I don't know where to start.

2 6

[cinder] festival of feature reviews 21st July, 2023
by Rajat Dhasmana 20 Jul '23

20 Jul '23

Hello Argonauts, We will be having our monthly festival of reviews today i.e. 21st July (Friday) from 1400-1600 UTC. Following are some additional details: Date: 21st July, 2023 Time: 1400-1600 UTC Meeting link: will be shared in #openstack-cinder around 1400 UTC etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews Attached is the invite if you want to add it to your calendar. Thanks Rajat Dhasmana

1 0

Announcement: OpenStack "C" Release Name
by Kristin Barrientos 19 Jul '23

19 Jul '23

Hi Everyone, Happy 13th birthday to OpenStack! We're proud to announce that the name chosen for the “C” release is… Caracal! Thank you to everyone who voted. Kristin Barrientos Marketing Coordinator OpenInfra Foundation

1 0

[neutron] unmanaged router resources - OVN interconnect
by Roberto Bartzen Acosta 19 Jul '23

19 Jul '23

Hello Neutron folks, Regarding the conversation started in March [1] about the use of OVN interconnect with Neutron, I would like to evolve the discussion in relation to resources allocated by OVN-IC and which are not managed by Neutron. In the March PTG [2], the problem related to the db_sync tool was presented, and a proposed solution in which Neutron does not manage these resources. After discussing some architectural designs with Felix/StackIT, it seems to make sense to come up with a proposal to change the mech_driver to validate the external_ids key and not remove resources present in the OVN backend without Neutron "signature". The discussion here is more complex than it seems, because architecturally Neutron does not allow us to interconnect workloads in multiple AZs (with different OpenStacks), but this could be a requirement for a high availability cloud solution (Cloud Region). Additionally, this OVN-IC solution allows interconnecting other cloud backends that use OVN, in the case of kubernetes with ovn-kube. We tested an OVN interconnect integrated with 3 OpenStack installations and it worked very well !!! considering direct L3 traffic at the router level between different network infrastructures. SYNC_REPAIR - problem * Static Routes (learned OVN-IC routes) * Router Port -> Transit Switches Jul 10 18:34:11 os-infra-1-neutron-server-container-845157ae neutron-server[8632]: 2023-07-10 18:34:11.343 8632 WARNING neutron.plugins.ml2.drivers.ovn.mech_driver.ovsdb.ovn_db_sync [req-8d513732-f932-47b8-bc2c-937958c30f47 - - - - -] Router Port found in OVN but not in Neutron, port_id=rt2-admin-tenant1 Jul 10 18:34:11 os-infra-1-neutron-server-container-845157ae neutron-server[8632]: 2023-07-10 18:34:11.343 8632 WARNING neutron.plugins.ml2.drivers.ovn.mech_driver.ovsdb.ovn_db_sync [req-8d513732-f932-47b8-bc2c-937958c30f47 - - - - -] Router 9823d34b-bb2a-480c-b3f6-cf51fd19db52 static routes [{'destination': ' 10.0.0.1/24', 'nexthop': '169.254.100.1'}, {'destination': '10.0.2.1/24', 'nexthop': '169.254.100.3'}] found in OVN but not in Neutron Any suggestions on how to resolve this db_sync issue? since all other Neutron modules did not present any problem with OVN-IC (as far as I tested). I remember Terry was keen to suggest some things to help. I believe that before proposing some complex mechanism to solve this simple problem, I would like to hear the community opinion. In our use case, a bit change in db_sync with filter by neutron key in external_ids would be enough. Regards, Roberto [1] https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032624.h… [2] https://etherpad.opendev.org/p/neutron-bobcat-ptg Additional logs: OpenStack 1 root@os-infra-1-neutron-ovn-northd-container-f931b37c:~# root@os-infra-1-neutron-ovn-northd-container-f931b37c:~# root@os-infra-1-neutron-ovn-northd-container-f931b37c:~# ovn-nbctl lr-route-list 6b776115-746a-4c59-aa73-6674c70b3498 IPv4 Routes Route Table <main>: 20.0.1.0/24 169.254.200.2 dst-ip (learned) 20.0.2.0/24 169.254.200.3 dst-ip (learned) 0.0.0.0/0 200.200.200.1 dst-ip IPv6 Routes Route Table <main>: ::/0 fc00:ca5a:ca5a:8000:: dst-ip root@os-infra-1-neutron-ovn-northd-container-f931b37c:~# ovn-nbctl lr-route-list 23d4552a-62c4-40e1-8bae-d06af3489c07 IPv4 Routes Route Table <main>: 10.0.1.0/24 169.254.100.2 dst-ip (learned) 10.0.2.0/24 169.254.100.3 dst-ip (learned) 0.0.0.0/0 200.200.200.1 dst-ip IPv6 Routes Route Table <main>: ::/0 fc00:ca5a:ca5a:8000:: dst-ip root@os-infra-1-neutron-ovn-northd-container-f931b37c:~# OpenStack 2 root@os-infra-1-neutron-ovn-northd-container-30f7e935:~# ovn-nbctl lr-route-list dc1e5008-adb9-451e-8b71-09388f3680bc IPv4 Routes Route Table <main>: 20.0.0.0/24 169.254.200.1 dst-ip (learned) 20.0.2.0/24 169.254.200.3 dst-ip (learned) 0.0.0.0/0 200.200.200.1 dst-ip IPv6 Routes Route Table <main>: ::/0 fc00:ca5a:ca5a:8000:: dst-ip root@os-infra-1-neutron-ovn-northd-container-30f7e935:~# ovn-nbctl lr-route-list ce45f681-6454-43fe-974f-81344bb8113a IPv4 Routes Route Table <main>: 10.0.0.0/24 169.254.100.1 dst-ip (learned) 10.0.2.0/24 169.254.100.3 dst-ip (learned) 0.0.0.0/0 200.200.200.1 dst-ip IPv6 Routes Route Table <main>: ::/0 fc00:ca5a:ca5a:8000:: dst-ip OpenStack 3 root@os-infra-1-neutron-ovn-northd-container-f237db97:~# root@os-infra-1-neutron-ovn-northd-container-f237db97:~# ovn-nbctl lr-route-list cfa259d6-311f-4409-bcf2-79a929835cb3 IPv4 Routes Route Table <main>: 20.0.0.0/24 169.254.200.1 dst-ip (learned) 20.0.1.0/24 169.254.200.2 dst-ip (learned) 0.0.0.0/0 200.200.200.1 dst-ip IPv6 Routes Route Table <main>: ::/0 fc00:ca5a:ca5a:8000:: dst-ip root@os-infra-1-neutron-ovn-northd-container-f237db97:~# ovn-nbctl lr-route-list c5a4dcd8-b9a6-4397-a7cf-88bc1e01b0b0 IPv4 Routes Route Table <main>: 10.0.0.0/24 169.254.100.1 dst-ip (learned) 10.0.1.0/24 169.254.100.2 dst-ip (learned) 0.0.0.0/0 200.200.200.1 dst-ip IPv6 Routes Route Table <main>: ::/0 fc00:ca5a:ca5a:8000:: dst-ip OVN-IC Global database root@ovn-global-db1:~# ovn-ic-sbctl show availability-zone osp1 gateway 832b6c0d-13ce-4600-ab37-78516d8ec4c5 hostname: osp1-gwnode1 type: geneve ip: 192.168.200.28 port admin-rt1-tenant1 transit switch: admin-tenant1 address: ["aa:aa:aa:aa:bb:01 169.254.100.1/24 fe80::1/64"] port admin-rt1-tenant1_1 transit switch: admin-tenant1_1 address: ["aa:aa:aa:aa:dd:01 169.254.200.1/24"] availability-zone osp2 gateway 17ffabdf-cf47-41ab-9539-d326c13c4ca8 hostname: osp2-gwnode1 type: geneve ip: 192.168.200.128 port admin-rt2-tenant1 transit switch: admin-tenant1 address: ["aa:aa:aa:aa:bb:02 169.254.100.2/24 fe80::2/64"] port admin-rt2-tenant1_1 transit switch: admin-tenant1_1 address: ["aa:aa:aa:aa:dd:02 169.254.200.2/24"] availability-zone osp3 gateway 97595af9-7896-40d0-a883-beadbff1aa5b hostname: osp3-gwnode1 type: geneve ip: 192.168.200.228 port admin-rt3-tenant1 transit switch: admin-tenant1 address: ["aa:aa:aa:aa:aa:03 169.254.100.3/24 fe80::3/64"] port admin-rt3-tenant1_1 transit switch: admin-tenant1_1 address: ["aa:aa:aa:aa:dd:03 169.254.200.3/24"] -- _‘Esta mensagem é direcionada apenas para os endereços constantes no cabeçalho inicial. Se você não está listado nos endereços constantes no cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão imediatamente anuladas e proibidas’._ * **‘Apesar do Magazine Luiza tomar todas as precauções razoáveis para assegurar que nenhum vírus esteja presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*

3 19

Cinder Bug Report 2023-07-19
by Sofia Enriquez 19 Jul '23

19 Jul '23

Hello Argonauts, Cinder Bug Meeting Etherpad <https://etherpad.opendev.org/p/cinder-bug-squad-meeting> Medium - nvmeof connector _get_host_uuid incompatible when cinder runs in lxd <https://bugs.launchpad.net/cinder/+bug/2027795>. - *Status*: This looks related to bug 2026257 <https://bugs.launchpad.net/bugs/2026257>. Low - Volume to Image upload is very slow due to use of tpool.Proxy() <https://bugs.launchpad.net/cinder/+bug/2027970>. - *Status*: Fix proposed to master <https://review.opendev.org/c/openstack/cinder/+/888676>. Cheers, -- 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

[all][tc] Proposals for reforming extended maintenance
by Nikolla, Kristi 18 Jul '23

18 Jul '23

Hi all, There have been quite a few discussions related extended maintenance in the last few months[0][1]. I have made a first-go at trying to write a policy for extended maintenance moving forward which tries to preserve the value being brought by extended maintenance while strengthening the requirements for keeping branches under that phase. [2] This was based on multiple discussions that I was present at and feedback that I have received from various teams and community members with which I talked, and is my interpretation of that feedback into something that looks like policy. I have also written two opposing policy proposals about what do to with the current branches under extended maintenance. One which attempts to apply the new requirements defined in the first proposal almost immediately[3], and one that aims for a more gradual EOL[4]. Please provide feedback on the proposals and help shape up the future of extended maintenance. Thank you, Kristi Nikolla [0]. https://lists.openstack.org/pipermail/openstack-discuss/2023-June/033980.ht… [1]. https://etherpad.opendev.org/p/vancouver-2023-em [2]. https://review.opendev.org/c/openstack/governance/+/887966 [3]. https://review.opendev.org/c/openstack/governance/+/887968 [4]. https://review.opendev.org/c/openstack/governance/+/887969

3 3

[tc] Technical Committee next weekly meeting today on July 18, 2023
by Nikolla, Kristi 18 Jul '23

18 Jul '23

Hi all, This is a reminder that the next weekly Technical Committee meeting is to be held Today on Tuesday, July 18, 2023, at 1800 UTC on #openstack-tc on OFTC IRC. Please find below the agenda for today's meeting: * Roll call * Follow up on past action items * knikolla will amend proposal for Unmaintained branches. * Extended Maintenance * https://etherpad.opendev.org/p/openstack-exteneded-maintenance * Release notes guidelines for SLURP/NON-SLURP cadence * Gate health check * Open Discussion and Reviews * https://review.opendev.org/q/projects:openstack/governance+is:open Thank you, Kristi Nikolla

1 0

[openstack][largescale-sig] Openstack multi region deployment
by Nguyễn Hữu Khôi 18 Jul '23

18 Jul '23

Hello guys, I am going to deploy openstack multi regions and I know that keystone replication is the most challenging. I plan to set up 2 regions which use centralize galera cluster(3 nodes). and one standby edge galera cluster(3 nodes) When region 1 is node available, I will map region 2 to use standby edge galera cluster. I hope you give me some experience and advice with multi regions. Thank you very much.

2 2

[ops] Built-in rolling-update/instance refresh capabilities
by Matthew Giassa 17 Jul '23

17 Jul '23

Good day, I was originally discussing this on the IRC channel, #openstack, and was advised to reach out to this mailing list. In short, does OpenStack (i.e. via Heat, Senlin, Masakari, or some other feature/plugin), have the ability to perform a rolling upgrade operation on a group of VMs (i.e. similar to the "rolling update" feature in K8S, or the "instance refresh" feature in AWS auto-scaling groups / ASGs). I've reviewed the available documentation, but all documents regarding "rolling upgrades" are with respect to a rolling upgrade of the OpenStack/IaaS stack itself (i.e. operator-level functionality) as opposed to groups of VMs managed by OpenStack (i.e. user-level functionality). I'd ideally like to use built-in functionality to handle this operation, rather than writing a service from scratch. I've also looked into tools such as Spinnaker.io and Harness.io, but could not find any FOSS or COTS tools for implementing rolling upgrades on OpenStack out-of-the-box (though if there are any options I've overlooked, I'm all ears). Thank you. -- ============================================================ Matthew Giassa e-mail: matthew(a)giassa.net website: www.giassa.net

1 0

CVE-2023-2088 for Charmed Openstack
by Corey Bryant 17 Jul '23

17 Jul '23

Bug LP:#2004555 (CVE-2023-2088) identified that “an unauthorised access to a volume could occur when an iSCSI or FC connection from a host is severed due to a volume being unmapped on the storage system and the device is later reused for another volume on the same host”. While the bug affects iSCSI and FC, the fix introduces a breaking change for configurations upgrading to the fixed packages if they do not have service token support enabled. The new code introduces mandatory use of service tokens to identify requests coming from a trusted control plane service. Service tokens are issued by Keystone for service users. For example, a token can be issued to the Nova service user. They have a particular trust level, defined by the service, that allows them to perform trusted actions. In the case of Nova, the action is detaching volumes from instances. Versions of Ubuntu OpenStack for Yoga and later will have new packages versions released with CVE patches applied that require the use of service tokens to enable the detaching and deletion of volumes on instances. These packages will be released on July 24, 2023. Versions of Ubuntu OpenStack for Xena and earlier will not have package updates released and will still be vulnerable to the “unauthorised detach of volumes” issue until a mitigation policy is applied. The mitigation policy provided requires the use of service tokens. For Charmed OpenStack releases, this means that some charms (identified below) must be upgraded to enable service tokens prior to the packages being upgraded and before the mitigation policy is applied. If not, users will lose the ability to detach volumes from their instances. = Patched packages = The following package versions include patches for CVE-2023-2088. These package versions deliver services that require the use of service tokens. Package versions prior to those listed will not be patched for CVE-2023-2088 and will therefore require policy updates for mitigation. Ubuntu 23.04 (Lunar) * nova >= 3:27.0.0-0ubuntu1.3 * cinder >= 2:22.0.0-0ubuntu1.3 * python-os-brick >= 6.2.0-0ubuntu2.3 * ironic >= 1:21.4.0-0ubuntu1.1 * python-glance-store >= 4.3.0-0ubuntu1.3 Ubuntu Cloud Archive Antelope * nova >= 3:27.0.0-0ubuntu1.3~cloud0 * cinder >= 2:22.0.0-0ubuntu1.3~cloud0 * python-os-brick >= 6.2.0-0ubuntu2.3~cloud0 * ironic >= 1:21.4.0-0ubuntu1.1~cloud0 * python-glance-store >= 4.3.0-0ubuntu1.3~cloud0 Ubuntu 22.10 (Kinetic) * nova >= 3:26.1.1-0ubuntu1.1 * cinder >= 2:21.2.0-0ubuntu1.1 * python-os-brick >= os-brick - 6.1.0-0ubuntu1.3 * ironic >= 1:21.1.0-0ubuntu1.1 * python-glance-store >= 4.1.0-0ubuntu1.3 Ubuntu Cloud Archive Zed * nova >= 3:26.1.1-0ubuntu1.1~cloud0 * cinder >= 2:21.2.0-0ubuntu1.1~cloud0 * python-os-brick >= os-brick - 6.1.0-0ubuntu1.3~cloud0 * ironic >= 1:21.1.0-0ubuntu1.1~cloud0 * python-glance-store >= 4.1.0-0ubuntu1.3~cloud0 Ubuntu 22.04 (Jammy) * nova >= 3:25.1.1-0ubuntu1.1 * cinder >= 2:20.2.0-0ubuntu1.1 * python-os-brick >= 5.2.2-0ubuntu1.2 * ironic >= 1:20.1.0-0ubuntu1.1 * python-glance-store >= 3.0.0-0ubuntu1.3 Ubuntu Cloud Archive Yoga * nova >= 3:25.1.1-0ubuntu1.1~cloud0 * cinder >= 2:20.2.0-0ubuntu1.1~cloud0 * python-os-brick >= 5.2.2-0ubuntu1.2~cloud0 * ironic >= 1:20.1.0-0ubuntu1.1~cloud0 * python-glance-store >= 3.0.0-0ubuntu1.3~cloud0 = Charms with Service Tokens Enabled by Default = Following is the list of charms and earliest revision that supports service tokens: Channel: 2023.1/stable * Keystone revision >= 645 * Cinder revision >= 639 * Nova-compute revision >= 678 * Nova-cloud-controller revision >= 674 * Ironic-api revision >= 54 * Ironic-conductor - s390x revision >= 151 - arm64 revision >= 152 - ppc64el revision >= 153 - amd64 revision >= 149 Channel: zed/stable * Keystone revision >= 646 * Cinder revision >= 647 * Nova-compute revision >= 683 * Nova-cloud-controller revision >= 676 * Ironic-api revision >= 53 * Ironic-conductor - s390x revision >= 148 - arm64 revision >= 154 - ppc64el revision >= 150 - amd64 revision >= 147 Channel: yoga/stable * Keystone revision >= 647 * Cinder revision >= 638 * Nova-compute revision >= 681 * Nova-cloud-controller revision >= 679 * Ironic-api revision >= 48 * Ironic-conductor revision >= 145 Channel: xena/stable * Keystone revision >= 651 * Cinder revision >= 640 * Nova-compute revision >= 680 * Nova-cloud-controller revision >= 677 * Ironic-api revision >= 50 * Ironic-conductor revision >= 143 Channel: wallaby/stable * Keystone revision >= 653 * Cinder revision >= 648 * Nova-compute revision >= 684 * Nova-cloud-controller revision >= 675 * Ironic-api revision >= 52 * Ironic-conductor revision >= 144 Channel: victoria/stable * Keystone revision >= 650 * Cinder revision >= 646 * Nova-compute revision >= 679 * Nova-cloud-controller revision >= 678 * Ironic-api revision >= 49 * Ironic-conductor revision >= 142 Channel: ussuri/stable * Keystone revision >= 652 * Cinder revision >= 645 * Nova-compute revision >= 682 * Nova-cloud-controller revision >= 680 * Ironic-api revision >= 51 * Ironic-conductor revision >= 155 = Using a custom Cinder policy as a mitigation = It’s possible to restrict the access to the operations affected by this CVE by providing a custom Cinder policy file that will prevent users from deleting attachments, detach and force detach. In order to use this mitigation, service token support must be enabled. The exact method for customising this depends on the deployment tooling being used. For Charmed OpenStack users it is the following: 1) Identify the nova service user id running the following command openstack user show --domain service_domain -f value -c id nova The command output looks like this ae034831d6bf41099327bf9d34988fbc 2) Create a policy file named cve-2023-2088-cinder.yaml with the following content: "is_service": "role:service or service_user_id:<nova_service_uuid>" "legacy_system_admin_or_project_member": "(role:admin) or (role:member and project_id:%(project_id)s)" "volume:attachment_delete": "rule:legacy_system_admin_or_project_member and rule:is_service" "volume_extension:volume_actions:terminate_connection": "rule:legacy_system_admin_or_project_member and rule:is_service" "volume_extension:volume_actions:detach": "rule:legacy_system_admin_or_project_member and rule:is_service" "volume_extension:volume_admin_actions:force_detach": "!" Replacing “<nova_service_uuid>” would result in a snippet that looks like this: "is_service": "role:service or service_user_id:ae034831d6bf41099327bf9d34988fbc" "legacy_system_admin_or_project_member": "(role:admin) or (role:member and project_id:%(project_id)s)" "volume:attachment_delete": "rule:legacy_system_admin_or_project_member and rule:is_service" "volume_extension:volume_actions:terminate_connection": "rule:legacy_system_admin_or_project_member and rule:is_service" "volume_extension:volume_actions:detach": "rule:legacy_system_admin_or_project_member and rule:is_service" "volume_extension:volume_admin_actions:force_detach": "!" 3) Create zip files from the yaml file: zip cve-2023-2088-cinder.zip cve-2023-2088-cinder.yaml 4) Attach the zip file as a resource to the cinder applications: juju attach-resource cinder policyd-override=cve-2023-2088-cinder.zip 5) Enable the overrides via the use-policyd-override charm option: juju config cinder use-policyd-override=true For more details on using policy overrides see the OpenStack Charm Guide. = Frequently Asked Questions = Q: What can I do if my deployed cloud doesn’t have service tokens enabled and my deployment tooling doesn’t have the option to enable them? A: Pin the version of the affected packages to block the upgrades to the versions listed in “Affected packages” section or newer, until service tokens are enabled. Q: For Charmed OpenStack, what’s the upgrade order for charms and deb packages? A: Upgrade the charms to the latest versions available in the charm channel tracked by your environment or at the least to the revisions listed in section “Charms with Service Token Enabled By Default”. After that, upgrade the deb packages with your preferred method (e.g. Landscape, apt-get, etc). = References = * CVE-2023-2088: https://ubuntu.com/security/CVE-2023-2088 * OSSA-2023-003 Unauthorized volume access through deleted volume attachments: https://security.openstack.org/ossa/OSSA-2023-003.html * OSSN-0092 Using Configuration as a Short-Term Mitigation for OSSA-2023-003: https://wiki.openstack.org/wiki/OSSN/OSSN-0092 * Bug 2004555: https://bugs.launchpad.net/nova/+bug/2004555 * OpenStack Charm Guide Policy overrides: https://docs.openstack.org/charm-guide/latest/admin/policy-overrides.html

1 0