Open Stack

Awesome, that's great news! Thanks for sharing!

Zitat von Michel Jouvin <michel.jouvin at 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 at 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 at 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 at 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-crowbar-deployment/#sec-depl-ostack-octavia-migrate-users [2]  
>>>>>> https://www.youtube.com/watch?v=jj4KMJPA0Pk
>>>>>>
>>>>>> Zitat von Michel Jouvin <michel.jouvin at 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
>>>
>>>
>>>
>>>