-
Notifications
You must be signed in to change notification settings - Fork 329
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Worked for me once I rebuilt my local waypoint server image. One thing we should improve here (potentially in a separate PR) is a better way to check the state of the runner pod post install. The waypoint output said that it was reported as ready, but kubectl said the pod wasn't ready and was in a crash backoff loop. So maybe we can make that a bit better for any other runner pod install errors that could come up in the future.
Good idea! Good idea. I think we can introduce a |
Actually just noticed this was the K8S PR specifically 馃槃 I think adding a pod status probably is a good idea. Let me look into that now. |
@mitchellh maybe it could be similar to what we do on Deploy for k8s? waypoint/builtin/k8s/platform.go Lines 433 to 468 in 8c2bfa7
|
Just pushed an easy short term fix :) I noticed we were checking for ready equality but it starts out at 0 so we don't wait at all. This now checks if |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! The short term fix works for me. Ends up polling for a while before exiting rather than continuing on saying it's ready 馃憤
This adds Kubernetes support for runner management.
I use a Deployment for runners since they have no state.
The only sneaky thing here is that during uninstall of a runner, I grab the cpu and memory requirements of the last install and persist them so we can use them on the next install (in the same process) which happens during an upgrade. I do this because we don't ask for these flags for the upgrade command and I think we shouldn't, we should just copy the existing settings.
Most of the LOC in this PR is just extracting client initialization into a standalone function. 馃槃