flyte-deploy-kind: local kind + R2 deploy needs task-pod storage creds, runs.storagePrefix override, and console-origin fix
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 58/100
- Loại issue
- Tài liệu
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- helm, kubernetes, python
- Lĩnh vực
- cloud, devops, documentation, infrastructure
Hướng nghiên cứu
Bắt đầu với skill runbook của flyte-deploy-kind, đặc biệt là các phần về storage và auth tùy chọn, rồi so sánh chúng với hành vi được báo cáo của R2, task-pod, console và port-forward. Thêm các biến môi trường của task-pod, ví dụ về runs.storagePrefix, quyền truy cập console qua một origin thống nhất và các ghi chú về vòng đời của port-forward; được xem là hoàn tất khi runbook cơ sở bao quát một deployment sẵn sàng cho task và các đường dẫn console hoạt động.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
While deploying a local kind-based Flyte v2 (flyte-binary v2.0.27) cluster on macOS using the flyte-deploy-kind skill, the control plane came up healthy and the API (ListProjects) worked, but task execution and the web console did not work out of the box. Each issue was diagnosable but not covered by the skill runbook. Filing to suggest concrete additions.
Deployment shape: kind on the local machine + Supabase Postgres (session pooler) + Cloudflare R2 object store.
Issues faced (in the order they surfaced)
1. Web console can't reach the API — console and API are separate origins
Port-forwarding flyte-console directly (:8080) serves only the Next.js SPA. The console frontend resolves its API base URL as NEXT_PUBLIC_ADMIN_API_URL || "/", and that env var is unset, so the browser calls the API at the same origin it was served from (localhost:8080/flyteidl2.*) — which 404s because :8080 doesn't serve the API. Result: run pages load blank / "connection refused" on the URL the SDK prints (http://localhost:8080/v2/...).
What actually works: put console + API behind one origin. Traefik (installed by the auth flow) with two IngressRoutes — PathPrefix('/flyteidl2.') → flyte-http:8090 (scheme h2c) and / → flyte-console:80 — then kubectl -n traefik port-forward service/traefik 8080:80 and open http://localhost:8080/v2.
2. Task pods have no object-store credentials → fall back to AWS IMDS
Tasks fail with:
OSError: Generic S3 error: Error performing PUT http://169.254.169.254/latest/api/token ... HTTP error: error sending request
The task-side SDK (obstore) reads static creds from FLYTE_AWS_ENDPOINT / FLYTE_AWS_ACCESS_KEY_ID / FLYTE_AWS_SECRET_ACCESS_KEY (flyte/storage/_config.py, S3._KEY_ENV_VAR_MAPPING). With none set it uses the default AWS credential chain and hits the EC2 metadata endpoint 169.254.169.254. The chart's storage.* values configure the control plane but do not propagate credentials to task pods.
Fix: inject them via configuration.inline.plugins.k8s.default-env-vars. Caveat: this list replaces the chart default, so the control-plane vars must be repeated:
configuration:
inline:
plugins:
k8s:
default-env-vars:
- _U_EP_OVERRIDE: "flyte-http.flyte:8090"
- _U_INSECURE: "true"
- _U_USE_ACTIONS: "1"
- FLYTE_AWS_ENDPOINT: "https://<account>.r2.cloudflarestorage.com"
- FLYTE_AWS_ACCESS_KEY_ID: "<key>"
- FLYTE_AWS_SECRET_ACCESS_KEY: "<secret>"
3. Task I/O written to the wrong bucket → 403 AccessDenied
After creds were fixed, tasks then failed with:
403 Forbidden AccessDenied ... PUT https://<account>.r2.cloudflarestorage.com/flyte-data/.../error.pb
runs.storagePrefix defaults to s3://flyte-data (a bucket that doesn't exist), so all task input/output/error writes go to the wrong bucket. storage.metadataContainer / userDataContainer only set the dataproxy container — not this prefix.
Fix:
configuration:
inline:
runs:
storagePrefix: s3://<real-bucket>
4. Minor / papercuts
helm upgradekills theflyte-httpport-forward. Every upgrade rolls the flyte pod, droppingkubectl port-forward service/flyte-http 8090:8090; the SDK then reports "Flyte system is currently unavailable." Worth calling out to restart it after each upgrade.- Console vs SDK use different ports. Browser →
:8080(Traefik unified origin), SDK →:8090(flyte-http). Easy to conflate; the run URL advertises:8080while the SDK config points at:8090. - Default SDK config port. A generated project-local
.flyte/config.yamlpointed atlocalhost:8080foradmin.endpoint; the API is on8090.
Suggested skill improvements
- Add a "Storage for task pods" step for any S3-compatible store (R2/MinIO), documenting the three
FLYTE_AWS_*env vars and thedefault-env-varslist-replacement caveat. This is required for tasks to run at all — not optional. - Add
runs.storagePrefixoverride to the storage step (or derive it frommetadataContainer), and explain it's distinct frommetadataContainer/userDataContainer. - Document console access without auth. The base (no-auth) path currently leaves the console unreachable for run pages; add the Traefik unified-origin recipe (or set
NEXT_PUBLIC_ADMIN_API_URL) so/v2run pages load. Today Traefik only appears in the optional auth section. - Note the port-forward lifecycle — that
helm upgradedrops theflyte-httpforward, and that browser (:8080) and SDK (:8090) use different forwards. - Consider a values snippet that bundles items 1–2 into the R2/S3 example so the base deployment is task-ready, not just API-ready.
Happy to open a PR against the skill with these additions if useful.
Environment: macOS, Docker Desktop, kind, flyte-binary v2.0.27, flyte SDK 2.5.8, Cloudflare R2 + Supabase (session pooler).
- Ngôn ngữ chính
- Python
- Star
- 4
- Fork
- 4
- Merge trung bình
- 4 giờ 28 phút
- Pull request đã merge (30 ngày)
- 4
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của flyteorg/flyte-agent-plugins
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 66/100
Tất cả issue của flyteorg/flyte-agent-plugins
Issue tương tự
-
PluginProvider.storeInstance races and clobbers the dedup cache for concurrent loadsCó thể đã có người làm @Wilson0511 đã nhận hôm nay. Đang mởneeds-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 2 ngày
-
community documentation good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
kagent-dev/kagent#3462 ·
Maintainer thường phản hồi trong vòng 1 ngày