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

[kong] add support for watch-namespace #79

Merged
merged 4 commits into from
Mar 23, 2020

Conversation

wopol
Copy link
Contributor

@wopol wopol commented Mar 19, 2020

Adding support for watch-namespace in chart

@CLAassistant
Copy link

CLAassistant commented Mar 19, 2020

CLA assistant check
All committers have signed the CLA.

@hbagdi
Copy link
Member

hbagdi commented Mar 20, 2020

Can you change this to instead inject arbitrary CLI arguments to the controller?
Something along the lines of taking in an array of strings and passing it verbatim to the controller.

We need to do this to make it easy enough for folks to override other properties via CLI flags.

@wopol
Copy link
Contributor Author

wopol commented Mar 20, 2020

Yes, i can do this. Did you mean something like that?

ingressController:
  installCRDs: false
  ingressClass: myClass
  rbac:
    create: false
  serviceAccount:
    create: false
    name: sa-name
  args:
    - --watch-namespace=namespace-name
    - --other-arg=value

And one more question. What with hardcoded arguments in kong.controller-container function like admin-tls-skip-verify, --admission-webhook-listen etc. Should these arguments stay there?

@hbagdi
Copy link
Member

hbagdi commented Mar 20, 2020

Should these arguments stay there?

No. Let's move them over to the values.yaml file as well so that a user can change them, if needed.

@wopol
Copy link
Contributor Author

wopol commented Mar 20, 2020

Should these arguments stay there?

No. Let's move them over to the values.yaml file as well so that a user can change them, if needed.

Now this is a little bit more complicated, but we have all default arguments and we can replace them when we define the same argument in args Map.

@hbagdi
Copy link
Member

hbagdi commented Mar 20, 2020

Now this is a little bit more complicated, but we have all default arguments and we can replace them when we define the same argument in args Map.

In values.yaml, we can simply add and keep this simple:

ingressController
  args:
  - --flag=value1
  - --bolean-flag
  - --flag2=value2

Users can inject any flag and edit the default as well.

@wopol
Copy link
Contributor Author

wopol commented Mar 20, 2020

Now this is a little bit more complicated, but we have all default arguments and we can replace them when we define the same argument in args Map.

In values.yaml, we can simply add and keep this simple:

ingressController
  args:
  - --flag=value1
  - --bolean-flag
  - --flag2=value2

Users can inject any flag and edit the default as well.

I prefer simple solution but what if someone use arguments like that:

ingressController:
  ingressClass: other-class
  args:
    - --ingress-class=class-name
    - --publish-service=name

Which values should have higher priority for --ingress-class ingressController.ingressClass or ingressController.args[0] ?
Which values should have higher priority for --publish-service ingressController.args[1] or {{ .Release.Namespace }}/{{ template "kong.fullname" . }}-proxy

@hbagdi
Copy link
Member

hbagdi commented Mar 20, 2020

Which values should have higher priority for --ingress-class ingressController.ingressClass or ingressController.args[0] ?

Specifying via args should have a higher priority.

Some background:
We do want to add arg based approach, but we will recommend using environment variables for all configuration changes, especially to these ones that are already supported by environment variables.

Only logging based variables are not yet supported by environment variables, which is why we want to merge this PR in.
Flag/env should take precedence over specifying the value directly using a chart variable, like ingressClass.

@wopol
Copy link
Contributor Author

wopol commented Mar 20, 2020

Only logging based variables are not yet supported by environment variables, which is why we want to merge this PR in.
Flag/env should take precedence over specifying the value directly using a chart variable, like ingressClass.

This will be more difficulty and less readable to check if in args array exist some key when not exist generate default e.g election-id=kong-ingress-controller-leader-{{ .Values.ingressController.ingressClass }}
I will try to do it.

{{- else }}
- --kong-url=http://localhost:{{ .Values.admin.containerPort }}
{{- end }}
{{- if .Values.ingressController.admissionWebhook.enabled }}
- --admission-webhook-listen=0.0.0.0:{{ .Values.ingressController.admissionWebhook.port }}
{{- end }}


