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

pull with custom platform: handle "localhost/" #679

Merged
merged 1 commit into from
Jul 16, 2021

Conversation

vrothberg
Copy link
Member

Commit bee8cae enforced the pull policy to "always" when a custom
platform was specified. The reason for always pulling is that many
multi-arch images are broken; wrong configs, wrong platforms, etc.

We cannot perform reliable platform checks. While we may to have to
revisit this strategy in the future, it is more important to keep
existing workloads running; a bit between a rock and hard place.

This change complements commit bee8cae: if attempt to pull an image
that resolves to "localhost/", set the pull policy "newer" instead of
"always" such that the image may be used instead of erroring out.
Ultimately to preserve previous behavior.

Context: containers/podman/issues/10914
Signed-off-by: Valentin Rothberg [email protected]

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jul 16, 2021

[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

pullPolicy = config.PullPolicyAlways
if strings.HasPrefix(resolvedImageName, "localhost/") {
logrus.Debugf("Enforcing pull policy to %q to support custom platform (arch: %q, os: %q, variant: %q)", "newer", options.Architecture, options.OS, options.Variant)
pullPolicy = config.PullPolicyNewer
Copy link
Member

Choose a reason for hiding this comment

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

Wouldn't this be never? Were is podman going to pull a localhost/* image from?

Copy link
Member Author

Choose a reason for hiding this comment

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

"newer" was intended but I am open to change to "never". Let me change something to the following:

  • pull("foo") -> resolved to "localhost/foo" -> pull neWer since there may still be an alias or registry
  • pull("localhost/foo") -> clearly resolves to a local image -> pull neVer

Copy link
Member Author

Choose a reason for hiding this comment

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

@rhatdan updated. Does it make more sense now?

Commit bee8cae enforced the pull policy to "always" when a custom
platform was specified.  The reason for always pulling is that many
multi-arch images are broken; wrong configs, wrong platforms, etc.

We cannot perform reliable platform checks.  While we may to have to
revisit this strategy in the future, it is more important to keep
existing workloads running; a bit between a rock and hard place.

This change complements commit bee8cae: if attempt to pull an image
that resolves to "localhost/", set the pull policy "newer" instead of
"always" such that the image may be used instead of erroring out.
Ultimately to preserve previous behavior.

Context: containers/podman/issues/10914
Signed-off-by: Valentin Rothberg <[email protected]>
@rhatdan
Copy link
Member

rhatdan commented Jul 16, 2021

LGTM

@mheon
Copy link
Member

mheon commented Jul 16, 2021

/lgtm

@openshift-ci openshift-ci bot added the lgtm label Jul 16, 2021
@openshift-merge-robot openshift-merge-robot merged commit ffcfe1f into containers:main Jul 16, 2021
@TomSweeneyRedHat
Copy link
Member

The changes look fine for what you're proposing, but I'm leery.
A) We'll need to change the --pull documentation in at least Buildah bud/pull, Podman build/pull, maybe Skopeo, and others. We probably should have done this after you last commit.

B) This doesn't line up with Docker and prior pull policies, no? Is this going to break people, or at least give unexpected results?

@TomSweeneyRedHat
Copy link
Member

And,
If someone throws in --pull-always or --pull-never is this logic ignored?

@vrothberg vrothberg deleted the fix-10914 branch July 16, 2021 15:03
@vrothberg vrothberg mentioned this pull request Jul 16, 2021
@vrothberg
Copy link
Member Author

The changes look fine for what you're proposing, but I'm leery.
A) We'll need to change the --pull documentation in at least Buildah bud/pull, Podman build/pull, maybe Skopeo, and others. We probably should have done this after you last commit.

Skopeo is not using that code. But I agree that we should mention that in the docs.

B) This doesn't line up with Docker and prior pull policies, no? Is this going to break people, or at least give unexpected results?

Can you precise "this"? Just to be sure we're talking about the same thing.

Ultimately, I do not think we have much of a choice. Relying on the platform is wrong. One thing I will add to the main branch soon though is to only overwrite the policy if the local image does not match. That will be an optimzation for cases where the specified platform matches the local image.

But I am too afraid to do that now so close to the release. Needs some more cooking.

@TomSweeneyRedHat
Copy link
Member

My concern is when a user says "when I pull with Docker, I get this image, but something different when I pull with Buildah/Podman" after this change goes through.

@rhatdan
Copy link
Member

rhatdan commented Jul 16, 2021

If you pull localhost/foobar on docker, you will get an error, since you can't create an image named that. localhost/foobar has special meaning in podman/buildah/skopeo.

Pulling a localhost/image makes no sense, so we can either throw an error or ignore the pull.

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

Successfully merging this pull request may close these issues.

5 participants