Hi Julien, Thanks for your (unfortunately late) answer.
On 12/3/21 3:11 PM, Julien Cristau wrote: > Control: tag -1 moreinfo > > Hi Thomas, > > On Tue, Aug 17, 2021 at 12:57:50PM +0200, Thomas Goirand wrote: >> Also, I would like to get Nova upgraded to the latest point >> release, to fix numerous small issues. The release notes for >> Nova are there: >> >> https://docs.openstack.org/releasenotes/nova/victoria.html >> > That looks incomplete? Please include a complete description of the > changes you want approved. What do you need exactly that isn't available publicly? The full commit history for Nova Victoria stable branch is here: https://opendev.org/openstack/nova/commits/branch/stable/victoria Here are the commits sum-ups: Changes in nova 22.2.0..22.2.1 ------------------------------ 210abc09b8 guestfs: With libguestfs >= v1.41.1 decode returned bytes to string 7b4f479647 Dynamically archive FK related records in archive_deleted_rows 21241b38dd Add functional test for bug 1837995 382d64ea36 Centralize sqlite FK constraint enforcement c7d9d6d9dd Fix the vGPU dynamic options race 276b8db5af Add config parameter 'live_migration_scheme' to live migration with tls guide 5d1adb2604 libvirt: Use specific user when probing encrypted rbd disks during extend 3d84097eab api: Log os-resetState as an instance action 831abc9f83 Use absolute path during qemu img rebase eda11a4875 libvirt: Skip encryption metadata lookups if secret already exists on host Changes in nova 22.1.0..22.2.0 ------------------------------ 35112d7667 Handle instance = None in _local_delete_cleanup 4f17ea2f7d Add regression test for bug 1914777 3d86df068a tools: Allow check-cherry-picks.sh to be disabled by an env var ef348c4eb3 only wait for plugtime events in pre-live-migration 8e12b81839 Disallow CONF.compute.max_disk_devices_to_attach = 0 09784db62f Prevent archiving of pci_devices records because of 'instance_uuid' Changes in nova 22.0.1..22.1.0 ------------------------------ eebf94b654 compute: Lock by instance.uuid lock during swap_volume 63d2e62c3a Use subqueryload() instead of joinedload() for (system_)metadata 6b57575092 Fallback to same-cell resize with qos ports 7366e3c375 Reproduce bug 1907522 in functional test 4e5b92545d Add upgrade check about old computes 0c5ca351e2 Warn when starting services with older than N-1 computes e3da2ca7be lower-constraints: Bump packaging to 20.4 c3a0969329 Omit resource inventories from placement update if zero eda458828b compute: Don't detach volumes when RescheduledException raised without retry 95fc161334 Add regression test for bug #1899649 478be6f4fb zuul: Replace nova-live-migration with zuulv3 jobs f4d62e1a0b Fix a hacking test 82d415d200 Add missing exception 3ecc098d28 Set instance host and drop migration under lock d768cdbb88 Reproduce bug 1896463 in func env 9a5b6249d6 Use cell targeted context to query BDMs for metadata Do you insist on reviewing *ALL* of the commits, one by one? As you can read above, *all* is bugfix only. Why don't you trust upstream bugfix releases, which contains only targeted bugfixes only, and that goes through extensive unit and functional testing? I also tested the point release, and I have it in production... Products like Firefox ESR get updated this way, and it doesn't seem to be a problem. Should OpenStack be treated differently? If so, why? >> [ Risks ] >> No risk during upgrade that I know of. >> > That is.. not reassuring. What do you need to re reassured? >> * Tune nova-api-{,metadata-}uwsgi.ini for performance. >> >> This is a minor tweak to the uwsgi.ini default configuration, >> which I've started pushing on all OpenStack packages in Debian. >> It's only better with it... > > I don't think this is appropriate for stable. There's no information on > what environment(s) this is tuned for, or benchmarked in. This simply increases the number of processes. https://salsa.debian.org/openstack-team/services/nova/-/commit/46a908d772c542eb63d9013ee71d70f820f32e4e Note that right now, the number of threads is back to "1" (in a later commit) because otherwise nova-api fails to work properly in some cases, because of Eventlet threading thing. The number of process set to 8 is only a better default because without it, uwsgi starts with the same amount of process as core. With modern servers, that's a way too much (imagine 32 processes on a 64 core machine...) and may eat-up too much memory. What's also very important is the "listen 100" which is comparable to the same kind of directive in Apache (ie: to accept maximum 100 waiting connections). Our bench (which I do not have handy, sorry) showed it helps a lot with performances (approximately x2 faster). >> * New upstream release. >> >> See above. > > I'll reserve my opinion on that until we have a better description of > the changes. It seems plausible, broadly. > >> * CVE-2021-3654: novnc allows open redirection. Added upstream patch: >> Reject_open_redirection_in_the_console_proxy.patch (Closes: #991441). >> >> This addresses the main issue that mandates the pu. >> >> * Do not maintain glance_api_servers through debconf (as the default of >> reading its URL in the Keystone catalogue is better). >> >> This avoids tweaking nova.conf on upgrades, which could otherwise >> potentially destroy one's deployment. Indeed, one very valid (and in >> fact recommended) way to deploy, is to *NOT* set the glance_api_servers >> directive. With the debconf code, this forces having something. After >> removing the debconf integration for this directive, upgrade to the >> proposed update isn't breaking deployments anymore, while leaving already >> configured glance_api_servers alone (so not destroying anyone setup). >> > Shouldn't nova/glance_api_servers be cleaned up from the debconf > database if it's no longer used? I'm also not convinced this is > appropriate for stable. This is appropriate because what was there actually *BREAKS* an otherwise working setup: the Glance endpoint is just read from the Keystone service catalogue, and what's done by the debconf thingy, is uncommenting the directive. So upgrading without this change can actually break a cluster. I can add the code to clean-up the debconf database if you think that is better. Cheers, Thomas Goirand (zigo)