-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
feat: RunnerDeployments #2
Conversation
RunnerSet is basically ReplicaSet for Runners. It is responsible for maintaining number of runners to match the desired one. That is, it creates missing runners from `.Spec.Template` and deletes redundant runners. Similar to ReplicaSet, this does not support rolling update of runners on its own. We might want to later add `RunnerDeployment` for that. But that's another story.
Adds the initial version of RunnerDeployment that is intended to manage RunnerSets(actions#1), like Deployment manages ReplicaSets. This is the initial version and therefore is bare bone. The only update strategy it supports is `Recreate`, which recreates the underlying RunnerSet when the runner template changes. I'd like to add `RollingUpdate` strategy once this is merged. This depends on actions#1 so the diff contains that of actions#1, too. Please see only the latest commit for review. Also see https://github.com/mumoshu/actions-runner-controller-ci/runs/471329823?check_suite_focus=true to confirm that `make tests` is passing after changes made in this commit.
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.
Thank you for the PR! I really like this 👍
This is a good starting point for a mechanism that makes Runner easier to scale.
Overall, there seems to be almost no problem, but I made some comments to improve some codes.
As discussed face-to-face, I'm considering to use StatefulSet to manage replica of runners. I'm not sure if we actually use this implementation at this time. 😉However, I'd like to merge this PR to compare the way of the implementation.
if err := r.List(ctx, &allRunnerSets, client.InNamespace(req.Namespace)); err != nil { | ||
if !errors.IsNotFound(err) { | ||
return ctrl.Result{}, err | ||
} |
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.
I think that this is not needed.
List interface will return empty list instead of 'NotFound' error.
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.
Thanks. Addressed in 70a8c3d
if metav1.IsControlledBy(&rs, &rd) { | ||
myRunnerSets = append(myRunnerSets, &rs) | ||
} | ||
} |
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.
It might be better to use 'Field Indexer' to get related RunnerSets.
You can see an example of Field Indexer in the kubebuilder book:
https://book.kubebuilder.io/cronjob-tutorial/controller-implementation.html?highlight=field,indexer#2-list-all-active-jobs-and-update-the-status
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.
Thanks! I've never realized that controller-runtime had such a facility. Addressed in 31fb7cc
Enhances the deployment controller to use indexed lookups against runner sets for more scalability.
Removes an unnecessary condition from the deployment controller code. We assumed that the client would return a not-found error on an empty runnerset list it is clearly not the case.
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.
LGTM 👍
Adds the initial version of RunnerDeployment that is intended to manage RunnerSets(#1), like Deployment manages ReplicaSets.
This is the initial version and therefore is bare bone. The only update strategy it supports is
Recreate
, which recreates the underlying RunnerSet when the runner template changes. I'd like to addRollingUpdate
strategy once this is merged.This depends on #1 so the diff contains that of #1, too. Please see only the latest commit for review.
Also see https://github.com/mumoshu/actions-runner-controller-ci/runs/471329823?check_suite_focus=true to confirm that
make tests
is passing after changes made in this commit.