MeshSync: non-Kubernetes / multi-platform discovery (design)
- Dominant language
- Go
- Stars
- 90
- Forks
- 96
- PR merge metrics
- No merged PRs in 30d
Description
## Summary
Let MeshSync discover non-Kubernetes platforms (Docker first, cloud later) into Server's already kind-agnostic Connection state machine, via an infrastructure-agnostic model - incrementally, not a big-bang rewrite.
## Key decisions
- **Phase 0 enabling refactor**: a `Discoverer` interface (`Discover`/`Watch`/`ScopeID`/`Shutdown`) with today's Kubernetes machinery as the first adapter (a thin wrapper, zero behavior change). Independently low-risk; unblocks everything non-K8s.
- Schema-first: a new platform-agnostic `resource` envelope construct in meshery/schemas; MeshSync ships a hand-written mirror first (the codegen swap is deferred to avoid compounding scope). `ScopeID` generalizes `clusterID` (dual-written for one migration window).
- Server's Connection model + FSM are already kind-generic (the `grafana`/`prometheus` register-only machines are the precedent); a Docker machine slots into `getMachine` the same way.
## Scope / phasing
Phase 0 refactor (days, MeshSync-only, runtime-verified for zero regression). Phase 1 Docker MVP end-to-end (weeks, 4 repos). Cloud = per-provider projects, each >= Docker-sized.
**Honest caveats:** cloud inventory APIs have no push/watch (poll-diff), and are rate-limited/metered; fingerprinting robustness and any Kanvas `Kind`-enum assumptions are open questions; standalone (non-embedded) deployment topology is deferred.
## Full design
[docs/design/fd6-non-kubernetes-discovery.md](https://github.com/meshery/meshsync/blob/master/docs/design/fd6-non-kubernetes-discovery.md) (added in #576).
Contributor guide
Research direction
Start with docs/design/fd6-non-kubernetes-discovery.md, then inspect the existing Kubernetes machinery and the proposed Discoverer methods: Discover, Watch, ScopeID, and Shutdown. Review how Server's Connection state machine reaches getMachine, and confirm which phase is being attempted. Phase 0 is done when the adapter preserves behavior and runtime verification shows zero regression; Docker MVP requires the described end-to-end work across four repositories.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, go, kubernetes
- Domain
- backend-api-design, distributed-systems, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100