[RUN AS-IF-FOSS] Add GraphQL mutation to control the weight of Canary Ingress
What does this MR do?
This MR adds the GraphQL mutation to control the weight of Canary Ingress.
Canary Ingress is the next-gen traffic control in Auto Deploy (a part of Auto DevOps) that allows users to accomplish advanced traffic routing technology. This special ingress is used in our Canary Deployments feature. We're working on the Canary Ingress integration within GitLab for letting users intuitively control the traffic without going through cumbersome CLI process.
This MR mainly adds the following functionalities:
- GraphQL mutation to update a weight (0-100) of a Canary Ingress in an environment.
-
Environments::CanaryIngress::UpdateService
that contains the main business logic
This MR is behind a feature flag canary_ingress_weight_control
which is disabled by default.
In the spirit of vertical slice, this MR contains all technical layers to complete the proposed feature (except documentation, which will be followed-up in a separate merge request). Hence, the change size of this MR is a bit intimidating, however, the change itself is pretty straight-forward.
Performance Implication
Since this GraphQL endpoint asks GitLab-Rails to communicate with user-owned Kubernetes cluster, it makes two external HTTP requests to complete the process. By this reason, this endpoint has a rate limiting. Users can update Canary Ingress once in a minute per environment. If more than one request happen in a minute, the GraphQL mutation denies user's request without causing any external HTTP requests, and notify users to retry the request later. Therefore, malicious users cannot abuse this endpoint for DDoS attack.
Manual QA
Executed the following GraphQL query:
mutation {
environmentsCanaryIngressUpdate(input:{
id: "gid://gitlab/Environment/29",
weight: 45
}) {
errors
}
}
GitLab returns the following response. If errors
is empty, the request succeeded.
{
"data": {
"environmentsCanaryIngressUpdate": {
"errors": []
}
}
}
Verified that the new weight is correctly reflected in the rollout status.
FYI, this GraphQL API will be used by ~frontend in the next milestone.
Does this MR meet the acceptance criteria?
Conformity
- [-] Changelog entry
- [-] Documentation (if required)
-
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. - [-] Tested in all supported browsers
- [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
- [-] Label as security and @ mention
@gitlab-com/gl-security/appsec
- [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
- [-] Security reports checked/validated by a reviewer from the AppSec team