Skip to content

Conversation

vrothberg
Copy link
Member

@vrothberg vrothberg commented Sep 25, 2023

The default pull policy is "missing" not "always".

Fixes: #20125

Does this PR introduce a user-facing change?

Fix a bug in the podman-build man pages and correct the default value of --pull to "missing".

@vrothberg vrothberg marked this pull request as ready for review September 25, 2023 08:08
@openshift-ci openshift-ci bot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. release-note and removed do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. labels Sep 25, 2023
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Sep 25, 2023

[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:

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

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 25, 2023
Copy link
Member

@Luap99 Luap99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

podman build --help says the default is true which according to the man page equals always, can you fix it there as well?

@vrothberg
Copy link
Member Author

vrothberg commented Sep 25, 2023

podman build --help says the default is true which according to the man page equals always, can you fix it there as well?

That needs fixing in buildah.

EDIT: oh, actually I should be able to update it in Podman.

@flouthoc
Copy link
Collaborator

Is true equal to always ? i remember conversation on this in past. If they are equal I think some correction is needed here as well https://github.com/containers/buildah/blob/main/docs/buildah-build.1.md

@vrothberg
Copy link
Member Author

vrothberg commented Sep 25, 2023

Is true equal to always ? i remember conversation on this in past. If they are equal I think some correction is needed here as well https://github.com/containers/buildah/blob/main/docs/buildah-build.1.md

Yes, true equals always.

@vrothberg vrothberg changed the title [CI:DOCS] podman build: correct default pull policy podman build: correct default pull policy Sep 25, 2023
Copy link
Member

@Luap99 Luap99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@edsantiago
Copy link
Member

Suggestion, should you feel like re-pushing:

diff --git a/test/system/070-build.bats b/test/system/070-build.bats
index d780a2e2d..56da8ef32 100644
--- a/test/system/070-build.bats
+++ b/test/system/070-build.bats
@@ -24,6 +24,10 @@ EOF
     PODMAN_TIMEOUT=240 run_podman build -t build_test --format=docker $tmpdir
     is "$output" ".*COMMIT" "COMMIT seen in log"
 
+    # $IMAGE is preloaded, so we should never re-pull
+    assert "$output" !~ "Trying to pull" "Default pull policy should be 'missing'"
+    assert "$output" !~ "Writing manifest" "Default pull policy should be 'missing'"
+
     run_podman run --rm build_test cat /$rand_filename
     is "$output"   "$rand_content"   "reading generated file in image"
 

The default pull policy is "missing" not "always".

Signed-off-by: Valentin Rothberg <[email protected]>
@vrothberg
Copy link
Member Author

Updated and repushed, thanks @edsantiago !

@vrothberg
Copy link
Member Author

Note: close #20125 once merged. I didn't add that to the commit message.

@edsantiago
Copy link
Member

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Sep 25, 2023
@openshift-merge-robot openshift-merge-robot merged commit c59d1df into containers:main Sep 25, 2023
if err := flag.Value.Set("true"); err != nil {
logrus.Errorf("Unable to set --pull to true: %v", err)
flag.DefValue = "missing"
if err := flag.Value.Set("missing"); err != nil {
Copy link
Member

@TomSweeneyRedHat TomSweeneyRedHat Sep 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless I'm mistaken, this is different than Docker, which does a pull=true by default.

@TomSweeneyRedHat
Copy link
Member

This change worries me. It seems like every year we decide on different functionality/behavior for pull and its options. For instance, in March 2020, I posted this blog: https://www.redhat.com/sysadmin/podman-image-pulling.

In my book, especially if we want to match Docker, --pull=true != --pull=always. IMO, true should only pull the image if it is not in the local storage, or if the version on the registry is different than the one in local storage. A failure should be thrown if the image can't be found in either the registry or local storage. The always variant should always pull, regardless of what's in the local storage. If the image can't be pulled, an error should be thrown, even if there's a copy in local storage.

This appears to be different than what @vrothberg says where true=always.

I think the default pull should be pull=true, as I defined above, so that we can emulate Docker. However, I think I made this argument once before and it was shot down.

Regardless, I'd like someone to write a document that we can all agree with, and that, going forward, we can use it as the point of truth for what pull and its variety of options should and should not do. I'd be happy to start the initial document if people would like. Please let's discuss this in a scrum soon.

@vrothberg vrothberg deleted the build-docs branch September 26, 2023 06:40
@vrothberg
Copy link
Member Author

This change worries me. It seems like every year we decide on different functionality/behavior for pull and its options. For instance, in March 2020, I posted this blog: https://www.redhat.com/sysadmin/podman-image-pulling.

Did you read the conversation above (#20124 (comment))? The only thing that changes in this PR is the displayed default in the help message, nothing else.

The default behavior is "missing" but --pull (without a string value) is the same as --pull=true. That's exactly how Docker behaves: only with --pull local images will be repulled.

In my book, especially if we want to match Docker, --pull=true != --pull=always.

That's not how it's been implemented. true always mapped to always and that is how Docker behaves as well.

This appears to be different than what @vrothberg says where true==always.

The code and the docs say it, not me ;-)

I think the default pull should be pull=true, as I defined above, so that we can emulate Docker. However, I think I made this argument once before and it was shot down.

It behaves like Docker at the moment already. Again, the only the changes in this PR is to display the correct default.

Regardless, I'd like someone to write a document that we can all agree with, and that, going forward, we can use it as the point of truth for what pull and its variety of options should and should not do. I'd be happy to start the initial document if people would like. Please let's discuss this in a scrum soon.

I honestly think you started reviewing this PR on the wrong foot. The last time we wrestled through these details, the behavior was written down in the docs already which clearly state that true == always.

@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Dec 26, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. release-note
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Docs] Outdated default for --pull in 'podman build'
6 participants