Watchers for changes in feature flag

[shilpashri]

Currently, we have polling mechanism which checks for configuration of go-feature-flag; though its optional by default polling happens every minute as specified here

Let us consider some scenarios:

• Changes to be made in feature flag shall not be frequent in real life scenario. It shall be updated only when there is a new feature added or when there is need to toggle between feature view for certain customer. So we can assume the changes shall be only after days.
• Once the changes are made in feature flag, the user would expect them to be reflected at the earliest. Hence, the polling has to be short; in a couple of seconds

Considering the above points regarding feature flag, it is very difficult to reach to a polling interval number satisfying both the situations. Hence, I would like to suggest to have watchers to keep a track on changes of go-feature-flag.

The advantages of using watcher:

• There need not be explicit polling interval per flag
• Open channel shall always listen to changes happening to feature flag
• More advantages here - https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes
• Once the changes are notified by the watcher, the further processing can be done

Kindly let know your thoughts.

Thanks
Shilpashri

[shilpashri]

Hi @thomaspoignant Did you get a chance to look at this? Thanks!

[thomaspoignant]

Hey @shilpashri, sorry I missed your post yesterday.

I think you've consider real things with your scenarios and I am totally aligned with what you say.

Changes to be made in feature flag shall not be frequent in real life scenario. It shall be updated only when there is a new feature added or when there is need to toggle between feature view for certain customer. So we can assume the changes shall be only after days.

This is true, despite if you are running a lot of flags configuration can change often but I agree that most of the time the configuration is stable.

Once the changes are made in feature flag, the user would expect them to be reflected at the earliest. Hence, the polling has to be short; in a couple of seconds

Yes an no, most of the times it is not a big deal to have a small delay before having the new value of the flag.
But that being said, if we can spread the change as soon as possible it is even better.

Considering the above points regarding feature flag, it is very difficult to reach to a polling interval number satisfying both the situations. Hence, I would like to suggest to have watchers to keep a track on changes of go-feature-flag.

The advantages of using watcher:

• There need not be explicit polling interval per flag
• Open channel shall always listen to changes happening to feature flag
• More advantages here - https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes
• Once the changes are notified by the watcher, the further processing can be done

Having a watcher mechanism is definitely something that I had in mind at some point.
The reason why we haven't invest much into this, is mainly because this is really Kubernetes specific and at that time the goal of the project was to be agnostic from where it runs.
That being said, now that GOFF has more stability we can possibly start thinking about adding such features that are specific to 1 platform.

Do you have any idea on how to implement it?

[shilpashri]

Hey @thomaspoignant, I was away for a while. Appreciate your patience.

One way would be to utilise kubernetes watcher; perhaps by utilising this - https://pkg.go.dev/k8s.io/apimachinery/pkg/watch

Or

we can have an open dedicated channel; and any change in the configmap shall be notified and we need to update

Once I find some time, I shall try to implement the same and raise a pull request here