Skip to content
Snippets Groups Projects

Allow Geo node status updates during maintenance mode

Merged Michael Kozono requested to merge mk/fix-geo-node-status-when-maintenance-mode-is-on into master
All threads resolved!

What does this MR do and why?

Describe in detail what your merge request does and why.

Geo secondary sites regularly build a status and POST it to the primary so the primary can save it. When maintenance mode is on, the primary is rejecting those POST requests.

This MR allows those requests so that admins can still observe Geo node statuses while maintenance mode is on.

Resolves #292983 (closed)

To do

  • Test locally that the primary currently rejects those POST requests
  • Test locally that this change allows those POST requests to work
  • Add specs

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

  1. Set up Geo https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/geo.md
  2. View /admin/geo/nodes to confirm the status is Healthy
  3. Enable maintenance mode https://docs.gitlab.com/ee/administration/maintenance_mode/
  4. Wait 15 minutes
  5. View /admin/geo/nodes to confirm the status is Healthy

MR acceptance checklist

These checklists encourage us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Quality

  • Quality checklist confirmed
  1. I have self-reviewed this MR per code review guidelines.
  2. For the code that that this change impacts, I believe that the automated tests (Testing Guide) validate functionality that is highly important to users (including consideration of all test levels). If the existing automated tests do not cover this functionality, I have added the necessary additional tests or I have added an issue to describe the automation testing gap and linked it to this MR.
  3. I have considered the technical aspects of the impact of this change on both gitlab.com hosted customers and self-hosted customers.
  4. I have considered the impact of this change on the front-end, back-end, and database portions of the system where appropriate and applied frontend, backend and database labels accordingly.
  5. I have tested this MR in all supported browsers, or determiend that this testing is not needed.
  6. I have confirmed that this change is backwards compatible across updates, or I have decided that this does not apply.
  7. I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
  8. If I am introducing a new expectation for existing data, I have confirmed that existing data meets this expectation or I have made this expectation optional rather than required.

Performance, reliability, and availability

  • Performance, reliability, and availability checklist confirmed
  1. I am confident that this MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
  2. I have added information for database reviewers in the MR description, or I have decided that it is unnecessary. (Does this MR have database-related changes?)
  3. I have considered the availability and reliability risks of this change. I have also considered the scalability risk based on future predicted growth
  4. I have considered the performance, reliability and availability impacts of this change on large customers who may have significantly more data than the average customer.

Documentation

  • Documentation checklist confirmed
  1. I have included changelog trailers, or I have decided that they are not needed. (Does this MR need a changelog?)
  2. I have added/updated documentation, or I have decided that documentation changes are not needed for this MR. (Is documentation required?)

Security

  • Security checklist confirmed
  1. I have confirmed that if this MR contains changes to processing or storing of credentials or tokens, authorization, and authentication methods, or other items described in the security review guidelines, I have added the label security and I have @-mentioned @gitlab-com/gl-security/appsec.

Deployment

  • Deployment checklist confirmed
  1. I have considered using a feature flag for this change because the change may be high risk. If I decided to use a feature flag, I plan to test the change in staging before I test it in production, and I have considered rolling it out to a subset of production customers before doing rolling it out to all customers. When to use a feature flag
  2. I have informed the Infrastructure department of a default setting or new setting change per definition of done, or decided that this is not needed.
Edited by Michael Kozono

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Michael Kozono
  • Michael Kozono requested review from @marc_shaw

    requested review from @marc_shaw

  • Michael Kozono marked the checklist item Quality checklist confirmed as completed

    marked the checklist item Quality checklist confirmed as completed

  • Michael Kozono marked the checklist item Performance, reliability, and availability checklist confirmed as completed

    marked the checklist item Performance, reliability, and availability checklist confirmed as completed

  • Michael Kozono marked the checklist item Documentation checklist confirmed as completed

    marked the checklist item Documentation checklist confirmed as completed

  • Michael Kozono marked the checklist item Security checklist confirmed as completed

    marked the checklist item Security checklist confirmed as completed

  • Michael Kozono marked the checklist item Deployment checklist confirmed as completed

    marked the checklist item Deployment checklist confirmed as completed

  • Michael Kozono mentioned in merge request !69748 (merged)

    mentioned in merge request !69748 (merged)

  • Michael Kozono added 262 commits

    added 262 commits

    Compare with previous version

  • Marc Shaw
  • Marc Shaw removed review request for @marc_shaw

    removed review request for @marc_shaw

  • Marc Shaw approved this merge request

    approved this merge request

  • :wave: @marc_shaw, thanks for approving this merge request.

    This is the first time the merge request is approved. To ensure full test coverage, a new pipeline has been started.

    For more info, please refer to the following links:

  • Michael Kozono added 1 commit

    added 1 commit

    • 2157108e - Geo: Fix maintenance mode causing Unhealthy secondary status

    Compare with previous version

  • Michael Kozono requested review from @brodock

    requested review from @brodock

  • Gabriel Mazetto
  • @mkozono I have two minor suggestions only

  • Michael Kozono added 1 commit

    added 1 commit

    • 1586b48e - Apply 1 suggestion(s) to 1 file(s)

    Compare with previous version

  • Michael Kozono added 626 commits

    added 626 commits

    Compare with previous version

  • 🤖 GitLab Bot 🤖 changed milestone to %14.4

    changed milestone to %14.4

  • Gabriel Mazetto approved this merge request

    approved this merge request

  • Gabriel Mazetto resolved all threads

    resolved all threads

  • Gabriel Mazetto enabled an automatic merge when the pipeline for 94023927 succeeds

    enabled an automatic merge when the pipeline for 94023927 succeeds

  • @mkozono LGTM! I've set it to MWPS :rocket:

  • Gabriel Mazetto mentioned in commit aa29d65f

    mentioned in commit aa29d65f

  • added workflowcanary label and removed workflowstaging label

  • added workflowproduction label and removed workflowcanary label

  • mentioned in issue #292983 (closed)

  • mentioned in issue #338620 (closed)

  • Please register or sign in to reply
    Loading