I faced a similar issue from A to C when running nova db online migrations. strangely some process in nova is creating a row in nova.instances table automatically with the uuid as '0000-0000-00000' and other column values for this entry as NULL.
Hi Allison,
I was able to test the upgrade twice today (2 control nodes, 1 compute
node). The first attempt was from A to C (slurp). I had several issues
along the way. I haven't been able to look closely for any root causes
yet, and I also didn't check for existing bugs yet, but I wanted to
share anyway:
1. nova-manage db online_data_migrations: one entry doesn't migrate (1
rows matched query populate_instance_compute_id, 0 migrated)
2. cinder-manage db online_data_migrations:
Running batches of 50 until complete.
2025-04-22 11:01:30.558 837433 WARNING py.warnings [None
req-daa04f7f-7daf-4b46-ac78-eff68794cae5 - - - - - -]
/usr/lib/python3/dist-packages/cinder/db/sqlalchemy/api.py:8620:
SAWarning: Coercing Subquery object into a select() for use in IN();
please pass a select() construct explicitly
filter(admin_meta_table.id.in_(ids_query)).\
+------------------------------------------------+----------------+-------------+
| Migration | Total Needed |
Completed |
|------------------------------------------------+----------------+-------------|
| remove_temporary_admin_metadata_data_migration | 0 |
0 |
+------------------------------------------------+----------------+-------------+
3. Some neutron agents (dhcp, metadata) don't properly start until all
control nodes are upgraded, I needed to stop and start them again.
Need to look for more details in the logs.
4. Horizon has stopped working entirely. I only get a "400 Bad
Request", no matter what I do. When the packages upgraded, I saw a
warning "No local_settings file found", but it is there:
root@controller02:~# ll
/usr/lib/python3/dist-packages/openstack_dashboard/local/local_settings.py
lrwxrwxrwx 1 root root 42 Jun 7 2024
/usr/lib/python3/dist-packages/openstack_dashboard/local/local_settings.py ->
/etc/openstack-dashboard/local_settings.py
The dashboard_error.log also contains the warning that there's no
local_settings file. I suspect that it has to do with the Django
change mentioned in the Caracal release notes:
> Django 3.2 support was dropped. Django 3.2 ends its extended support
> in April 2024. Considering this horizon dropped Django 3.2 support
> and uses Django 4.2 as default.
I decided to rollback the VMs to a previous snapshot (back to
Antelope) and tried the upgrade to Bobcat. The result is better, I
didn't see the neutron agents fail, and the dashboard is still usable.
The only issues I still see are the 'nova-manage db
online_data_migrations' and 'cinder-manage db online_data_migrations'.
If some or all of these issues are know, could anyone point me to the
relevant bug reports? If these are new bugs, I can create reports for
them. But as I mentioned, I don't have too much information yet.
Thanks,
Eugen
Zitat von Allison Price <allison@openinfra.dev>:
> Hi Eugen,
>
> Excellent! Please keep me posted on how testing goes and then we can
> take the next steps in talking about your production environment.
>
> Cheers,
> Allison
>
>> On Apr 21, 2025, at 3:10 PM, Eugen Block <eblock@nde.ag> wrote:
>>
>> Hi and thank you for the links. We just upgraded to Antelope last
>> week, and we plan to do the next upgrade directly to Caracal since
>> we need one of the fixes. I’m planning to test the slurp upgrade on
>> a lab environment quite soon, maybe this week even. And if all goes
>> well, we’ll upgrade our production quickly after that. I‘d be happy
>> to share my experience in this thread. :-)
>>
>> Thanks!
>> Eugen
>>
>> Zitat von Allison Price <allison@openinfra.dev>:
>>
>>> Hi everyone,
>>>
>>> We have now published two case studies from OpenStack users who
>>> have implemented and are benefiting from the SLURP upgrade
>>> process[1]: Cleura[2] and Indiana University[3]
>>>
>>> I wanted to follow up to see if there are other organizations who
>>> have implemented the SLURP upgrade process who would like to tell
>>> your story? If we can get a few more, I would love to schedule an
>>> OpenInfra Live to deep dive into the improvements made around
>>> OpenStack upgrades and what users stuck on older releases should
>>> know.
>>>
>>> If you are interested, please let me know. And even if you’re not
>>> but you’re still using OpenStack—please remember to take the
>>> OpenStack User Survey[4] so we can learn more!
>>>
>>> Thanks!
>>> Allison
>>>
>>>
>>>
>>> [1]
>>> https://docs.openstack.org/project-team-guide/release-cadence-adjustment.html
>>> [2]https://superuser.openinfra.org/articles/streamlining-openstack-upgrades-managing-scalability-efficiency-and-compliance-at-cleura/
>>> [3]
>>> https://superuser.openinfra.org/articles/streamlining-openstack-upgrades-a-case-study-of-indiana-universitys-efficient-upgrade-strategy/
>>> [4] https://www.openstack.org/user-survey
>>
>>
>>