Allow environments/storage backends to be optional (skip if unavailable) #5477
ChristianMurphy
started this conversation in
Ideas
Replies: 1 comment 3 replies
-
|
Hey @ChristianMurphy. Is there anything that blocks you from doing something like this in your Dockerfile? FROM docker.flipt.io/flipt/flipt:v2
USER root
RUN apk add git && mkdir -p /repo && git init /repo && chown -R flipt:flipt /repo && apk del git
USER flipt |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Problem
We bake a single
flipt-config.yamlinto a Docker image that runs in both production (ECS) and local development (Docker Compose). Our config defines two environments:file:///repo) for quick local iterationThe
/repopath only exists in the local dev docker-compose setup. In production, Flipt crashes at startup with:The failure happens during environment store initialization, before any fetch policy logic applies. This means a single config can't gracefully degrade based on what's available at runtime.
What we've tried
fetch_policy: "lenient"on the local storage backend. Doesn't help. The error occurs during initial store setup (local path resolution), not during a remote fetch.lenientonly covers remote connectivity failures.FLIPT_environment variable overrides: great for scalar values, but there's no clean way to add or remove an entirestorageblock orenvironmentsentry via env vars.Entrypoint scripts with
yqto assemble config at startup: this works, but adds operational complexity (extra tooling in the image, conditional logic in the entrypoint, harder to reason about what config Flipt actually sees).Proposed solutions
Here are a few options we'd love the maintainers' perspective on:
Option A:
optional: trueon an environmentThe simplest conceptual change. If the storage backend for an environment fails to initialize, log a warning and skip it instead of crashing.
Option B: Extend
fetch_policy: "lenient"to cover local path failuresToday
lenientonly handles remote fetch errors. Broadening it to also tolerate a missing local repo path (treating it as "empty state" rather than a fatal error) would make the existing mechanism cover this use case naturally.Option C: Support multiple config files with merge semantics
Allow
--configto accept multiple paths or a glob, with later files merged on top of earlier ones. The local-only config would only be mounted in dev:This is a pattern used by tools like Docker Compose, Helm, and many others.
Context
This seems like a natural extension of the
fetch_policywork in v2.3.0 (#4920, #4965). The underlying need is the same: "don't crash when a configured backend isn't available at runtime." The current implementation covers remote connectivity failures but not missing local paths, which creates a gap for teams using a single image across environments.Happy to discuss further or contribute if any of these directions make sense!
Beta Was this translation helpful? Give feedback.
All reactions