github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-05-08 05:39:49 -05:00
Code Issues 564 Packages Projects Releases 72 Wiki Activity

[GH-ISSUE #1439] [Feature Request] Develop a Kubernetes Operator for Headless/Declarative Pangolin Setup #8675

New Issue
Closed
opened 2026-04-30 04:40:52 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-04-30 04:40:52 -05:00
Owner
Copy Link

Originally created by @marcschaeferger on GitHub (Sep 8, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1439

Originally assigned to: @marcschaeferger on GitHub.

Summary

Create a Kubernetes Operator for Pangolin to enable fully headless, declarative provisioning and lifecycle management via Custom Resources (CRs/CRDs). The operator should optionally use the Pangolin HTTP API (POST/PUT) where needed and possible (e.g., to create API keys or perform actions not exposed directly via DB/config) while keeping the primary contract declarative through CRs.

Motivation

  • Allow GitOps-style provisioning of Pangolin (sites, resources, tunnels etc.) without using the web UI.
  • Remove manual steps (e.g., admin UI key creation) during automated installs.
  • Provide reconciliation semantics (self-healing) and integrate with Kubernetes primitives (Secrets, ConfigMaps, Ingress, PVCs).

Goals / Requirements

  • Define and implement CRDs to represent Pangolin concepts (example CRs: PangolinCluster, PangolinSite, PangolinResource).
  • Operator performs reconciliation to ensure cluster state matches the declared CRs.
  • Support bootstrap/seed behavior on first-run (apply initial sites/resources from CRs or mounted config).
  • Optionally call Pangolin API endpoints for operations not possible via direct configuration (e.g., generating integration API keys) — operator should support both direct config and API-backed flows.
  • Integrate with Kubernetes objects:
    • Use Secrets for credentials / API keys
    • Use ConfigMaps for static config or seed files
    • Support PVC/Storage, Ingress or Service for exposing UI/API
  • Provide idempotent behavior and clear status conditions for each CR.
  • Emit logs and events for troubleshooting; provide output/status for success/failure.
  • Include basic validation/webhook (optional) for CRD fields.
  • Provide sample YAMLs and documentation for GitOps workflows.

Operator behaviors / features

  • Watch Pangolin CRs and reconcile: create/update/delete Pangolin configuration and resources.
  • On create, operator can either:
    • Write config files / DB entries directly (preferred), or
    • Call Pangolin API to create resources when necessary (fallback).
  • Support "seed on startup" mode: load initial resources from a ConfigMap/volume and apply them as CRs.
  • Provide optional "wait for readiness" and "debug dumps" (describe pods, collect logs) on failures.
  • Support disabling timeouts / manual confirmation flows via annotations or CR spec for testing scenarios.

Acceptance Criteria

  • CRDs are defined and documented.
  • Operator can create at least: PangolinCluster and PangolinSite resources and reconcile them.
  • Operator can bootstrap an admin user and/or create an integration API key and store it in a Secret.
  • Operator supports declarative creation of at least one example site end-to-end (ingress -> pangolin -> backend).
  • Documentation includes sample GitOps workflow and CR examples.

Notes / Non-goals

  • The operator should not require the web UI for initial provisioning (goal is headless), but may optionally interact with Pangolin's API if some operations cannot be achieved otherwise.
  • Advanced UI features and any unrelated Pangolin UX items are out of scope.
Originally created by @marcschaeferger on GitHub (Sep 8, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/1439 Originally assigned to: @marcschaeferger on GitHub. ## Summary Create a Kubernetes Operator for Pangolin to enable fully headless, declarative provisioning and lifecycle management via Custom Resources (CRs/CRDs). The operator should optionally use the Pangolin HTTP API (POST/PUT) where needed and possible (e.g., to create API keys or perform actions not exposed directly via DB/config) while keeping the primary contract declarative through CRs. ## Motivation - Allow GitOps-style provisioning of Pangolin (sites, resources, tunnels etc.) without using the web UI. - Remove manual steps (e.g., admin UI key creation) during automated installs. - Provide reconciliation semantics (self-healing) and integrate with Kubernetes primitives (Secrets, ConfigMaps, Ingress, PVCs). ## Goals / Requirements - Define and implement CRDs to represent Pangolin concepts (example CRs: PangolinCluster, PangolinSite, PangolinResource). - Operator performs reconciliation to ensure cluster state matches the declared CRs. - Support bootstrap/seed behavior on first-run (apply initial sites/resources from CRs or mounted config). - Optionally call Pangolin API endpoints for operations not possible via direct configuration (e.g., generating integration API keys) — operator should support both direct config and API-backed flows. - Integrate with Kubernetes objects: - Use Secrets for credentials / API keys - Use ConfigMaps for static config or seed files - Support PVC/Storage, Ingress or Service for exposing UI/API - Provide idempotent behavior and clear status conditions for each CR. - Emit logs and events for troubleshooting; provide output/status for success/failure. - Include basic validation/webhook (optional) for CRD fields. - Provide sample YAMLs and documentation for GitOps workflows. ## Operator behaviors / features - Watch Pangolin CRs and reconcile: create/update/delete Pangolin configuration and resources. - On create, operator can either: - Write config files / DB entries directly (preferred), or - Call Pangolin API to create resources when necessary (fallback). - Support "seed on startup" mode: load initial resources from a ConfigMap/volume and apply them as CRs. - Provide optional "wait for readiness" and "debug dumps" (describe pods, collect logs) on failures. - Support disabling timeouts / manual confirmation flows via annotations or CR spec for testing scenarios. ## Acceptance Criteria - CRDs are defined and documented. - Operator can create at least: PangolinCluster and PangolinSite resources and reconcile them. - Operator can bootstrap an admin user and/or create an integration API key and store it in a Secret. - Operator supports declarative creation of at least one example site end-to-end (ingress -> pangolin -> backend). - Documentation includes sample GitOps workflow and CR examples. ## Notes / Non-goals - The operator should not require the web UI for initial provisioning (goal is headless), but may optionally interact with Pangolin's API if some operations cannot be achieved otherwise. - Advanced UI features and any unrelated Pangolin UX items are out of scope.
GiteaMirror commented 2026-04-30 04:40:53 -05:00
Author
Owner
Copy Link

@chiqors commented on GitHub (Sep 13, 2025):

I recently saw someone working on a Pangolin operator: https://github.com/bovf/pangolin-operator

maybe you could try check that, see if this similar approach.

<!-- gh-comment-id:3287672436 --> @chiqors commented on GitHub (Sep 13, 2025): I recently saw someone working on a Pangolin operator: https://github.com/bovf/pangolin-operator maybe you could try check that, see if this similar approach.
GiteaMirror commented 2026-04-30 04:40:54 -05:00
Author
Owner
Copy Link

@miloschwartz commented on GitHub (Sep 27, 2025):

Thanks, converting this to a discussion thread so others can upvote and participate!

<!-- gh-comment-id:3341947302 --> @miloschwartz commented on GitHub (Sep 27, 2025): Thanks, converting this to a discussion thread so others can upvote and participate!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
api
authentication
bug
config
dependencies
docker
documentation
enhancement
good first issue
help wanted
Improvement
Look Into
needs investigating
networking
new feature
non-critical bug
potential bug
pull-request
Mirrored from GitHub Pull Request
 question
reverse proxy
Security
stale
ui
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#8675
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?