You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
App detail Services tab: show a connection FQDN with configurable domain suffix #3112
Before 1.4.0 the dashboard could show an FQDN to connect to a provisioned service, with a configurable domain suffix (via the old kube-service-details factory) — handy when CoreDNS was tuned to expose external IPs under a separate zone. The new cozystack-ui has no equivalent: no hostname or connection string is shown for LoadBalancer services anywhere. Requested as part of #2789.
Current state
apps/console/src/routes/detail/ServicesTab.tsx shows only cluster-internal fields. A repo search for fqdn / svc.cluster.local / domain-suffix handling finds nothing — there is no FQDN/endpoint mechanism in the new UI. IngressesTab.tsx renders spec.rules[].host for Ingress objects, but that does not cover externally-exposed LoadBalancer services.
Design questions
Where does the domain suffix come from — a platform-level setting, per-tenant config, or user-supplied? The old behaviour was operator-configurable, so the new one needs a source of truth before implementation.
Should the FQDN be derived from the external IP's reverse zone, from a per-service annotation, or composed from a configured suffix + service name?
This is distinct from surfacing the raw LoadBalancer IP (sibling issue), which is a straight wiring fix; the FQDN needs the domain-source decision first.
Taking this off backlog. It has been asked for four times now, twice in this thread and twice in the community chat, and it is the reason at least one operator is still running 1.3.5 rather than moving to the new dashboard.
Nothing has started on the UI side: no issue and no PR in cozystack-ui touches the Services tab for this.
Two things need a decision before any code. Where the suffix comes from, platform config or tenant or a per-app field. And what the tab actually renders, a bare hostname or a ready connection string per service port.
Igor Cherkaev (@igcherkaev) which of those two closes your case? If <name>.<suffix> shown next to the LoadBalancer IP is enough, that is a small change and I would rather ship it than hold it behind the full design.
Taking this off backlog. It has been asked for four times now, twice in this thread and twice in the community chat, and it is the reason at least one operator is still running 1.3.5 rather than moving to the new dashboard.
Nothing has started on the UI side: no issue and no PR in cozystack-ui touches the Services tab for this.
Two things need a decision before any code. Where the suffix comes from, platform config or tenant or a per-app field. And what the tab actually renders, a bare hostname or a ready connection string per service port.
Igor Cherkaev (@igcherkaev) which of those two closes your case? If <name>.<suffix> shown next to the LoadBalancer IP is enough, that is a small change and I would rather ship it than hold it behind the full design.
The suffix could just come from the dashboard component's values (or any other place, I'll leave it to you). By default it could take the global cluster DNS suffix.
If some level of flexibility is required, it could be also made to be possible to override via some annotation on the service, if the operator or tenant admin doesn't like the platform configured one.
The bare minimum for us is: we provide access to the cluster to our dev teams, they provision required services on their own, once provisioned, they see the FQDN to connect to. If port number can also be shown next to it, it'd be nice, but since ports are usually pretty standard and the services are well-known, it'd be more like a "nice to have", rather than "required" feature.
Igor Cherkaev (@igcherkaev)#4035 covers your minimum case. Set publishing.serviceDomain in the platform values, and the Services tab shows <service-name>.<suffix> under the external IP of every LoadBalancer Service.
I did not default it to the cluster domain. A svc.cluster.local name does not resolve from outside the cluster, so your dev teams would see a hostname they can't connect to. The name is display-only, so your DNS has to resolve it already, for example external-dns with a matching fqdn template. A per-Service override annotation and the port are left for a follow-up.
The PR is rebased on current main and waits for review.
Activity
igcherkaev commentedon Jul 10, 2026
Aleksei Sviridkin (@lexfrei) thanks for fixing the missing load balancer IP, but this is also a highly anticipated feature!
igcherkaev commentedon Jul 28, 2026
Aleksei Sviridkin (@lexfrei) myasnikovdaniil just a gentle nudge to maybe take a look at it again. Thanks in advance!
lexfrei commentedon Aug 14, 2026
Taking this off backlog. It has been asked for four times now, twice in this thread and twice in the community chat, and it is the reason at least one operator is still running 1.3.5 rather than moving to the new dashboard.
Nothing has started on the UI side: no issue and no PR in cozystack-ui touches the Services tab for this.
Two things need a decision before any code. Where the suffix comes from, platform config or tenant or a per-app field. And what the tab actually renders, a bare hostname or a ready connection string per service port.
Igor Cherkaev (@igcherkaev) which of those two closes your case? If
<name>.<suffix>shown next to the LoadBalancer IP is enough, that is a small change and I would rather ship it than hold it behind the full design.igcherkaev commentedon Aug 22, 2026
Aleksei Sviridkin (@lexfrei) Oh, sorry, forgot to reply here, replied in the community chat.
The suffix could just come from the dashboard component's values (or any other place, I'll leave it to you). By default it could take the global cluster DNS suffix.
If some level of flexibility is required, it could be also made to be possible to override via some annotation on the service, if the operator or tenant admin doesn't like the platform configured one.
The bare minimum for us is: we provide access to the cluster to our dev teams, they provision required services on their own, once provisioned, they see the FQDN to connect to. If port number can also be shown next to it, it'd be nice, but since ports are usually pretty standard and the services are well-known, it'd be more like a "nice to have", rather than "required" feature.
lexfrei commentedon Sep 30, 2026
Igor Cherkaev (@igcherkaev) #4035 covers your minimum case. Set
publishing.serviceDomainin the platform values, and the Services tab shows<service-name>.<suffix>under the external IP of every LoadBalancer Service.I did not default it to the cluster domain. A
svc.cluster.localname does not resolve from outside the cluster, so your dev teams would see a hostname they can't connect to. The name is display-only, so your DNS has to resolve it already, for example external-dns with a matching fqdn template. A per-Service override annotation and the port are left for a follow-up.The PR is rebased on current main and waits for review.
feat(dashboard): show a connection hostname for LoadBalancer services (…