-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
chore: Set minimal supported Kubernetes version #2510
Conversation
Signed-off-by: MOZGIII <mike-n@narod.ru>
Thanks.
I think it is. Installation is all about supported platforms, etc. Is there a scenario where the version we'd communicate during installation would not align with our supported version? |
To me, the difference is the MSKV is our input parameters for the design, and our installation documentation is the output (i.e. the representation of the current state of things). I.e. we should derive the installation parameters from the supported versions spec. So, I see those as different concerns. And one of the consequences for that would be that we can specify MSKV as If you think it's unnecessary - we can only keep the MSKV at the installation meta. I don't mind, I just want to make sure that the idea behind my approach is communicated properly. |
Yeah, that is the point of the |
@binarylogic can you take over this PR and apply changes you see fit? 😄 |
.meta/supported_versions.toml
Outdated
@@ -0,0 +1,7 @@ | |||
# This file holds generic specification of version constraints of the third-pary |
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 file holds generic specification of version constraints of the third-pary | |
[supported_versions] | |
# This file holds generic specification of version constraints of the third-pary |
@binarylogic like this?
Signed-off-by: Brian Menges <brian.menges@anaplan.com>
Specify the minimal supported Kubernetes version, according to the #2222.
The file location is not set in stone, I'm open to changes.
I think this format is the best fit, since the supported versions aren't really a part of the installation domain.
The proposals at #2222 are conceptual and not concrete - that's by the design of the RFC process. We didn't complete the discussion at #2222, so we can finish it here.