Open J0zi opened 3 years ago
@gallettilance @dinhxuanvu it not only blocks new categories to be added but we are unable to use the latest opm
/operator-sdk
in our pipelines. We are running operator-sdk
in container which works for 0.18.2
https://github.com/operator-framework/community-operators/pull/2941/checks?check_run_id=1664566934#step:3:495 but fails for 1.3.0
https://github.com/operator-framework/community-operators/pull/2941/checks?check_run_id=1662932005.
Seems that functionality to run opm
/operator-sdk
in container was accidental removed or broken.
Thank you.
we found -b none
working for sdk :tada: Need to test it more.
Despite -b none
works in case of sdk against quay registry, issue still persist accessing local kind registry from a container.
We can confirm, that -b podman
was working in very old version 0.18.2
but now not working at all. We are executing an sdk command on a container against local kind registry on the underlying host.
Could you confirm the issue persists on the latest versions of opm or the SDK, and with an alternate container tool (such as docker)? If so, we definitely want to address on the opm side.
We want to attempt to reproduce by running the docker run -it --rm -e STORAGE_DRIVER=vfs --privileged quay.io/operator_testing/operator-test-playbooks:jtest bash
command, seems like there could be a real issue, but there could be multiple things going on.
Bug Report
Categories validation works on a host, not in a container.
What did you do?
Manually built
operator-sdk
operator-sdk version: "v1.2.0-42-g7a741929", commit: "7a741929485a7122d88f1ff22000093ddde13ab0", kubernetes version: "v1.19.4", go version: "go1.15.6", GOOS: "linux", GOARCH: "amd64"
Run
OPERATOR_BUNDLE_CATEGORIES=/tmp/community-operators/categories.json /tmp/operator-test/bin/operator-sdk bundle validate --verbose quay.io/openshift-community-operators/eclipse-che:v7.22.2 --select-optional suite=operatorframework -b podman
in a containerWhat did you expect to see?
All validation tests have completed successfully
What did you see instead? Under which circumstances?
podman cp failed despite cp is working for me manually
Environment
Operator type:
language go
Kubernetes cluster type:
no, just docker container executing podman commands from
operator-sdk
container run command
docker run -it --rm -e STORAGE_DRIVER=vfs --privileged quay.io/operator_testing/operator-test-playbooks:jtest bash
categories.json https://github.com/operator-framework/community-operators/blob/master/categories.json
$ operator-sdk version
operator-sdk version: "v1.2.0-42-g7a741929", commit: "7a741929485a7122d88f1ff22000093ddde13ab0", kubernetes version: "v1.19.4", go version: "go1.15.6", GOOS: "linux", GOARCH: "amd64"
manually compiled master
$ go version
(if language is Go)go1.15.6
$ kubectl version
no
Possible Solution
podman cp
fails using some hash. For mepodman cp
works with specific file, not hash. Not sure if this information helps.Additional context
podman cp is working manually:
The same output using
opm
Here is an
opm
outputVersion: version.Version{OpmVersion:"v1.15.3", GitCommit:"9e92474", BuildDate:"2020-12-03T18:34:29Z", GoOs:"linux", GoArch:"amd64"}