MeshSync: composite fingerprints spanning multiple entities (design)

[leecalcote]

Summary

Correlate the individually-discovered objects that compose one application (Deployment + Service + ConfigMap + ...) into a named group, and identify the tool/version behind it. Today every object is published and persisted in isolation.

Key decisions

• Correlate server-side, not in MeshSync - informer events arrive out of order and MeshSync forbids cross-run pipeline state; Server has the full per-cluster DB and an existing async registration-queue hook.
• Schema-first: two additive v1beta1 constructs (application_group, relationship_instance) that reuse the existing RelationshipDefinition taxonomy - sibling.matchlabels for same-app grouping (porting the existing MatchLabelsPolicy algorithm to runtime rows) and hierarchical.inventory.parent for owner-references. Grouping key tiers: app.kubernetes.io/instance -> /part-of -> /name.
• Replaces the acknowledged getTypeOfConnection substring hack in auto_register.go (which already carries an // Improve this fingerprinting comment) with a real fingerprint lookup; fallback preserved.

Scope / phasing

Phase 1: label-based grouping (~2 wks). Phase 2: builder-pattern tool+version identification with confidence/evidence.

Risks flagged: never fabricate group keys when labels are absent; prefer /instance over broad /part-of to avoid over-grouping; fix delete-cascade orphaned relationship_instance rows.

Full design

docs/design/fd3-composite-fingerprints.md (added in #576).