Open joelmccoy opened 1 week ago
I think I may advocate for the listed alternative:
Deploying a custom Istio Ingress and not use the UDS Package CR to create the virtual services and netpols
Unless there is a clear ask for multi-domain support from a significant portion of our user-base, this feels like a potential one-off that we could support building out as conditional manifests in the Marketplace package. It would still run on core and benefit from pieces of core integration, but would require gateway, virtualservice, and network policy to be defined and deployed with the marketplace package.
Alternatively we could bite off parts of this, as @joelmccoy noted synchronously one thing we could support in the operator would be allowing use of additional gateways, specifically for expose
entries in the Package
CR. Core wouldn't necessarily create/manage additional Gateway
resources, but could allow them to be used via expose
. This would effectively reduce the number of resources needed for this from 3 (Gateway, VS, NetPol) to 1 (Gateway). Would have to lean more into validations and pepr looking up existing gateways, but it's overall not too complex to support.
Is your feature request related to a problem? Please describe.
Currently I don't have a method to host UDS Packages under multiple domains on a single uds-core cluster. I would like to be able to host
UDS_PACKAGE_1
underapp.domain1.com
andUDS_PACKAGE_2
underapp.domain2.com
using the native package CRD.This ask is coming from this issue: https://github.com/defenseunicorns/uds-marketplace/issues/204
Describe the solution you'd like
Describe alternatives you've considered
Additional context
I see two paths forward for implementation that would be satisfactory:
Allow the Istio Tenant and Admin Gateway to support multiple domains
*.domain1.com
and*.domain2.com
Add UDS Package Operator support for another gateway