Open landism opened 2 years ago
IMO, the big reason to use an ingress in dev is to have hostname-based or pathname-based traffic routing to multiple resources. (Ingress is an HTTP-level traffic balancer, whereas Service is a TCP-level traffic balancer). So I'm not sure there's much value in resolving the ingress's IP. But could be lots of value in resolving the ingress' traffic router for hostnames/paths.
One thing that I've always wanted is to have Tilt help you set up hostnames in dev (rather than using random port numbers)
But I flipflop back and forth between whether tilt should teach you how to setup an ingress, and proscribe a very opinionated workflow that works with Tilt. Or if it should auto-infer hostnames and pathnames from any ingresses you create. Or some combination of both.
I love the idea of an opinionated ingress with TLS support built-in and vhost functionality. I've wondered if we should create a DNS record for local.tilt.dev -> 127.0.0.1, then we could have vhosts like
In our setup we are running a CoreDNS server locally to resolve all the hostnames used by the ingress. Having Tilt to auto-infer the hostnames from ingresses created would be a nice feature.
Describe the Feature You Want
k8s_resource
and friends can define links on a resource. These links have to be resolved during Tiltfile execution. If the Tiltfile is also responsible for instructing Tilt to create an ingress, then it's not possible to resolve a link to that ingress since the ingress doesn't yet exist.Current Behavior
One can write a Tiltfile that checks if the ingress exists and has an ip, and if so, add the link to the resource. Then, define a separate
local_resource
that runstilt trigger '(Tiltfile)'
when the ingress exists or its ip changes. Alternatively, one can define a link to a port forward, which I suspect is what most users do, but then they're not exercising their ingress while developing.