This is not sufficiently useful. If anything, the way to go is what we used to do for PostgreSQL: ship the old version inside the newer version as a non-path executable (i.e. in /usr/libexec) just so migration scripts can use it.
yep that would be better.
What is the command to test if a user has an unmigrated BoltDB?
podman images triggers the warning on my end with podman version 5.7.1.
podman images
Cool, thanks. What about a command that can be run for other users? (Something in the spirit of file ~user/some/path | grep Bolt)
This machine has only had one user for at least two years. When I install Fedora (in my case Atomic Desktops) on other machines for testing, the warning does not appear.
podman info --format {{.Host.DatabaseBackend}}
That either says boltdb or sqlite, if you are on sqlite then all is good.
I think that is a good idea, sorry I missed that before. At least maintenance wise it seems like the most straight forward.
The problem is podman is not exactly a small binary (5.7.1 is 42 MB) so duplicating this install and package size seems unwanted. I think there are variants such as coreos that include podman by default so I would assume they would not be to happy about such a size bump.
The bigger technical issue is that running podman 5.X and 6.X in parallel is not something we can support or test realistically to the point where I would say it may be possible to corrupt the container state by doing this so I rather have two packages that clearly conflict.
Hmm…
Is the sqlite/boltdb migration code partitioned off as a functional golang package? If it is can you point me to it?
Naively, I would think it should be reasonable for someone to wrap that with in a small stand-alone migration command. If this functionality is an importable golang package, even I, might be able to do my own migration using the golang package outside of podman.
So far the code is not yet merged though that will happen for 5.8 rc1 this week https://github.com/containers/podman/pull/27660
The code is not its own package and somewhat deeply intertwined with the rest of our libpod package so I am not sure it would be trivial to extract that from there but of course possible if someone would want to spend the time on it.
hmm..
well that answers that, the db migration logic isn’t a functional golang package that libpod imports and makes use of. That makes it much more difficult to put a small stand alone utility together.
Seems all the business logic is effectively contained in the migrateDB and migrateNodeDatabase functions inside libpod, which is a golang package.
Restating the result of the FESCO discussion here:
Podman 6 is approved to land in Fedora 44 with the following conditions:
-
The complete set of incompatible changes must be in
updates-testingby the beginning of the Beta Freeze. -
Upgrades must be cleanly supported from Fedora 42.
As discussed with Neal we will extract the migration logic out of podman and ship that together as separate binary alongside of podman 6 in the same rpm. And then we work out a away to trigger that migration automatically wherever possible.
If we cannot deliver all breaking changes in time or provide a satisfactory migration path in time we should delay the podman 6 update to f45.
This change has been approved by FESCo and will be included in Fedora Linux 44.
To find out more about how our changes policy works, please visit our docs site.
FESCo Issue: Making sure you're not a bot!
Some late comments.
If we split this into a sub package, we can exclude it on Fedora CoreOS as we can also (mostly) guarantee that systems updates go through specific versions so we can make sure that systems boot a version with podman 5.8 at least once before we move to podman 6.
But keeping the migration code alongside podman 6 will also not hurt for users that don’t use auto updates so this will be useful for Fedora CoreOS as well.
It’ll at least avoid some of the painful failures from previous migrations and it’ll be beneficial for when Podman 6 is shipped in CentOS/RHEL too.
1 Like
This change has been deferred from Fedora Linux 44 to Fedora Linux 45.
The change will be retargeted for the F45 release cycle.
FESCo Issue: Making sure you're not a bot!