Copy link
Member

Choose a reason for hiding this comment

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

Please remove these line jumps.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@hbagdi hbagdi requested a review from rainest March 20, 2020 20:20
@hbagdi
Copy link
Member

hbagdi commented Mar 20, 2020

This looks good to me since going forward, users should add CLI args only for logging related settings.
The existing CLI flags will be moved over to environment variables after controller 0.8 is released, and we already have good amount of code on how to set precedence there.
@rainest thoughts?

@rainest
Copy link
Contributor

rainest commented Mar 20, 2020

@hbagdi you mean migrate kong.ingressController.env to something like kong.env's dict-based deduplication system and handle all defaults via environment variables? That seems reasonable.

Post-0.8 is there any reason you'd still use CLI arguments over their equivalent variable? It almost seems like it'd make more sense to wait and have users use environment variables only, since we wouldn't have any means of avoiding conflicts between envvar/CLI settings.

@hbagdi
Copy link
Member

hbagdi commented Mar 20, 2020

dict-based deduplication system and handle all defaults via environment variables?

Yes.

Post-0.8 is there any reason you'd still use CLI arguments over their equivalent variable? It almost seems like it'd make more sense to wait and have users use environment variables only, since we wouldn't have any means of avoiding conflicts between envvar/CLI settings.

Yes, because Kong/kubernetes-ingress-controller#506.
Hence, the comment on logging CLI args only. Everything else will move to env vars.
We should move logging CLI args to env vars as well but that's not a priority (for me at least).

rainest
rainest previously approved these changes Mar 20, 2020
Copy link
Contributor

@rainest rainest left a comment

Choose a reason for hiding this comment

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

Ah, okay, I thought 0.8 was going to add support also.

Copy link
Member

@hbagdi hbagdi left a comment

Choose a reason for hiding this comment

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

This is looking good and we would like to merge it in.
Please also add a test case to an existing test (don't add another test file as it puts pressure on the CI).
Add a harmless argument like --ingress-class=test-kong or something like that. A logging arg would be even better. Full list here: https://github.com/Kong/kubernetes-ingress-controller/blob/master/docs/references/cli-arguments.md.

Thank you for pushing through this even though the purpose of the PR changed significantly.

- [Prerequisites](#prerequisites-1)
- [Kong Enterprise License](#kong-enterprise-license)
- [Kong Enterprise Docker registry access](#kong-enterprise-docker-registry-access)
- [Service location hints](#service-location-hints)
- [RBAC](#rbac)
- [Sessions](#sessions)
- [Email/SMTP](#emailsmtp)
- [Changelog](https://github.com/Kong/charts/blob/master/charts/kong/CHANGELOG.md)
- [Seeking help](#seeking-help)
Copy link
Member

Choose a reason for hiding this comment

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

Please remove changes to this table.

@@ -276,6 +283,7 @@ section of `values.yaml` file:
| installCRDs | Create CRDs. Regardless of value of this, Helm v3+ will install the CRDs if those are not present already. Use `--skip-crds` with `helm install` if you want to skip CRD creation. | true |
| env | Specify Kong Ingress Controller configuration via environment variables | |
| ingressClass | The ingress-class value for controller | kong |
| args | Map of ingress-controller cli arguments | {} |
Copy link
Member

Choose a reason for hiding this comment

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

The description is outdated. It should be an array and not a map.

@@ -191,6 +191,7 @@ ingressController:
image:
repository: kong-docker-kubernetes-ingress-controller.bintray.io/kong-ingress-controller
tag: 0.7.1
args:
Copy link
Member

Choose a reason for hiding this comment

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

Please initialize with an empty array [] to set the user expectation that this is an array.

@wopol wopol requested a review from hbagdi March 21, 2020 11:55
@hbagdi
Copy link
Member

hbagdi commented Apr 22, 2020

@wopol Thank you for your contribution. Please fill in the contributor form to claim your Kong swag: https://github.com/Kong/kong/blob/master/CONTRIBUTING.md#contributor-t-shirt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants