Awesome, that's great news! Thanks for sharing!
Zitat von Michel Jouvin michel.jouvin@ijclab.in2p3.fr:
Hi,
As promised, the conclusion of the story! After installing Octavia in our cloud, we ran the nlbaas2octavia.py tool as suggested by Eugen. It worked like a charm, without any modification. Once the LBs had been converted to Octavia LB, we just had to fix the provider attribute in the DB, changing it from "haproxy" (which is not a provider in Octavia) to "amphora". And then the "openstack coe cluster delete" worked just fine removing these broken LBs as part of the cluster deletion.
Cheers,
Michel
Le 14/07/2023 à 23:24, Michel Jouvin a écrit :
Hi Eugen,
I found some time to look at my issue in the light of your advices! In my research, I found the presentation https://opendev.org/openstack/neutron-lbaas which is both synthetic and clear, with a list of the migration options offered (at the time of the presentation). This includes the DB migration tool, nlbaas2octavia.py. Following your broken link, I manage to find it, it is still there but hidden. You need to checkout the repo https://opendev.org/openstack/neutron-lbaas and go back a couple of revisions (it is explained in the README). It is Python2 but at least it is a starting point, either installing a Python2 venv or migrating the script which is not very long and seems to have very few dependcies, apart from oslo.
I'm afraid that the neutron-lbaas-proxy is no longer an option as, as far as I understood, it relies on some LBAAS code still being present in the Neutron server and this part of the Neutron code has been completely removed I think in Ussuri release (it's the reason of my problems in fact, too bad, it was a matter of a few days, just missed the very old announcement that it would be the case).
If I succeed to clean the things (again I don't really want to migrate the existing LBAAS, I just want to delete them), I'll report in this thread in case it is useful to somebody else...
Best regards,
Michel
Le 08/07/2023 à 00:15, Eugen Block a écrit :
Unfortunately, the link to the migration tool doesn’t work:
https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation
But maybe it can get you in the right direction, neutron-lbaas-proxy seems to be the keyword. But as I already mentioned, I don’t have experience with this path.
Zitat von Eugen Block eblock@nde.ag:
Hi,
I mean the latter. Once you have Octavia installed you can create new LBs, but as I understand it you won’t be able to delete the legacy LBs. Did the neutron config change when you upgraded to Ussuri? I wonder if there’s just some config missing to be able to delete the old LBs, I don’t have a clue tbh. Maybe someone else has some more experience and will chime in.
Zitat von Michel Jouvin michel.jouvin@ijclab.in2p3.fr:
Ho Eugène,
Thanks for your answer. Do you mean that after installing octavia (it is planned) we'll have again the ability to delete the remaining LBAAS instances? Or just that octavia is the LBAAS replacement in terms of functionalities?
Best regards,
Michel Sent from my mobile Le 7 juillet 2023 18:52:30 Eugen Block eblock@nde.ag a écrit :
Hi,
neutron lbaas was deprecated in Queens so you may have to migrate the existing LBs to octavia. I have never done that but I remember reading through the SUSE Docs when one of our customers had to decide whether they wanted to upgrade or reinstall with a newer openstack release. They decided to do the latter, so we set up octavia from scratch and didn't have to migrate anything. There's also a video I've never watched [2], maybe that helps. I can't really tell if a migration is possible to work around your issue but I thought I'd share anyway.
Regards, Eugen
[1] https://documentation.suse.com/soc/9/single-html/suse-openstack-cloud-crowba... [2] https://www.youtube.com/watch?v=jj4KMJPA0Pk
Zitat von Michel Jouvin michel.jouvin@ijclab.in2p3.fr:
> 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