feat(helm): Allow supplying custom configmap

[Demonsthere]

What type of PR is this?

• feature

What this PR does / why we need it: This PR allows 2 thing:

1. Change the name of the envoy-gateway cm using an override
2. Allow the control of creating this cm

Those 2 options allow us to supply our own configmap, as well as keep the current schema of deploying it by default. This way one can disable the default config and sideload it when using this as a subchart

Which issue(s) this PR fixes:

Fixes #

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 66.54%. Comparing base (9416798) to head (9965ed9). Report is 556 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2723   +/-   ##
=======================================
  Coverage   66.54%   66.54%           
=======================================
  Files         157      157           
  Lines       21956    21956           
=======================================
  Hits        14611    14611           
  Misses       6502     6502           
  Partials      843      843           

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[shahar-h]

Any progress with this? We are also interested in this feature.

[arkodg]

@shahar-h couldn't you input the same intent directly via Values.yaml ?

[shahar-h]

@arkodg in our case extensionManager.service.host represents a kubernetes service host - <service-name>.<namespace>.svc.cluster.local, and since the namespace part is dynamic according to chart installation command we need to have an option to make it templated. In case we have an option to provide our own configmap we can achieve that.

[arkodg]

@arkodg in our case extensionManager.service.host represents a kubernetes service host - <service-name>.<namespace>.svc.cluster.local, and since the namespace part is dynamic according to chart installation command we need to have an option to make it templated. In case we have an option to provide our own configmap we can achieve that.

since you are supplying the namespace in the helm command, could you also supply the same value to the values field, i.e. your helm cmd invocation is templated which seems like the common case, but the namespace will change ? im trying to see if we can avoid this, but if not, lets find the right UX and get this in

[shahar-h]

@arkodg in our case extensionManager.service.host represents a kubernetes service host - <service-name>.<namespace>.svc.cluster.local, and since the namespace part is dynamic according to chart installation command we need to have an option to make it templated. In case we have an option to provide our own configmap we can achieve that.

since you are supplying the namespace in the helm command, could you also supply the same value to the values field, i.e. your helm cmd invocation is templated which seems like the common case, but the namespace will change ? im trying to see if we can avoid this, but if not, lets find the right UX and get this in

I could send it from external chart values but this means that I need to send the whole service host, which means that I need to know the internal service name, which I want to avoid.

[arkodg]

@arkodg in our case extensionManager.service.host represents a kubernetes service host - <service-name>.<namespace>.svc.cluster.local, and since the namespace part is dynamic according to chart installation command we need to have an option to make it templated. In case we have an option to provide our own configmap we can achieve that.

since you are supplying the namespace in the helm command, could you also supply the same value to the values field, i.e. your helm cmd invocation is templated which seems like the common case, but the namespace will change ? im trying to see if we can avoid this, but if not, lets find the right UX and get this in

I could send it from external chart values but this means that I need to send the whole service host, which means that I need to know the internal service name, which I want to avoid.

sounds like to want the ConfigMap to be a template in other Helm Chart ? If this is the case, you'll need to enforce order to make sure the ConfigMap exists before Envoy Gateway Helm Chart kicks in

[shahar-h]

I want the configmap to be installed as a template of a EG wrapper helm chart. Regarding the installation order, configmap is installed Before deployment(see https://helm.sh/docs/intro/using_helm/) so there is no issue here.

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, when it's ready. Thank you for your contributions!

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, when it's ready. Thank you for your contributions!

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, when it's ready. Thank you for your contributions!

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, when it's ready. Thank you for your contributions!

[guydc]

cc @arkodg - WDYT?

[arkodg]

cc @arkodg - WDYT?

the use case of supplying an external configmap makes sense, can we brainstorm a little more on the API for e.g. thoughts on

config:
  .......
  customConfigMap: <blah>