Skip to content

chore: Set minimal supported Kubernetes version#2510

Merged
binarylogic merged 2 commits into
masterfrom
k8s-initial-mskv
May 11, 2020
Merged

chore: Set minimal supported Kubernetes version#2510
binarylogic merged 2 commits into
masterfrom
k8s-initial-mskv

Conversation

@MOZGIII

@MOZGIII MOZGIII commented Apr 30, 2020

Copy link
Copy Markdown
Contributor

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 requested a review from binarylogic April 30, 2020 16:49
@MOZGIII MOZGIII self-assigned this Apr 30, 2020
@binarylogic

Copy link
Copy Markdown
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

MOZGIII commented Apr 30, 2020

Copy link
Copy Markdown
Contributor Author

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
Copy Markdown
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

MOZGIII commented Apr 30, 2020

Copy link
Copy Markdown
Contributor Author

@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.

Comment thread .meta/supported_versions.toml Outdated
@@ -0,0 +1,7 @@
# This file holds generic specification of version constraints of the third-pary

Copy link
Copy Markdown
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