Skip to content
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

Merged
merged 2 commits into from
May 11, 2020
Merged

Conversation

MOZGIII
Copy link
Contributor

@MOZGIII MOZGIII commented Apr 30, 2020

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.

Signed-off-by: MOZGIII <mike-n@narod.ru>
@MOZGIII MOZGIII self-assigned this Apr 30, 2020
@binarylogic
Copy link
Contributor

Thanks.

I think this format is the best fit, since the supported versions aren't really a part of the installation domain.

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?

@MOZGIII
Copy link
Contributor Author

MOZGIII commented Apr 30, 2020

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 1.14, but not specify it in the installation docs until we deliver. Similarly - if we change MSKV to 1.10 for example - we only change the version we specify at the installation docs once the code is implemented and the release supporting 1.10 is ready.

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.

@binarylogic
Copy link
Contributor

Yeah, that is the point of the .meta/installation/* files. Using the installation namespace isn't necessary and clearly just confuses things. Your file is fine, can you add it under a supported_versions table though?

@MOZGIII
Copy link
Contributor Author

MOZGIII commented Apr 30, 2020

@binarylogic can you take over this PR and apply changes you see fit? 😄
I don't think I understood what you mean (I see multiple competing interpretations), but it's probably quicker if you just do it.

@@ -0,0 +1,7 @@
# This file holds generic specification of version constraints of the third-pary
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# 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?

@binarylogic binarylogic merged commit 2340457 into master May 11, 2020
@binarylogic binarylogic deleted the k8s-initial-mskv branch May 11, 2020 14:42
mengesb pushed a commit to jacobbraaten/vector that referenced this pull request Dec 9, 2020
Signed-off-by: Brian Menges <brian.menges@anaplan.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants