Investigate a path forward to use "Gitlab Feature Flag API"as a source for a GitLab Open feature Provider
Context
We are considering creating a GitLab open feature provider, following discussions in #567 (comment 1517175303). Open feature providers adhere to a standardized API specification for feature flag use that is vendor-agnostic and community-driven.
The immediate use of the GitLab provider would be to evaluate development feature flags (ff) present in GitLab rails from within the container registry, however the long term goal is to allow usage of the provider across gitlab go applications.
By leveraging the gitlab features API as the ff retrieval source for the proposed Open feature provider, go applications that use the provider will get to continue to use the same processes that exist today within gitlab rails to manage development feature flags.
Goal
The goal of this issue is to understand how we can use the existing gitlab features API to retrieve the necessary feature flags from the rails API endpoint, A few questions worth considering:
-
What is required to retrieve feature flags from the endpoint and how do we obtain and store one? (e,g tokens) -
Are there any rate limiting in place for the gitlab features API -
What fallback strategies to consider if the provider (and/or cache) fails (hard coded default values? metrics/alerts?) -
What immediate caching strategies can be leveraged on the registry side to reduce calls to the gitlab features API and decrease synchronization drift from the API. -
Storage of secret needed for contacting the features API -
Which API specification from open feature do we need to focus on first to guarantee we can evaluate simple boolean flags
The outcome of this issue would be a plan (and issues under &11261) on how to proceed.