[FLI-786] Flag Metadata

[markphelps]

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:

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]

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]

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

[pdonorio]

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"

[markphelps]

Now that #3196 is merged (thanks @kvnhmn and @erka !) we have a few more todos before this issue can be closed I think:

• [ ] Think about and implement CRUD metadata in the UI
• [ ] Support in our OpenFeature providers (https://openfeature.dev/specification/types/#flag-metadata)