-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
[kubeadm] Pass features gates to components #2037
Conversation
539e3ef
to
11c9318
Compare
Codecov Report
@@ Coverage Diff @@
## master #2037 +/- ##
==========================================
+ Coverage 28.59% 29.06% +0.47%
==========================================
Files 80 81 +1
Lines 5243 5288 +45
==========================================
+ Hits 1499 1537 +38
- Misses 3551 3558 +7
Partials 193 193
Continue to review full report at Codecov.
|
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.
Looks basically fine, the tests seem a little verbose though.
api: | ||
advertiseAddress: 192.168.1.101 | ||
bindPort: 8443 | ||
kubernetesVersion: v1.8.0-alpha.0 |
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.
The hardcoded versions here seem like they'd make these tests pretty brittle, can we get away without having this much boilerplate checked in?
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.
The versions are passed in on line 167 so they won't change. The "expectedCfg" is generated entirely from the bootstrapper.KubernetesConfig object
for k := range componentToKubeadmConfigKey { | ||
keys = append(keys, k) | ||
} | ||
sort.Strings(keys) |
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.
Why do we need this sort? Keys should be unique, and it looks like we collect the result sinto another map (extraConfig).
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.
The extraConfig is only an intermediary map that eventually gets passed to kubeadmExtraArgs, a slice.
I think I did this because a slice of []ComponentExtraArgs is passed to the template
type ComponentExtraArgs struct {
Component string
Options map[string]string
}
For tests, we want to write the slice in alphabetical order according to components, and then for each component, write the options in alphabetical order.
I agree this whole construction is a bit suspect, so any refactoring ideas would be appreciated.
11c9318
to
dd50d76
Compare
Passes feature gates properly to apiserver, scheduler, controller-manager, and kubelet for the kubeadm bootstrapper.