-
Notifications
You must be signed in to change notification settings - Fork 462
Watch scheduler CR and make masters schedulable accordingly #937
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
Watch scheduler CR and make masters schedulable accordingly #937
Conversation
| node.Spec.Taints = newTaints | ||
| }) | ||
| if err != nil { | ||
| glog.Errorf("error making node %v schedulable with error %v", 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.
As a general rule, rather than logging and continuing, please return the error and let the higher level logic retry.
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.
In this case, it might be different - we cannot return error when it fails for a single node, perhaps we need to capture slice of errors for individual nodes and return. I don't have a strong preference but I see your point.
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.
we cannot return error when it fails for a single node,
Why not?
perhaps we need to capture slice of errors for individual nodes and return.
Yes, that's a better pattern indeed, but I think "fast fail for single item" is still better than "log and continue".
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.
Yeah, I have done slice collection and then returned because in the next iteration it could cause problems with other node. Let me know, if you prefer it other way
bc654d7 to
0304353
Compare
545902f to
d23ccf7
Compare
d23ccf7 to
96cd136
Compare
| @@ -14,5 +14,5 @@ rules: | |||
| resources: ["configmaps", "secrets"] | |||
| verbs: ["*"] | |||
| - apiGroups: ["config.openshift.io"] | |||
| resources: ["images", "clusterversions", "featuregates"] | |||
| resources: ["images", "clusterversions", "featuregates", "schedulers"] | |||
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.
This can be changed futher to just list, instead of giving *
|
@ravisantoshgudimetla this patch looks good - is there some testing I can perform manually? |
|
|
/test e2e-aws-upgrade |
1 similar comment
|
/test e2e-aws-upgrade |
364cabb to
2cc6a1e
Compare
|
/retest |
|
/retest
|
|
|
|
/test e2e-aws verify needs some care |
57995a9 to
f6b7b5f
Compare
|
Overall this looks good, thanks for working on it! Can you please squash it into one commit - since this is really one logical change. And also now the last commit has intermixed fixups from review. And please write a commit message, something like:
|
f6b7b5f to
b265bd4
Compare
|
Thanks for the review @runcom @cgwalters @kikisdeliveryservice. I made the changes suggested. PTAL |
|
/retest |
|
this lgtm will let @cgwalters / @runcom give the final approval |
|
needs a rebase :( |
The bright side is it's an opportunity to use the 🏄♂️ emoji |
b265bd4 to
3c60a1a
Compare
|
Rebased 🙈 |
|
ci didn't like that last commit :( |
|
uhoh hitting limits now:
|
|
reported but ci has been hitting this for the last few hours. |
|
/retest |
|
/lgtm |
By default, the MCO's kubelet configuration injects a taint to disable scheduling. This adds support in the MCO for watching the API recently added to allow the masters to be schedulable. openshift/api#366 Use cases here are for 3 node bare metal clusters (which have significant resources on the masters), as well as CodeReady Containers which wants to make a single node OpenShift as a VM. Closes: openshift#763
eb910e1 to
5144a15
Compare
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, ravisantoshgudimetla, runcom The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Still seeing ci problems: /retest |
|
/retest |
The purpose of this change was to make masters able to run workloads by default. This is needed to complete a successful deployment of a 3-node bare metal install. This particular approach was only short term, while better interfaces were developed to control this behavior. The scheduler configuration resource now includes a "mastersSchedulable" boolean, enabled here: openshift#937 This installer PR made it the default behavior if no workers were defined at install time: openshift/installer#2004 With these changes in place, the custom kubelet config for the baremetal platform is no longer necessary.
- What I did
Added logic in node controller to watch for scheduler CR changes and update the master nodes to make them schedulable and unschedulable
- How to verify it
I did not test it. I want to check if the approach seems reasonable before I proceed further. Please review the c82786dThe e2e test verifies if the worker label has been added and master taint has been removed for all the masters when scheduler CR's
mastersSchedulablefield has been set or unset. That field was added to Scheduler CRD here openshift/api#366- Description for the changelog