gateway: platform TLSRoutes use root-host while a non-root publishing tenant's listeners use its own apex
メンテナーはふだん 3 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 48/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- go, kubernetes
- 領域
- cloud, networking
調査の方向性
Start by comparing the listed TLSRoute templates in packages/system/cozystack-api/templates/api-tlsroute.yaml, packages/system/kubevirt/templates/vm-exportproxy-tlsroute.yaml, and packages/system/kubevirt-cdi/templates/cdi-uploadproxy-tlsroute.yaml with the publishing tenant host and the listener hostname rendered in internal/controller/tenantgateway/reconciler.go. Reproduce with a non-root publishing tenant and inspect the route and Gateway listener hostnames. Done means the platform endpoints attach for that layout, or the supported host constraint is documented and validated.
索引モデルが issue の本文から書いたものです。
説明
Summary
When publishing.ingressName names a tenant other than tenant-root, the platform's TLS-passthrough routes never attach. The routes build their hostnames from the cluster's root-host, while the passthrough listeners they pin by sectionName carry the publishing tenant's own apex. The two hostnames do not intersect, so the Kubernetes API, VM export and CDI upload endpoints are not published through the Gateway at all.
Mechanism (main at bf03c8471)
-
The platform routes take their hostname from
_cluster.root-host:packages/system/cozystack-api/templates/api-tlsroute.yaml:1and:19(api.<root-host>)packages/system/kubevirt/templates/vm-exportproxy-tlsroute.yaml:1and:18(vm-exportproxy.<root-host>)packages/system/kubevirt-cdi/templates/cdi-uploadproxy-tlsroute.yaml:1and:18(cdi-uploadproxy.<root-host>)
Each route pins
sectionName: tls-<svc>on the Gateway in theexpose-ingressnamespace (:3,:15-:17in each file). -
expose-ingresscomes frompublishing.ingressName(packages/core/platform/templates/apps.yaml:167), androot-hostcomes frompublishing.hostor thecozystackConfigMap (packages/core/platform/templates/apps.yaml:5-8and:37). Nothing ties the two together. -
The gateway chart of the publishing tenant sets the TenantGateway apex from that tenant's own host (
packages/extra/gateway/templates/tenantgateway.yaml:1and:139, reading_namespace.host). For a child tenant that host is<name>.<parent-host>unlesstenant.spec.hostoverrides it (packages/apps/tenant/templates/namespace.yaml:20-24). -
The controller renders each
tls-<svc>listener with hostname<svc>.<apex>(internal/controller/tenantgateway/reconciler.go:1681).
So with publishing.ingressName: tenant-foo, the listener is tls-api for api.foo.<root-host>, and the route asks for api.<root-host> on that listener. Gateway API attaches a route only where its hostnames intersect the listener's hostname, so the route attaches nowhere.
Steps to reproduce
- Set
gateway.enabled: trueandpublishing.ingressName: tenant-fooin the platform values, keepingapiinpublishing.exposedServices. - Create tenant
fooundertenant-rootwithgateway: trueand no explicithost. - Look at
kubectl -n default get tlsroute kubernetes-api -o yaml. The route's hostname isapi.<root-host>, while thetls-apilistener ontenant-foo/cozystackanswersapi.foo.<root-host>. The route is not served there.
The default layout, where the publishing tenant is tenant-root and its host equals root-host, is not affected.
Possible directions
- Build the platform route hostnames from the publishing tenant's host rather than from
root-host, or - Document and validate that the publishing tenant's host must equal
publishing.host.
The pending gateway portability change (#4638) already renders the singleAddress API route from the publishing tenant's own gateway chart and apex, so the API is consistent there. The VM export and CDI upload HTTPRoutes still use root-host.
- 主要言語
- Go
- スター
- 2.2k
- フォーク
- 209
- 平均マージ
- 3日 18時間
- マージ済み PR（30日）
- 241
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
cozystack/cozystack のほかの issue
-
triage/needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
cozystack/cozystack#4787 · リアクション 1 件 ·
メンテナーはふだん 3 日以内に返信
-
kubernetes-nodes: raising minReplicas does not raise the MachineDeployment's replicas on upgradeオープンtriage/needs-triage
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
cozystack/cozystack#4786 · リアクション 1 件 ·
メンテナーはふだん 3 日以内に返信
-
triage/needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
cozystack/cozystack#4785 · リアクション 1 件 ·
メンテナーはふだん 3 日以内に返信
-
triage/needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
cozystack/cozystack#4777 · リアクション 1 件 ·
メンテナーはふだん 3 日以内に返信
-
triage/needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
cozystack/cozystack#4776 · リアクション 1 件 ·
メンテナーはふだん 3 日以内に返信
cozystack/cozystack の issue をすべて見る
似ている issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
vanderheijden86/b9s#20 ·
-
go-battery needs an ndsctl on PATH: TestPurchaseSessionGuardHoldsThroughTheOutcomeUnknownWindow fails on bare hosts (passes with stub)対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
OpenTollGate/tollgate-module-basic-go#726 ·
メンテナーはふだん 1 日以内に返信
-
ux waiting for feedback
難易度 2/5 1〜3時間 初心者へのやさしさ 63/100
evcc-io/evcc#34527 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
phase:v3 type:harness
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信