[Spike] Explore iterable gateway configuration

Motivation

Currently the operatorless istio sandbox has gateway configuration split out into separate template directories. This leads to some measure of repeated code. In order to DRY this up, we should explore using an iterable object to create gateway HelmReleases and its dependencies

Acceptance Criteria

• A detailed account of the trade-offs between approaches must be commented to this issue
• A branch with an example configuration must be linked in this issue
• A discussion with SM team and anchors about which approach to go with must be had and decision documented on this issue

added to epic &352 (closed)

set weight to 2

added istio kindenhancement priority5 teamService Mesh labels

changed title from Explore iterable gateway configuration to [Spike] Explore iterable gateway configuration

changed the description

assigned to @zcallahan

changed epic to &393

Punted this to epic 2 since it is not blocking the completion of epic 1.

Trade-Offs between iterable gateways and static gateway "packages."

Iterable Gateways

Strengths

• Easy for a customer to duplicate to make custom gateways
  • Just add a new key in the values
• Singular git config for all gateways
• Works for egress and ingress gateways at the same time
• DRY

Weaknesses

• Templating is more complicated than normal packages (HelmReleases and values Secrets)
• In the event the big bang consumer wants different versions for different gateways, iterable gateways are incompatible

Static Gateways

Strengths

• Simpler templating (standard big bang package templating)
• Can pin different gateways to different chart versions

Weaknesses

• Requires consumers to use the wrapper for custom gateways (egress and ingress)
• Necessitates some code duplication

marked the checklist item A detailed account of the trade-offs between approaches must be commented to this issue as completed

Implementation branch: https://repo1.dso.mil/big-bang/bigbang/-/tree/istio-iterable-gateways/chart/templates/istio3-gateways?ref_type=heads

marked the checklist item A branch with an example configuration must be linked in this issue as completed

marked the checklist item A discussion with SM team and anchors about which approach to go with must be had and decision documented on this issue as completed

After discussing with the team during our sprint retro, we decided to go forward with this approach. I'll create issues to facilitate that and link back to this issue.

added statusreview label

closed

mentioned in issue #2507 (closed)

removed statusreview label