Skip to content
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

Switch to using containers-storage even without --local #262

Merged
merged 4 commits into from
Mar 15, 2024

Conversation

ondrejbudai
Copy link
Member

This pull request switches to using containers-storage even without the --local flag.

@achilleas-k
Copy link
Member

I think we're all going to get stuck on the pull vs no-pull decision (i.e. whether we should behave like --pull=newer).

I think that pulling always is not the greatest idea since we switched to a container storage, but it keeps the backward compatibility.

In my mind, running bib is similar to a podman build and I think I expect it to behave the same way. I could be thinking about it very differently from how users do though, so maybe always pulling makes sense? I honestly don't know.

If I had to choose right now, I'd default to only pulling when missing.

@ondrejbudai
Copy link
Member Author

My thinking is that we will probably want to adjust the behaviour of --local and handling the host's container storage in the future (see #259 and comments from Dan in #120), and this will probably be a somewhat breaking change. Thus, this PR aims to be fully backward compatible, so we don't break users more often neccessary.

In other words, I'm absolutely fine with changing the behaviour, but once we know what the final behaviour should be.

I think that pulling always is not the greatest idea since we switched
to a container storage, but it keeps the backward compatibility.

Note that the manifest test now has to be rootful because we run podman
pull.
@cgwalters
Copy link
Contributor

If I had to choose right now, I'd default to only pulling when missing.

Right; podman-bootc also explicitly goes to similar effort to implement pull-if-not-present semantics and I think it makes sense.

If we always pulled it would break offline development, and we'd at least need a flag to not pull.

Unfortunately there's not a podman pull --policy=if-not-present or so (a tricky thing AFAIK is often these CLI flags need to be added to docker too in order to avoid divergence).

@ondrejbudai
Copy link
Member Author

I agree, Colin, and you can still achieve the same behaviour by using --local and mounting in the container storage. The point of this PR is to unify the codepaths, so we can start doing stuff like in #272.

I know that we should unify the behaviour with podman run and podman-bootc, but I think this needs a bigger discussion, thus I decided not to introduce any functional changes in this PR so we can land it smoothly to unblock other things.

@achilleas-k
Copy link
Member

I decided not to introduce any functional changes in this PR so we can land it smoothly to unblock other things.

Good call. Let's get this merged.

@achilleas-k achilleas-k added this pull request to the merge queue Mar 15, 2024
@cgwalters
Copy link
Contributor

Yep makes sense to me for the record!

Merged via the queue into osbuild:main with commit 8fbaa66 Mar 15, 2024
7 of 9 checks passed
@ondrejbudai ondrejbudai deleted the pull-local branch March 15, 2024 16:31
@rhatdan
Copy link
Contributor

rhatdan commented Mar 15, 2024

You could do a hack of podman run --pull=missing IMAGE true
podman run --help| grep missing
--pull string Pull image policy ("always"|"missing"|"never"|"newer") (default "missing")

@rhatdan
Copy link
Contributor

rhatdan commented Mar 15, 2024

Or
podman image exists IMAGE || podman pull IMAGE

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants