Skip to content

Plugin Composition Uplift Tracker

Status: Active after MinIO/storage composition landed Owner: Floe architecture Last updated: 2026-05-09

This document tracks adoption of Floe’s composition model across plugin families after the MinIO/storage composition work landed. Follow-on plugin-family uplift is tracked here unless a plugin is required for the implemented alpha Iceberg runtime path.

The landed work establishes the pattern for MinIO-backed, S3-compatible storage composition in the Polaris/DuckDB/Dagster alpha path. Other plugins should adopt the pattern only when they participate in concrete cross-plugin composition. This prevents a platform-wide rewrite while keeping a clear target state.

LevelMeaningRequired Evidence
0Discoverable plugin onlyEntry point, metadata, config schema
1Declares capabilities and requirementsPluginCapabilities, PluginRequirements, compatibility tests
2Emits or consumes typed bindingsContract model, schema tests, no raw secrets
3Has deployment/runtime translators validated by resolverResolver tests, generated deployment binding, renderer tests, E2E where applicable
Plugin familyTarget levelStatusScope
Storage3Landed for floe-storage-minioNeutral storage binding, bucket requirements, credential refs, capabilities, provisioning intent
Catalog3Landed for Polaris + MinIOCatalog storage requirements, Polaris deployment binding, bootstrap payload, storage Secret refs
Compute / dbt3Landed for DuckDB/dbt profile pathRuntime storage binding consumption, profile generation, endpoint/credential consistency
Orchestrator / Dagster2 then 3Remaining migrationDagster still needs binding-first Iceberg writer/runtime ownership cleanup
Helm / deployment renderer3Landed for MinIO/Polaris binding renderingRender resolved deployment bindings; no semantic storage decisions in templates
Secrets / identity2 then 3Remaining projection workCredential and workload identity modes are typed; full provider-owned projection still needs implementation
Plugin familyTarget levelTrigger for upliftNotes
Ingestion2 then 3Landing, quarantine, checkpoint, or raw bucket requirements become first-classShould consume storage bucket requirements instead of inventing bucket config
Semantic layer2 then 3Semantic runtime needs compute/catalog/storage bindingAvoid direct compute connection duplication
Lineage backend1 then 2Backend deployment/auth or endpoint wiring becomes plugin-ownedOpenLineage remains enforced standard
Telemetry backend1 then 2OTLP backend deployment topology becomes plugin-ownedOpenTelemetry remains enforced standard
Quality1 then 2Quality plugin needs runtime compute/storage capabilitiesdbt tests remain enforced baseline
RBAC2 then 3Workload identities and Secret refs are generated from plugin bindingsRemaining work; should consume declared runtime surfaces
Network / pod security2 then 3Network policy needs service endpoints from plugin deployment bindingsRemaining work; should consume deployment bindings instead of static service names
Alert channels1Alert delivery backends add auth/deployment requirementsKeep low priority until user-facing alerts are implemented
  • A plugin may declare what it needs and translate its own config.
  • A plugin must not know every other plugin’s implementation details.
  • New compatibility should be represented as capabilities and requirements, not as chart conditionals.
  • New provider-specific fields belong in provider-owned deployment bindings unless they are stable cross-provider concepts.
  • CompiledArtifacts must remain secret-free.
  • Helm and other renderers consume resolved deployment bindings; they do not rediscover plugin config.
  • floe-storage-minio remains strict with no s3 alias.
  • CompiledArtifacts.deployment.storage carries neutral storage desired state.
  • CompiledArtifacts.deployment.catalog carries Polaris-owned deployment and bootstrap state.
  • Composition resolver validates Polaris + MinIO and rejects incompatible catalog/storage selections with actionable errors.
  • floe helm generate renders from deployment bindings only.
  • Architecture docs describe the composition model.
  • Raw storage credentials are absent from compiled artifacts and generated chart values; Kubernetes Secret refs carry credential identity.
  • Remote infrastructure E2E is run, product failures are separated from infrastructure failures, and billable resources are directly verified and cleaned up.
  • Credential and identity projection: provider-owned secret and workload identity resources need complete translation from typed modes.
  • Dagster/Iceberg runtime ownership: orchestrators should delegate table mutation to the Iceberg writer contract instead of owning write semantics.
  • Semantic datasource binding: semantic plugins should consume compiled compute/catalog/storage bindings rather than duplicate connection logic.
  • RBAC and network policy generation: policy plugins should consume resolved service endpoints, Secret refs, and identity surfaces from deployment bindings.
IDAreaWorkExit Signal
PCU-001StorageAdd native S3 storage plugin designS3 plugin declares workload identity and bucket verification requirements
PCU-002CatalogAdd Glue catalog designGlue rejects incompatible S3-compatible storage and accepts native S3
PCU-003CatalogAdd Nessie catalog designNessie integration documents server-side vs client-side storage access
PCU-004IngestionAdd landing/quarantine/checkpoint bucket requirementsIngestion consumes storage bucket requirements
PCU-005SecurityConnect credential binding to identity/secrets pluginsImplemented: workload identity and external secret modes are resolver-validated
PCU-006NetworkGenerate network policies from deployment bindingsPolicies use plugin endpoints rather than static chart service assumptions
PCU-007Iceberg runtimeExtract writer contract from orchestrator export pathsDagster and future orchestrators delegate Iceberg table mutation to floe-iceberg