(question) How to efficiently modify flagSet list

[alexjball]

Your question

flags within flagsets will be periodically retrieved and can be force refreshed via the admin api. Is there a similar mechanism to update the list of flagsets themselves? Our use case is adding PR-specific flagsets as part of ephemeral PR deploys. We can always update the mounted secret and restart the service but I was wondering if there is a way to trigger the service to re-load the config from file to avoid the restart.

Thank you!

[thomaspoignant]

Hello @alexjball
This is not currently possible for now to add / remove flag sets dynamically, but this is something we could look at.

Thinking about it, the only limits I will put is that we should keep a flag set immutable, meaning that we will not allow to modify an existing flag set without a restart of the service (to avoid being in a not stable state during the modification).

To implement it, we should probably use the Watch() function of koanf https://github.com/knadh/koanf?tab=readme-ov-file#watching-file-for-changes that allow to be notified on a configuration change.

Our use case is adding PR-specific flagsets as part of ephemeral PR deploys.

Also @alexjball I am curious on your use case, if you can tell me a bit more (here or on slack) it would be awesome.

[alexjball]

Use case is to be able to test changes to feature flag definitions in PR's:

• Production flags are deployed off main
• Developer opens feature branch, adds a flag, and opens a PR
• CI creates a new flagset for the pr based on the content of the flags file
• CI deploys application to pr-123-foobar.example.com which uses flags from the pr's flagset
• Testing passes, PR is merged, production flags are updated

We have separate prod and dev infrastructure, and PR deploys to dev. So it's not a problem to restart the service to update flagsets. I just wanted to make sure I wasn't missing existing watch functionality.

It makes sense only to allow adding new flagsets in watch updates.

Besides the above use case, per-customer flags would benefit from this. Currently provisioning a tenant requires a service restart which is quite heavyweight. Though if the goal is self-service onboarding, one might want flagsets to be even more dynamic. Would it simplify things to, say, only support dynamic flagsets when using the postgres retriever? In that case go feature flag would fully delegate flagset/flag management to the database.

[thomaspoignant]

FYI, I am working on a watcher on the config file of the relay proxy that will allow to add and remove flagsets.
I should enable what you want to do.