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

oc import-image --from=registry cross-cross:latest --confirm --insecure #9730

Open
soltysh opened this issue Jul 7, 2016 · 9 comments
Open
Assignees
Labels
blocked component/image kind/bug Categorizes issue or PR as related to a bug. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/P2

Comments

@soltysh
Copy link
Contributor

soltysh commented Jul 7, 2016

While working on cherry picking #9580 I was invoking:

oc import-image --from=${DOCKER_REGISTRY}/custom/cross:namespace-pull cross-cross:latest --confirm --insecure

For some reason --insecure flag was not applied to the created Image Stream.

@soltysh soltysh added kind/bug Categorizes issue or PR as related to a bug. priority/P1 priority/P2 component/image labels Jul 7, 2016
@soltysh soltysh self-assigned this Jul 7, 2016
@soltysh
Copy link
Contributor Author

soltysh commented Jul 7, 2016

When working on this please add following test:

imageid=$(docker images | grep custom/cross | awk '{ print $3 }')
os::cmd::expect_success "docker rmi -f ${imageid}"
echo "[INFO] Importing image from internal registry for chained cross pull"
os::cmd::expect_success "oc import-image --from=${DOCKER_REGISTRY}/custom/cross:namespace-pull cross-cross:latest --confirm --insecure"
os::cmd::expect_success "docker pull ${DOCKER_REGISTRY}/cache/cross-cross:latest"
echo "[INFO] Cross namespace chained pull successful"

which is failing right now.

@soltysh
Copy link
Contributor Author

soltysh commented Jul 8, 2016

The --insecure flag works as expected, just checked, lowering prio to p2. I'm still trying to figure out why the test fails, though.

@miminar
Copy link

miminar commented Jul 8, 2016

IMHO the problem here is that the registry is trying to pullthrough from itself. Using the importer which is invoked with insecure=false (hardcoded). And of course this fails because the registry is not secured.

@soltysh
Copy link
Contributor Author

soltysh commented Jul 8, 2016

This is blocked by #9758. We can't implement that without the option to specify multiple secrets.

@miminar
Copy link

miminar commented Dec 18, 2017

#17238 should be addressed when fixing this.

@bparees
Copy link
Contributor

bparees commented Jan 19, 2018

This is blocked by #9758. We can't implement that without the option to specify multiple secrets.

@soltysh @miminar why do we need multiple secrets to resolve this?

Can one of you provide an updated summary of exactly what scenario is broken?

What I am seeing is:

  1. push an image in one project
  2. as the same user, import that image into a second project (from the registry)
  3. the imagestream is marked insecure(and the registry is) but the import fails with:
 message: you may not have access to the Docker image "172.30.244.80:5000/p2/foo:latest"

I would assume the issue here is simply that the docker secret that the importer picked up from my second project doesn't have access to the first project.

Is there something deeper?

@soltysh
Copy link
Contributor Author

soltysh commented Jan 24, 2018

Sorry, I can't remember a thing 😢 I'll defer to @miminar since he's still playing with images and registry.

@openshift-bot
Copy link
Contributor

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci-robot openshift-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 24, 2018
@bparees
Copy link
Contributor

bparees commented Apr 24, 2018

/lifecycle frozen
/remove-lifecycle stale

@openshift-ci-robot openshift-ci-robot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Apr 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked component/image kind/bug Categorizes issue or PR as related to a bug. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/P2
Projects
None yet
Development

No branches or pull requests

5 participants