[FLI-786] Flag Metadata

markphelps commented 5 months ago

Problem

Often feature flags are tied to pull requests, GitHub issues, or other internal documents

It would be nice if we had a way to record and track generic flag metadata per flag.

This lines up with the OpenFeature flag metadata type as well: https://openfeature.dev/specification/types/#flag-metadata

Ideal Solution

This is a large feature request as it will touch almost all of the code including:

API GRPC + Rest
UI
Storage (Relational and Declarative)
Import/Export
Validation (flipt validate)
SDKs (at least open feature)

I think it will however unlock potential future features

I've created a mockup of the UI:

metadata

The gist is:

Support generic key/value pairs per flag
Keys will be strings
Values can be strings, bools or numbers
Likely store these as JSON or individual rows in backing datastores (relational)
Flag metadata should likely be returned on evaluation, per the OpenFeature spec (link above)

Again we need to break this down into smaller issues to track the various pieces above, but from an API perspective this could be either added as fields to the existing UpdateFlag request, where all of the metadata would need to be provided at once on update, or we could add new APIs like CreateFlagMetadata, UpdateFlagMetadata, DeleteFlagMetadata.

Wanted to open this up for discussion

Search

[X] I searched for other open and closed issues before opening this

Additional Context

No response

_{From SyncLinear.com | FLI-786}

GeorgeMac commented 5 months ago

Great shout. My 2 cents would be to err on the side of make it a parameter of flag (on CreateFlag, UpdateFlag). This is a property of flag, could also be a property of segment. However, creating it as its own isolated resource, to me furthers the over normalization which I think we already do with other resources (variants, rules etc.). We wont want to list metadata and paginate it and so on. At-least I cant see a valid usecase for that. Also, I would probably just keep metadata to string key/value pairs and let clients parse it if necessary. But that is just me being influenced by k8s.

markphelps commented 5 months ago

^yeah I think I agree on using the existing CreateFlag, UpdateFlag RPCs for this

pdonorio commented 3 months ago

This turned out to fit our use case where we would like to add a generic comment in one of the field that is not a description, e.g. "to be removed after xyz"

flipt-io / flipt