-
Notifications
You must be signed in to change notification settings - Fork 546
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
0.15.0 install hang #1534
Comments
Not sure why, but i was thinking the crd's shouldn't be in that file either. there is a separate crd file usually. |
if I cut out the crds for subscriptions and csv's out of the file, it loads ok. |
If I cut everything but subscripts crd out, it fails to load. |
Same problem here, did not finish after running a whole night. It is my first time trying out olm and I didn't realize the release was only 1-2 hours old at the time^^ Gonna use 0.14.1 for the time being. Platform: Digitalocean/Kubernetes
|
The manifest also refers to:
which is inaccessible. |
Still not sure what's going on with the CRDs. I think it has to do with there being the string '---' being used in the crd definitions. Stripping them works:
Oddly, if you apply a second time, it hangs:
|
Ok. Narrowing it down I think...
Twice, it fails. Two of the crd's don't like being applied a second time. As its both in the crds.yaml and the olm.yaml (incorrect), it fails during olm.yaml unless there is some change. I suspect some interaction with these crd's and the k8s serverside apply code in 1.18. When loading the crd's into k8s, the apiserver throws this in the logs:
|
We are aware that there are issues with the 0.15.0 release, and are working on recalling the 0.15.0 release and cutting a new release 0.15.1. Will update this issue when 0.15.1 is ready. Apologies for the confusion. |
@kfox1111 the issue was that the 0.15.0 tag in quay was deleted. It's been restored now, however the 0.15.0 assets contains a commit beyond the 0.15.0 tag in quay. We're publishing a patch before we recall 0.15.0 so that the assets and the quay tag are in sync. |
That explains why it wouldn't start after the crds were removed from the olm.yaml file. Still unsure why the crd loading themselves ffail on reapply though. I'm wondering if 0.15.1 will have the same issue. |
@kfox1111 the failure you're seeing on reapplying the CRDs might be due to a kubectl bug in this library: evanphx/json-patch@v4.4.0...v4.6.0 Applying quickstart/olm.yaml was failing because the CRDs were being included in that file too. |
Ah. Thanks for the link and the details and for looking into it. :) And thanks for all the hard work. OLM's really a great piece of software. |
@kfox1111 I dug into the hanging kubectl apply, and as far as I can tell it's legitimately busy constructing a JSON patch the entire time due to the size of some of the CRD schemas. The log message you found is an open issue on the Kube API server (kubernetes/kubernetes#90902), but it's a red herring. |
Explanation and fix went in here evanphx/json-patch#87, but kube seems to be using 4.2.0, which pre-dates that change. |
Ah. Very interesting. Thanks. :) |
Still hitting this with 0.15.1 |
/cc |
In a new minikube instance (1.10.1), I installed the crd's and that works. but applying the olm manifest is hanging:
[kfox@zathras ~]$ kubectl apply -f https://github.com/operator-framework/operator-lifecycle-manager/releases/download/$OLMVER/olm.yaml
customresourcedefinition.apiextensions.k8s.io/catalogsources.operators.coreos.com configured
Tried to download it and apply it locally. same effect. Blew away minikube, started a fresh one, and same problem.
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T11:56:40Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T11:48:36Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
The text was updated successfully, but these errors were encountered: