docs(platform-package): sync the publishing.* table with the platform values - #679
Aleksei Sviridkin (lexfrei) wants to merge 2 commits into
Conversation
✅ Deploy Preview for cozystack ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
myasnikovdaniil
left a comment
myasnikovdaniil
left a comment
There was a problem hiding this comment.
Blocking on one row. publishing.serviceDomain does not exist at either end yet. Rendered the platform chart on main with the value set and nothing reaches the values Secret, and on the consumer side ServicesTab.tsx builds the External IP cell as ip ?? hostname ?? "Pending" with serviceDomain nowhere in the console source. So display-only does not make it harmless to document early, it documents a key nothing reads on either side. Both halves arrive with #4035. Split that row into a PR stacked on it, or hold this one until #4035 lands.
Rest of the table I went through cell by cell against packages/core/platform/values.yaml and against the v1.5.0 and v1.6.0 tags. All of it matches, and there is no publishing key left undocumented. The removals are correct, and the loadBalancerClass row is accurate down to the failure message: the host-ingress suites pass 10/10 and one case asserts that message literally carries the kubectl delete service command.
Second ask, and it is the bigger one. latest_version_id is v1.6, so content/en/docs/v1.6/ is what readers actually get served, and it still lists all five publishing.exposureClass.* rows and has no loadBalancerClass, which v1.6.0 does ship. grep -rln exposureClass content/ now returns that one file and nothing else. So the release everyone runs is documented with five keys that don't exist and missing the one that replaced them, and no issue or open PR tracks it. Copy the same edit there, in this PR or right after it.
i18n-lint red is stale source_digest in de/hi/ru/zh-cn _index.md, not from this diff. But main got its digests refreshed and it is green there since 2026-09-08, so a rebase should clear it.
| | `publishing.ingressName` | `"tenant-root"` | Ingress controller to use for exposing services. | | ||
| | `publishing.externalIPs` | `[]` | List of external IPs used for the specified ingress controller. If not specified, a LoadBalancer service is used by default. | | ||
| | `publishing.loadBalancerClass` | `""` | Native `loadBalancerClass` for the host ingress. When `publishing.externalIPs` is empty the host ingress publishes its Service as `type: LoadBalancer`; this is the `loadBalancerClass` of the LoadBalancer controller that should handle it. The admin provisions the matching address pool or announcer out of band (a MetalLB `IPAddressPool`, a Cilium LB-IPAM pool, a cloud LB). Empty (the default) lets the cluster's default LoadBalancer controller claim the Service. `spec.loadBalancerClass` is immutable: on a cluster whose host ingress Service already exists as `type: LoadBalancer`, setting, changing or clearing this value requires recreating that Service once — the chart fails early with the exact command. This is the migration path off `Service.spec.externalIPs`. | | ||
| | `publishing.serviceDomain` | `""` | DNS suffix the dashboard appends to the name of a LoadBalancer Service on the application Services tab, shown under the external IP as `<service-name>.<serviceDomain>` (for a postgres release named `demo`: `demo-external-write.<serviceDomain>`). Display-only: nothing in the platform creates DNS records for it. Set it only when your DNS already resolves exactly that name to the Service's LoadBalancer IP, for example external-dns with a matching fqdn template; a CoreDNS `k8s_external` zone does not fit, because it answers `<service>.<namespace>.<zone>`. The name is not the `<release>.<tenant host>` name the app charts put into their certificates, so a TLS client may see a SAN mismatch unless DNS and certificates are aligned by the operator. The suffix is cluster-wide, so two tenants with a release of the same name get the same hostname. Empty (the default) shows no hostname. | |
There was a problem hiding this comment.
This key is not in tree yet, main has none and v1.6.0 has none, it lives only on feat/dashboard-service-fqdn. Until #4035 merges anyone following this row sets a value nothing reads. Better to split it into PR stacked on #4035.
There was a problem hiding this comment.
Removed in b32653a. I'll open this row as its own PR after cozystack/cozystack#4035 merges.
| | `publishing.exposedServices` | `[api, dashboard, vm-exportproxy, cdi-uploadproxy]` | List of services to expose. Possible values: `api`, `dashboard`, `cdi-uploadproxy`, `vm-exportproxy`. | | ||
| | `publishing.ingressName` | `"tenant-root"` | Ingress controller to use for exposing services. | | ||
| | `publishing.externalIPs` | `[]` | List of external IPs used for the specified ingress controller. If not specified, a LoadBalancer service is used by default. | | ||
| | `publishing.loadBalancerClass` | `""` | Native `loadBalancerClass` for the host ingress. When `publishing.externalIPs` is empty the host ingress publishes its Service as `type: LoadBalancer`; this is the `loadBalancerClass` of the LoadBalancer controller that should handle it. The admin provisions the matching address pool or announcer out of band (a MetalLB `IPAddressPool`, a Cilium LB-IPAM pool, a cloud LB). Empty (the default) lets the cluster's default LoadBalancer controller claim the Service. `spec.loadBalancerClass` is immutable: on a cluster whose host ingress Service already exists as `type: LoadBalancer`, setting, changing or clearing this value requires recreating that Service once — the chart fails early with the exact command. This is the migration path off `Service.spec.externalIPs`. | |
There was a problem hiding this comment.
Two things here. Early failure is not platform render, it is ingress helmrelease guard, so what operator sees is flux reconcile error on ingress release. And row says what happens when publishing.externalIPs is empty but not what happens when it is not, class is silently ignored with no error at all.
There was a problem hiding this comment.
Fixed in b32653a, the v1.6 copy is in cec1b3b. The guard lives in packages/extra/ingress/templates/nginx-ingress.yaml, not in the platform chart, so the row now says the ingress HelmRelease fails to reconcile. The case where a non-empty publishing.externalIPs makes the class silently ignored is covered by the keeps the externalIPs path untouched by loadBalancerClass test.
77b7d50 to
1ad801b
Compare
… values The publishing.* reference on the next trunk documented five publishing.exposureClass.* keys the platform no longer has: the ExposureClass/ServiceExposure machinery was dropped for the native Service loadBalancerClass, and packages/core/platform/values.yaml carries no exposureClass key. Remove those rows and rewrite the publishing.exposure note that still named exposureClass as the successor. Add the publishing.loadBalancerClass row that replaced them and never had one: it names the LoadBalancer controller for the host ingress Service, the address pool or announcer is provisioned out of band, and because spec.loadBalancerClass is immutable an existing Service has to be recreated once when the value changes. The row says where that failure surfaces (the ingress HelmRelease reconcile, not the platform render) and that the value is ignored while externalIPs is set, since the Service then stays ClusterIP. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin <f@lex.la>
v1.6 is the served release, and its publishing.* table still listed the five publishing.exposureClass.* keys while missing publishing.loadBalancerClass. The v1.6.0 platform values have no exposureClass key and do ship loadBalancerClass, with the same ingress-side immutability guard as the trunk, so the v1.6 page gets the same rows and the same publishing.exposure note as next. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin <f@lex.la>
1ad801b to
cec1b3b
Compare
|
myasnikovdaniil the |
This branch has not been deployed
2 participants
The publishing table on the platform-package page is out of date. It lists five
publishing.exposureClass.*keys that the platform no longer has, and it has no row forpublishing.loadBalancerClass. ExposureClass was dropped in favour of the nativeloadBalancerClass.This PR removes the five rows and adds
loadBalancerClass, based on the comment in the platform values and the guard in the ingress chart. The note under the table still namedpublishing.exposureClassas the successor ofpublishing.exposure, so it now points atexternalIPsandloadBalancerClassinstead. The KEP-5707 deprecation timeline forService.spec.externalIPsused to sit in the removedexposureClass.namerow. It moved to theloadBalancerClassrow.The same change goes into
content/en/docs/v1.6/, which is the served version. v1.6.0 shipsloadBalancerClassand has noexposureClasskey, so that page had the same five stale rows and no row for the new key.The
publishing.serviceDomainrow is no longer part of this PR. It depends on cozystack/cozystack#4035, which is still open, and will come as a separate PR once that lands.Every
publishing.*row on both pages matchespackages/core/platform/values.yaml(main for next, the v1.6.0 tag for v1.6).hugo --gc --minifyandhack/check-i18n.shpass locally.