-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Cleanup after #8855 #8846
Cleanup after #8855 #8846
Conversation
2b8e299
to
9580e39
Compare
With this PR what exactly will happen if a user specifies one of the impacted docker versions in the cluster manifest? Will nodeup fallback to the new default docker version of 17.03.2? Should we add some api-level validation, so that a |
@rifelpet I think it will install 17.03.2, this is what I saw happening in the past when the Docker version was not found by NodeUp. |
9580e39
to
efc89bc
Compare
Validation for Docker versions is now added. Thanks for the idea @rifelpet. |
/retest |
nodeup/pkg/model/docker.go
Outdated
@@ -43,270 +43,9 @@ var _ fi.ModelBuilder = &DockerBuilder{} | |||
|
|||
// DefaultDockerVersion is the (legacy) docker version we use if one is not specified in the manifest. | |||
// We don't change this with each version of kops, we expect newer versions of kops to populate the field. | |||
const DefaultDockerVersion = "1.12.3" | |||
const DefaultDockerVersion = "17.03.2" |
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.
Might be better to instead require a value in the manifest.
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 is used as a fallback when the dirstro or arch is not listed. For example, if anyone chooses to use a Debian Jessie based image with latest Docker, NodeUp will not find it and use this.
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.
How does that work? I only see this referenced from the dockerVersion()
receiver of DockerBuilder
, when Cluster.Spec.Docker.Version
is not specified.
It seems odd to be updating a field to the oldest version we can. The comment suggests it's a backwards-compatibility strategy that is never supposed to be updated.
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 looked at the code and I also don't see any other reference. It is used just if the version doesn't exist as you also noticed.
This is a very old piece of code that exists since the beginnings. No idea why it was needed then and why we still keep it. At this point there should always be a Docker version.
kops/pkg/model/components/docker.go
Lines 50 to 62 in 62c5100
if fi.StringValue(clusterSpec.Docker.Version) == "" { | |
if b.IsKubernetesGTE("1.18") { | |
docker.Version = fi.String("19.03.8") | |
} else if b.IsKubernetesGTE("1.17") { | |
docker.Version = fi.String("19.03.4") | |
} else if b.IsKubernetesGTE("1.16") { | |
docker.Version = fi.String("18.09.9") | |
} else if b.IsKubernetesGTE("1.12") { | |
docker.Version = fi.String("18.06.3") | |
} else { | |
docker.Version = fi.String("17.03.2") | |
} | |
} |
The only explanation I have is this, since containerd support was added: #7986 (comment).
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, the components/docker.go
code that presumably ensures the field is set was added in the same commit that adds DefaultDockerVersion
. @justinsb would have the context.
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 is indeed very very old. The kops CLI is supposed to populate the docker version in the "expanded" form of the cluster spec (the one you can see with --full
). When it was first introduced, we didn't lock nodeup to the kops version, and so there was the risk of skew. To tolerate that, we introduced a default docker version that nodeup would use, when kops didn't populate it.
At this point, it's probably easier to remove the nodeup defaulting entirely - just skip installing docker if isn't populated, I would suggest (with a warning so we can figure out what happened!).
3c4d875
to
726c7ce
Compare
nodeup/pkg/model/docker.go
Outdated
@@ -43,270 +43,9 @@ var _ fi.ModelBuilder = &DockerBuilder{} | |||
|
|||
// DefaultDockerVersion is the (legacy) docker version we use if one is not specified in the manifest. | |||
// We don't change this with each version of kops, we expect newer versions of kops to populate the field. | |||
const DefaultDockerVersion = "1.12.3" | |||
const DefaultDockerVersion = "17.03.2" |
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 is indeed very very old. The kops CLI is supposed to populate the docker version in the "expanded" form of the cluster spec (the one you can see with --full
). When it was first introduced, we didn't lock nodeup to the kops version, and so there was the risk of skew. To tolerate that, we introduced a default docker version that nodeup would use, when kops didn't populate it.
At this point, it's probably easier to remove the nodeup defaulting entirely - just skip installing docker if isn't populated, I would suggest (with a warning so we can figure out what happened!).
|
||
if config.Version != nil { | ||
valid := []string{"17.03.2", "17.09.0", "18.03.1", "18.06.1", "18.06.2", "18.06.3", "18.09.3", "18.09.9", "19.03.4", "19.03.8"} | ||
allErrs = append(allErrs, IsValidValue(fldPath.Child("version"), config.Version, valid)...) |
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 validation is the critical thing to backport, I believe. (I think the others might have a higher risk of collisions).
Should we split this out into its own commit that we cherry-pick back? And I'm wondering whether it's easier just to exclude the known-bad versions (1.11, 1.12 etc) with an explicit "docker removed these versions" message... Technically I guess it doesn't really matter if we let through 19.03.8 on an older version that doesn't support it - we're no worse off than we are today.
Thanks for doing this @hakman . On the cherry-pick, I think the critical thing to cherry pick is a warning/error about the no-longer available docker versions; so I suggested splitting that into its own PR. Removal of the mappings to URLs is internal machinery and so less important to cherry-pick I suggest, and I worry that there has been some changes there that might make it harder to cherry-pick. |
Thanks @justinsb. I create a new PR that can be easily cherry-picked and will update this to remove default Docker version. |
89d380a
to
3471155
Compare
3471155
to
3851a41
Compare
Thanks for splitting this out - looks great @hakman /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hakman, justinsb 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 |
Thanks @justinsb. Will take care of the cherry-picks for Kops 1.16 and 1.17. |
The repo containing the binaries for Docker 1.11, 1.12 and 1.13 was shut down on March 31. This means support for older docker versions cannot be maintained.
https://www.docker.com/blog/changes-dockerproject-org-apt-yum-repositories/
This PR will need to be cherry-picked to 1.16+.