templating for public and passthrough gateways

Context:

Operatorless Istio Gateway(s) and BB Helm Templating :thread:

Istio historically offered two different charts gateways/istio-ingress and gateways/istio-egress both of which are now legacy and are replaced by the current upstream gateway chart we are tracking in istio-gateway.
The current design of Operatorless Istio provides two top-level BB packages for configuration:

• istio (currently named istio3 until release)
• istioGateway The two main issues here are:
• the only OFFICIALLY supported method of deploying istio is via the istioctl cli and we cannot change this (helm charts although offered are not officially supported) ✅
• each istio gateway that we wish to deploy in BB requires a separate gateway chart instantiation since the chart itself handles only a single gateway ❓
  So, for the latter issue, there are several possible solutions to this problem:

1. continue with the current istio and istioGateway top level configurations declaring 1..X gateways under istioGateway.gateways which itself will follow a pattern that BB has not used elsewhere... specifically: rolling out multiple Helm Releases in a single BB template -- this itself has the limitation of passing down values to each specific gateway helm release

• discussions with overcoming this limitation with @luis.gomez_gonzalez.3 and @jbourque seem to conclude that we pass down values to the individual HRs via postRenderers
• is there another method to handle passing down gateway configuration values to multiple HRs inside a single BB template that is less hacky than using postRenderers?

2. an alternate solution albeit another not previously established BB helm templating pattern would be to recognize that we officially support exactly 1 or 2 gateways by design:

• this is inline with maintaining feature parity with the current Operator method for istio in BB
• the istioGateway helm template gets renamed to istioIngressPublic handling the public ingress gateway use case
• a new istioIngressPassthrough helm template is added which handles the passthrough ingress gateway for Keycloak and other packages that require this type of gateway
• the configuration for each of these 2 gateway packages can be handled at the top level istio package -- these two packages will not be enabled/disabled or configured as normal BB packages are with their own top level package configuration -- these two packages self-enable via templating logic when the top level istio package is enabled and parse out their own configs from istio.gateways -- this approach lends to a simplified configuration under a single BB package although the helm magic of coordinating 3 individual packages is hidden to the normal BB consumer
• additional gateways can be added via the wrapper class -- which we will document

3. @jbourque had the idea that perhaps we should instead deploy gateways via istioctl from inside a cluster pod as is done similarly to how twistlock uses kubectl from inside a cluster pod to handle some resources

• this approach at first glance seems more complicated and may require additional development time
• it may ultimately be the most elegant solution Having worked on this problem for some time, I am in favor of solution #2 (closed) ... but, I'd like to get feedback from other SM members and the anchors.

More:

See the full discussion here

Recap:

This story tracks the progress of implementation for number 2 above.