Put backend workspaces logic behind feature flag
MR: Put backend workspaces logic behind feature flag (!119152 - merged)
Overview
There is a single feature flag, remote_development_feature_flag
. This is a development type flag which disables all
- all graphql endpoints,
- the controller which renders the Vue UI,
- the
internal/kubernetes/modules/remote_development/reconcile
andinternal/kubernetes/authorize_proxy_user
endpoints.
Description
Put everything behind the feature flag on the remote_dev
branch.
We will do this by putting guard clauses in the API to throw exception if flag isn't on: in the GraphQL create/update, and in the REST kubernetes internal API method.
We will also put the UI behind the flag, by making the controller return a 404 if it's not enabled.
Tasks
(TODO: more details to list including actual endpoint paths)
-
Add guards to all endpoints - GraphQL
-
GraphQL Workspace create
-
GraphQL Workspace update
-
GraphQL root QueryType workspace
byid
field (see https://docs.gitlab.com/ee/development/api_graphql_styleguide.html#feature-flagged-field) -
GraphQL root QueryType workspaces
byids
field -
GraphQL User interface workspaces
field
-
- REST
- QUESTION: Do these need to use the
ops
flag type? https://docs.gitlab.com/ee/development/feature_flags/#ops-type ? Asked on slack -
REST internal kubernetes workspace reconcile: internal/kubernetes/modules/remote_development/reconcile
-
REST internal kubernetes agent config (existing endpoint that is used by other GA4K features, but we should put guard around our part of the request logic): internal/kubernetes/authorize_proxy_user
- QUESTION: Do these need to use the
- GraphQL
-
Add guard to controller to return 404 for UI if flag is off -
Update documentation with references on how to enable feature flags.
Edited by Chad Woolley