audit kgateway helm install UX

[lgadban]

• CRD installation
  • Separate CRD chart?
• What installs the default GW?
  • As I mentioned before I think there are major long term UX trade-offs to include it in the templating in the chart directly. ~ @josh-pritchard
• Revisit default GW Params
  • IMO you should never need this by default. It should be for overrides and customization. The fact that all of that is required in the CR right now shows me the feature was probably originally rushed. ~ @josh-pritchard
• Audit helm values

[timflannagan]

+1 on removing the need for default GW Params object.

re:default GW. @josh-pritchard do you remember the concerns you had in this approach (vs. having the controller roll it out for us?).

[lgadban]

+1 on removing the need for default GW Params object.

I'm also a heavy +1 on this, but it will require a lot more work than the other items called out.
The internal helm chart for dynamic resources and the deployer semantics will need to be revisited entirely to break this out.
To be clear, I think it is worth it, but the timing will be difficult for 2.0.0 at least.

re:default GW. @josh-pritchard do you remember the concerns you had in this approach (vs. having the controller roll it out for us?).

I am also in favor of this, my reasons are:

• not installing via helm is one less cluster-scoped resource installed, which means we can explore namespaced installs for niche use-cases

Other reasons I can recall being mentioned:

• we need to effectively recreate the GwClass API in helm if we install it via helm
  • IMO this reasoning is a bit flimsy
• If users modify it after the fact in cluster, there is no reconciliation and will be blown away by e.g. helm upgrade

[jenshu]

re: default gatewayparameters, if we keep it in the chart, we should revisit how it is linked to the gatewayclass and which fields you can override. does it have to exist in the install namespace?

see a previous bug that was uncovered with hardcoded namespace #10653