Skip to content

App detail Services tab: show a connection FQDN with configurable domain suffix #3112

Closed

Description

Summary

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.

Reference

User report: #2789.

Sibling: cozystack/cozystack-ui#38 (raw LoadBalancer IP wiring).

Activity

  1. added
    kind/featureCategorizes issue or PR as related to a new feature
    priority/backlogGeneral backlog priority. Lower than priority/important-longterm
    on Jun 3, 2026
  2. igcherkaev commented on Jul 10, 2026

    @igcherkaev

    Aleksei Sviridkin (@lexfrei) thanks for fixing the missing load balancer IP, but this is also a highly anticipated feature!

  3. igcherkaev commented on Jul 28, 2026

    @igcherkaev

    Aleksei Sviridkin (@lexfrei) myasnikovdaniil just a gentle nudge to maybe take a look at it again. Thanks in advance!

  4. lexfrei commented on Aug 14, 2026

    @lexfrei
    ContributorAuthor

    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.

  5. added
    priority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to complete
    and removed
    priority/backlogGeneral backlog priority. Lower than priority/important-longterm
    on Aug 14, 2026
  6. igcherkaev commented on Aug 22, 2026

    @igcherkaev

    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.

    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.

  7. lexfrei commented on Sep 30, 2026

    @lexfrei
    ContributorAuthor

    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.

  8. added a commit that references this issue on Sep 30, 2026
    c586506
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/dashboardIssues or PRs related to the dashboard / UIkind/featureCategorizes issue or PR as related to a new featurepriority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to completetriage/acceptedIndicates an issue is ready to be actively worked on

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions