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: support any Linux kernel version newer than 3.10 #81623
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: neolit123 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
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.
just a quick question
@@ -30,7 +30,7 @@ const dockerEndpoint = "unix:///var/run/docker.sock" | |||
var DefaultSysSpec = SysSpec{ | |||
OS: "Linux", | |||
KernelSpec: KernelSpec{ | |||
Versions: []string{`3\.[1-9][0-9].*`, `4\..*`, `5\..*`}, // Requires 3.10+, 4+ or 5+ | |||
Versions: []string{`3\.[1-9][0-9].*`, `[4-99]\..*`}, // Requires 3.10+, or newer |
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.
should this and the other regex just be defined in one place instead of both meaning we have to copy and paste it wherever we want it? can we make it a package const or something?
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.
can be done, but while this regex should hold the actual values, the other one can have any values, as it's just a test.
if we have more votes for this i can update it.
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.
@neolit123 - if we need always to change both at the same, it seems reasonable to have const for this package
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.
If versions between 4.x and 99.x is what you desire, then [4-99]\..*
is pretty wrong. This one should do the trick in that case:
[4-9]\..*|[1-9][0-9]\..*
And let's hope we don't get Linux 99.x soon.
P.S. Any version >= 4.x is going to be [4-9]\..*|[1-9][0-9]*\..*
, then Linux 999.x would be OK too.
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.
Any version >= 4.x is going to be [4-9]..|[1-9][0-9]..*, then Linux 999.x would be OK too.
ok, i will give this a test.
And let's hope we don't get Linux 99.x soon.
i think i calculated roughly 25 more years of Linux kernels with the current cadence until we reach 99.x
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.
+1
[4-99]
would match the 4-9 range and 9
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.
updated with the correct regexp, also there was a bug in the old regexp for 3* versions :)
i kept the regexp between _unix and the test file duplicated.
the correct thing to do is to introduce separate _windows and _unix unit tests that test the different OS kernel versions, but i don't wish to add this as part of this PR.
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.
0aeff32
to
1936cc3
Compare
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
It seems undesirable that Kubernetes as a system should be blocking a node if it's Linux kernel is way too new. If such a problem even occurs we should exclude versions from the list of supported versions instead of blocking users from trying e.g. the latest 7.0.0-beta kernel because our validators are not aware of this new version.
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.
What about 10.21.1
?
/hold
I think, that |
it works, thanks. |
1936cc3
to
bec9c36
Compare
@rosti done, updated |
|
/retest |
/lgtm |
What this PR does / why we need it:
It seems undesirable that Kubernetes as a system should be
blocking a node if it's Linux kernel is way too new.
If such a problem even occurs we should exclude versions from
the list of supported versions instead of blocking users
from trying e.g. the latest 7.0.0-beta kernel because our
validators are not aware of this new version yet.
Which issue(s) this PR fixes:
NONE
Special notes for your reviewer:
NONE
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
/kind cleanup
/priority important-longterm
/assign @rosti @yastij