Skip to content

feat: adopt GitOps-native feature flags (flagd + OpenFeature Operator) + formalize the progressive-delivery layers #2510

Description

@devantler

🤖 Generated by the Daily AI Assistant

Part of devantler-tech/monorepo#2059 (feature-flag-first delivery portfolio-wide).

Problem

The platform has no per-request/per-feature runtime flag layer. New app or infra behaviour goes live on reconcile; there is no GitOps-native way to land a feature off, validate it, and flip it on — and no standard convention distinguishing the tools that already exist (Flagger, Helm toggles) from a real flag system.

Proposed direction

Layer feature control the GitOps-native way, using the four independent layers (top = coarsest):

  1. Runtime per-request flags — [flagd] + [OpenFeature Operator] (the new capability). Deploy the OpenFeature Operator declaratively; keep flag definitions in Git as FeatureFlag CRs (group core.openfeature.dev/v1beta1) reconciled + self-healed by Flux. Use flagd-proxy mode (pub/sub watch of the CRs) so workload pods don't need cluster-wide API RBAC. GitOps caveat: exclude the operator-created ClusterRoleBinding from Flux reconciliation so it doesn't fight the mutating webhook.
  2. Version rollout / traffic shifting — [Flagger] (already deployed): formalize it as the release/canary toggle layer (zero manifest changes, metric-analysed auto-rollback) — the answer to "is this build safe to shift traffic to?", distinct from per-user flags.
  3. Coarse component on/off — Helm values ({{- if .Values.x.enabled }}) + Kustomize overlays as the low-tech gate (prefer values for simple on/off; reserve patches for what values can't express).
  4. Platform behaviour — Kubernetes --feature-gates (alpha/beta/GA) remain orthogonal, owned by Talos/kubeadm config.

Add CI validation of flag definitions against the flagd JSON schema, and a flag-lifecycle discipline: naming convention, owner/expiry/purpose metadata, and stale-flag cleanup (release flags removed after rollout). Record the chosen mechanism in platform/AGENTS.md ## Maintenance. Tenant web apps (wedding-app, ascoachingogvaner) then consume this flagd layer rather than each rolling their own.

Rough size

L — decompose: (1) OFO + flagd-proxy install + one example FeatureFlag CR, off, validated; (2) flag-def CI schema check; (3) document the four-layer model + Flagger release-toggle convention in AGENTS.md.

References

OpenFeature Operator https://github.com/open-feature/open-feature-operator · flagd syncs https://flagd.dev/concepts/syncs/ · Flagger https://flagger.app

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    Status
    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions