I’d like some guidance around use of namespaces. The only import/export filtering is on namespaces which makes them a tempting delimiter for cross-env federation, i.e. a central server configures all namespaces, which can be propagated out to the relevant envs only.
This makes it harder for teams to define contextual behaviours for all envs, i.e. compare values across all envs for a flag. in this case using some other mechanism for namespaces or use a default one would make sense, but I would end up pushing a lot of rules that would never apply to some edge nodes in those envs, although given how complex rules could get, perhaps this is reasonable to ensure consistent evaluation.
Some possible ways of dealing with this would be
Allow flags and segments to be defined as templates, which appear in all namespaces consistently (we could do this with automation ourselves via the API potentially). This way the effort around ensuring consistency across projects/envs is reduced
Treat some attributes as first class citizens, which are passed into the flipt nodes as injected parameters, e.g. a sidecar could interpolate pod name, deployment name, host, env and some other data, but env maybe would be something that is assumed to always exist, and could be exposed as a filter for import/export or an autogenerated segment
I think my worry is that namespaces as a generic concept make it hard to keep consistency across teams or envs, and that I feel like more functionality needs to be added to bridge the gap, would love some advice on this.
I totally get what you’re saying. I think, in hindsight, suggesting namespaces are useful as containers for environments was the wrong suggestion.
Namespaces are great for organizing collections of flags that have something in common (e.g. they belong to some team). And as a parameter for hanging authorization on. e.g. Team X can view namespaces A,B,C, but can edit D,E,F and so on. But they’re not adequate for namespaces.
In the declarative backends, we imagined that references would make better sense for environments. e.g. with Git, these are branches. You can then literally diff the two branches to understand the difference there. We’re thinking about how to bring this into the UI there, along with writes in general.
With OCI, you have tag in the repositories. This way you can e.g. have your environemnts organized as different folders in a repository before each folder is published to a different tag. Same actually can be done with git actually, there is a directory predicate which means you can run Flipt multiples times over a repo, each serving a different environment folder.
But that doesn’t help with the relation backends.
We could still introduce the concept of environments as first-class concept.
I wonder if there is a way we can make the experience work seemlessly across the backends
Makes sense, thanks for the clarifications and thoughts. I think having env as a first class citizen is only part of the puzzle, having a way of building consistency across namespaces/envs is whats needed, and that could be a manual external process but it would be great aided through tooling, for example
Allowing a centrally defined list of envs to be defined
Allowing rules, or segments to be defined as global, so they are visible across all namespaces, or can be exported and imported to different namespaces automatically via a filter
Evaluation views or flag views howing the breakdown of responses for different envs (simpler than a broad dag of rule evaluation)
I really like this idea and I think it would allow us to get pretty far with the problem of keeping namespaces in sync. It doesn’t solve the env problem though as you both discussed above. I guess we’d ultimately need to decide if we want to make envs a ‘first class’ thing which would be about the same amount of work that it took us to add namespaces (pretty large lift)
You’re not the first to suggest this either. The idea of the evaluation view demonstrating how a flag evaluates in across different parameters (e.g. env or even just for different context values, allowing you to compare the results).
This reminded me that another way folks have modelled environments is actually via segments. Since you can encode an environment name into a context, you can create segments which change the result of the flag based on that context key. Maybe combined with a evaluator in the UI which can compare the results of different contexts, you get a kind of way to compare a flags state across environments.
Sharing things like segments across namespaces is an interesting idea. Obviously, you have to introduce a new authz concept for that (authz is on its way), which says that user X can (read|write) global segments. Reminds me of Roles vs ClusterRoles in k8s.
