-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
State database doesn't save storage options #2217
Comments
We store nothing related to images in the BoltDB state (except for references to which image our containers use). We also don't store storage configuration there, except to use for checking the storage configuration passed in by the user. I wonder if it isn't the storage configuration checks that are blowing up here, though. It could be overwriting some information used by the ostree backend. |
@mheon I don't think that it's only the OStree configuration being affected, since another option active If you are not saving any of those values, then it's probably the configuration check blowing up. |
@mheon I don't know if the presence of the BoltDB is changing the checks in any ways. Remember that removing the DB after each run helps podman honoring those options. |
It seems like we're somehow blanking supplemental storage options when the DB's saved storage configuration is not empty |
(This is strange, because I know we're not doing that for rootless Podman - the fuse-overlayfs mount program is preserved there) |
Due to an issue that I initially faced trying to use OStree with rootless containers I started playing around with these combinations as root. I could isolate the issue as root, but I would expect the same issue to appear rootless. In fact it would probably explain by I'm having issues to get rootless containers using |
Hm. (We have issues where we won't error on trying to load a storage config that is completely unreadable to us, but that doesn't explain why it works the first time and not the second) |
Let me pastebin everything.
Debug output first run -> https://pastebin.com/1YUTuC4U Debug output second run removing BoltDB -> https://pastebin.com/6nET34WK BTW, the result of the second run is exactly the same if I wipe the whole |
Wow! This is strange! Running the same commands rootless (pretty much same configuration, except for user paths and So the issue appears in root execution, but not in rootless execution. This might help you isolate the issue. |
I think it has to be https://github.com/containers/libpod/blob/master/pkg/util/utils.go#L322 For rootless cases, we force a reload of the storage configuration file, which pre-populates our storage config from storage.conf - including storage options For non-rootless cases, once the DB has been created, we pre-populate a good deal of storage.conf from it (to try and ensure path consistency - if you change a directory after containers have been created, strange and undesirable things may happen). That seems to be overriding our normal check into storage.conf which would pick up the additional storage options. I think we need to make that storage.conf reload unconditional, not for only rootless cases |
I agree with @mheon, |
Taking a look at this tomorrow |
@mheon sure! I'll provide any feedback directly on the PR. |
Due to our unconditionally setting some storage options, we are not always reading storage options from storage.conf. This can lead to some fields in the storage config (most notably extra storage options) being ignored, despite being set in storage.conf. Resolve this by unconditionally refreshing our storage config from storage.conf (this was previously only done for rootless Podman) Fixes containers#2217 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
/kind bug
Description
State DB (Bolt) doesn't save storage options, therefore they are honored on the first run, but not on following runs.
Steps to reproduce the issue:
Configure a storage option (e.g.
ostree_repo = "/var/lib/ostree"
).Pull an image with debug level "looking" for the options output:
sudo podman --log-level debug pull alpine:3.8 2>&1 | grep "overlay: "
Pull another image with debug level "looking" for the options output:
sudo podman --log-level debug pull alpine:3.7 2>&1 | grep "overlay: "
Describe the results you received:
On first pull:
References available in OStree repository (
ostree refs --repo=/var/lib/ostree
):On second pull:
References available in OStree repository (
ostree refs --repo=/var/lib/ostree
):Describe the results you expected:
On first pull:
References available in OStree repository (
ostree refs --repo=/var/lib/ostree
):On second pull:
References available in OStree repository (
ostree refs --repo=/var/lib/ostree
):Additional information you deem important (e.g. issue happens only occasionally):
If the state DB (
bolt_state.db
) is removed after the first run, then the output is the expected one.Output of
podman version
:Output of
podman info
:Whereas the value of
GraphOptions
after first run isAdditional environment details (AWS, VirtualBox, physical, etc.):
Bare metal installation of Arch Linux. Libpod from AUR package: https://aur.archlinux.org/packages/libpod/
The text was updated successfully, but these errors were encountered: