-
Notifications
You must be signed in to change notification settings - Fork 77
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
Add option to use networking.k8s.io/v1beta1 ingresses #945
Add option to use networking.k8s.io/v1beta1 ingresses #945
Conversation
[CHATOPS:HELP] ChatOps commands.
|
charts/vald/values.yaml
Outdated
@@ -995,6 +995,9 @@ gateway: | |||
# @schema {"name": "gateway.vald.ingress.servicePort", "type": "string"} | |||
# gateway.vald.ingress.servicePort -- service port to be exposed by ingress | |||
servicePort: grpc | |||
# @schema {"name": "gateway.vald.ingress.usev1beta1", "type": "boolean"} | |||
# gateway.vald.ingress.usev1beta1 -- use networking.k8s.io/v1beta1 instead of v1 | |||
usev1beta1: false |
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.
Currently the default value is false
. what do you think about 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.
I think it's okay, and we should add comment if k8s 1.22 released it would be better to remove this option
I am thinking the same issue may happen in later k8s also, maybe we can let user to choose which version to use in other k8s resources also. |
how about define vald wide api version definition list in the charts's defaults section like
and use it
and users can easy to overwrite specification by helm's but if some api version breaks backward compatibility we have to add logical section. |
I starting thinking we should manage k8s manifest by version |
yes we should care about it, cuz we provide helm charts for user usually charts provider maintains k8s apiVersion. |
I think it's not a good idea to allow users to edit api-versions through values.yaml. If the users want to edit them, they should use |
Maybe we should define required version of K8s for each version of the charts. |
I think that specifying apiVersion from values.yaml and implementing conditional branching with usev1beta1 are not so different in maintenance cost, is there any other cost that I am not considering? |
But, as you mentioned, we shouldn't support backward compatibility about api version. in this document which said helm automatically resolves api version which suitable for current k8s context cluster version. |
that's right. I thought this PR is just for temporary workaround for the problem that is happened in our dev cluster. |
I understand that this pull request will be used as a temporary workaround. |
How about this approach? |
@kevindiu we can't do that, helm operator will apply everything that he made. |
In the private chat, Kpango said that it is enough to prepare |
okay, and I opened new issue #946 about this pr's problems. |
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
Description:
usev1beta1
option to use networking.k8s.io/v1beta1 version of ingresses.Related Issue:
Nothing
How Has This Been Tested?:
Nothing
Environment:
Types of changes:
Changes to Core Features:
Checklist: