Add new feature flag type called `worker`
What does this MR do and why?
Add new feature flag type called worker
This feature flag type is similar to undefined
where the feature flag
names are not defined in the GitLab codebase. Each feature flag's name
might have the worker name in it. These feature flags will
be used to control the behavior of Sidekiq workers dynamically, e.g.
deferring jobs from runaway workers during an incident.
Changelog: added
Resolves gitlab-com/gl-infra/scalability#2345.
More context can be found in the epic gitlab-com/gl-infra&1004 (closed) and this discussion.
The immediate usage of this new type of feature flag is at Defer Sidekiq jobs from worker type feature flags (!120606 - merged)
How to set up and validate locally
-
Checking for a random feature flag will follow the
default_enabled_if_undefined
behavior[1] pry(main)> Feature.enabled?(:some_feature_flag, type: :worker, default_enabled_if_undefined: false) Feature::FlipperGate Load (0.3ms) SELECT "feature_gates".* FROM "feature_gates" WHERE "feature_gates"."feature_key" = 'some_feature_flag' /*application:console,db_config_name:main,console_hostname:Gregoriuss-MBP,console_username:gregoriusmarco,line:/lib/feature.rb:237:in `block in current_feature_value'*/ => false [2] pry(main)> Feature.enabled?(:some_feature_flag, type: :worker, default_enabled_if_undefined: true) => true
-
Turn on that feature flag from API (requires to create a personal access token first):
$ curl -s -H "PRIVATE-TOKEN: $PERSONAL_ACCESS_TOKEN" http://gdk.test:3000/api/v4/features/some_feature_flag --data "value=true" | jq { "name": "some_feature_flag", "state": "on", "gates": [ { "key": "boolean", "value": true } ], "definition": null }
-
Check again if the feature is enabled:
[4] pry(main)> Feature.enabled?(:some_feature_flag, type: :worker, default_enabled_if_undefined: false) => true [5] pry(main)> Feature.enabled?(:some_feature_flag, type: :worker, default_enabled_if_undefined: true) => true
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Merge request reports
Activity
assigned to @marcogreg
added groupscalability sectionplatforms teamFrameworks labels
added devopsplatforms label
added featureaddition typefeature labels
- A deleted user
added backend label
1 Message This merge request adds or changes documentation files. A review from the Technical Writing team before you merge is recommended. Reviews can happen after you merge. Documentation review
The following files require a review from a technical writer:
-
doc/development/feature_flags/index.md
(Link to current live version)
The review does not need to block merging this merge request. See the:
-
Metadata for the
*.md
files that you've changed. The first few lines of each*.md
file identify the stage and group most closely associated with your docs change. - The Technical Writer assigned for that stage and group.
- Documentation workflows for information on when to assign a merge request for review.
Reviewer roulette
Changes that require review have been detected!
Please refer to the table below for assigning reviewers and maintainers suggested by Danger in the specified category:
Category Reviewer Maintainer backend Halil Coban (
@halilcoban
) (UTC+2)Terri Chu (
@terrichu
) (UTC-4)To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.
To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.
Once you've decided who will review this merge request, assign them as a reviewer! Danger does not automatically notify them for you.
If needed, you can retry the
danger-review
job that generated this comment.Generated by
Danger-
- A deleted user
added documentation label
marked the checklist item I have evaluated the MR acceptance checklist for this MR. as completed
changed milestone to %16.0
- Resolved by Mehmet Emin INAC
@mksionek Would you mind giving an initial review for this, please?
requested review from @mksionek
mentioned in merge request !120606 (merged)
@mksionek
, thanks for approving this merge request.This is the first time the merge request is approved. To ensure full test coverage, a new pipeline will be started shortly.
For more info, please refer to the following links:
added pipeline:mr-approved label
- Resolved by Marco (Gregorius)
@marcogreg - This change looks good to me but could you please show an example of how we are going to defer/drop the jobs based on the FF value?
enabled an automatic merge when the pipeline for f3a73587 succeeds
@minac, did you forget to run a pipeline before you merged this work? Based on our code review process, if the latest pipeline was created more than 6 hours ago OR finished more than 2 hours ago, you should:
- Ensure the merge request is not in Draft status.
- Start a pipeline (especially important for Community contribution merge requests).
- Set the merge request to merge when pipeline succeeds.
This is a guideline, not a rule. Please consider replying to this comment for transparency.
This message was generated automatically. You're welcome to improve it.
mentioned in commit 4443f9fc
added workflowstaging-canary label
added workflowcanary label and removed workflowstaging-canary label
added workflowstaging label and removed workflowcanary label
added workflowproduction label and removed workflowstaging label
added workflowpost-deploy-db-staging label and removed workflowproduction label
added releasedcandidate label
mentioned in merge request kubitus-project/kubitus-installer!2224 (merged)