Ah, I think I see now - the user needs to tell the outside world a DNS name, and they need to point that DNS name to the K8s ingress controller, and when the traffic arrives, ingres needs to know that the traffic is supposed to go to this particular service.
Still, I think we could do better.
First, I think it’s tasteless that we use juju- as a prefix on things for no good reason. It results in output that looks bad. When you look at your instance names in a cloud and its a mess of juju, it doesn’t create a positive impression. Why did this need to be juju-external-name?
Second, as you started to explore, I think we can make the DNS process more deliberate and designed, rather than requiring human interaction. We have app-name and model-name as keys that can be used in a DNS string, for example. If DNS is a key part of networking (it is) then Juju should have a designed and deliberate approach to it, which is zero-touch y default but can easily be tailored. For example, Juju could default to xip.io names unless you provide a custom one (meaning, you don’t have to provide a name for it to work). Juju could provide DNS itself, so this becomes app.model.controller-uid.local (but with some plan for how that’s useful).
Just falling back on ‘the human will do it manually every time’ is the anti-pattern I am asking us to avoid.