[CI:DOCS] containers.conf: database_backend

[vrothberg]

Document the database_backend option which has been added earlier but intentionally left undocumented to avoid the impression sqlite would be ready for prime-time.

@mheon @baude @giuseppe PTAL

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vrothberg

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [vrothberg]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rhatdan]

LGTM
@containers/podman-maintainers PTAL

[Luap99]

Maybe make it clear that users should run podman system reset before switching? We shouldn't allow using both db's at once.

[mheon]

Switching back and forth doesn’t require a reset, so as long as we document the CLI flag as well I don’t think it’s necessary to recommend system reset.

…

On Mon, Apr 17, 2023 at 07:38 Paul Holzinger ***@***.***> wrote: ***@***.**** commented on this pull request. Maybe make it clear that users should run podman system reset before switching? We shouldn't allow using both db's at once. — Reply to this email directly, view it on GitHub <#1422 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCHE7Z6PWCT74XOLNA3XBUTUJANCNFSM6AAAAAAXA6I4TM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[vrothberg]

Maybe make it clear that users should run podman system reset before switching? We shouldn't allow using both db's at once.

I think that's rather something Podman should do/decide on. Podman could error out when there's already an existing DB that doesn't match the user/config selection.

[Luap99]

Switching back and forth doesn’t require a reset, so as long as we document
the CLI flag as well I don’t think it’s necessary to recommend system reset.

Well sure it doesn't have to, changing the network backend never required it either.
For starters changing it will immediately loose all access to your containers unless you change it back.
My point is that things can go bad very quickly. Just one example when I create a volume with the same name in both dbs then I delete it in one of them it deletes the data for both since they use the exact same underlying path.

Also there is zero information about what podman actually stores in the db. I loose access to containers, pods and volumes. However images and networks are shared for both because these are not stored in the db. As a naive user this is very confusing.

I think that's rather something Podman should do/decide on. Podman could error out when there's already an existing DB that doesn't match the user/config selection.

Yes that is what I would prefer but it also boils down to: you should do a system reset before switching this config option.

[rhatdan]

I think you can document what is different in the man page as well as containers.conf.

[rhatdan]

And then recommend the reset to permanently make the changes. Or at lease remove all networks and containers.

[vrothberg]

Let's just state that "podman system reset may be necessary when changing from one backend to another"

[vrothberg]

I do not think we should document which data is being stored in the DB. That is an internal that IMO no user should let their workloads rely on. The bottom line should always be that users need to expect to lose all their data when switching the backend/run system reset.

[rhatdan]

Fine document that without resetting the storage then the system will not work correctly and executing the podman system reset is the best option.

[vrothberg]

Done, PTAL

[Luap99]

LGTM

[rhatdan]

Can you add

patch

[vrothberg]

Done, thanks!

[vrothberg]

merge me

[Luap99]

/lgtm