It would be very beneficial to supply extraManifests value to the emissary-ingress Helm chart that would render extra manifests as a part of a single Helm chart deployment.
Describe the solution you'd like
An extra variable to hold a list of arbitrary Kubernetes manifests, e.g.
## Extra manifests to deploy as an array
extraManifests: []
# - apiVersion: elbv2.k8s.aws/v1beta1
# kind: TargetGroupBinding
# metadata:
# name: internal-emissary-ingress
# spec:
# serviceRef:
# name: internal-emissary-ingress
# port: 80
# targetGroupARN: <target group arn>
Describe alternatives you've considered
Building a Helm chart wrapper to include emissary-ingress Helm chart as a subchart.
Using Kustomize with overlays.
Deploying the extra manifests in a separate Helm chart / Kustomize overlay.
The (1) & (2) are hard to maintain and scale, the (3) introduces the dependency between deployments which requires putting the stuff in correct order.
Additional context
This has been a normal practise and a lot of OSS Helm charts support such options these days, e.g.
Please describe your use case / problem.
It would be very beneficial to supply
extraManifestsvalue to theemissary-ingressHelm chart that would render extra manifests as a part of a single Helm chart deployment.Describe the solution you'd like
An extra variable to hold a list of arbitrary Kubernetes manifests, e.g.
Describe alternatives you've considered
emissary-ingressHelm chart as a subchart.The (1) & (2) are hard to maintain and scale, the (3) introduces the dependency between deployments which requires putting the stuff in correct order.
Additional context
This has been a normal practise and a lot of OSS Helm charts support such options these days, e.g.
I'm willing to implement this feature.