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

clusterctl create sometimes fails to create cluster object #385

Closed
krousey opened this issue Jun 22, 2018 · 5 comments · Fixed by #388
Closed

clusterctl create sometimes fails to create cluster object #385

krousey opened this issue Jun 22, 2018 · 5 comments · Fixed by #388
Assignees

Comments

@krousey
Copy link
Contributor

krousey commented Jun 22, 2018

Usually appears like:

F0622 10:16:44.593398  128171 create_cluster.go:58] unable to create cluster object: Timeout: request did not complete within allowed duration
@krousey
Copy link
Contributor Author

krousey commented Jun 22, 2018

/assign @krousey

@roberthbailey
Copy link
Contributor

This has been happening to me quite frequently this week.

Environment:

macOS 10.13.5
minikube 0.28.0 (and then also 0.27.0)
VirtualBox Version 5.2.12 r122591 (Qt5.6.3)

If I give minikube more memory & cpu, then it seems more likely that the call doesn't time out, but it's still hit or miss.

@krousey
Copy link
Contributor Author

krousey commented Jun 22, 2018

This is happening, contrary to my earlier assumptions, because the cluster-api API server comes up and registers the cluster API group with the main server before it's backing ETCD store is ready. This is a race, but exacerbated by the fact that we pull from quay's latest tag, and always pull.

I can reliably reproduce this by changing the image field to something that can't be pulled.

@krousey
Copy link
Contributor Author

krousey commented Jun 22, 2018

I'm going to change the image, and add some more detection for readiness so we can avoid this.

@krousey
Copy link
Contributor Author

krousey commented Jun 23, 2018

Also a recent switch from Poll to PollImmediate made the race more likely. This is probably the reason some of us were seeing this more frequently. I had been using an old version that didn't have this change.

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

Successfully merging a pull request may close this issue.

2 participants