Skip to content

Add toggle to create self-monitoring project

A service to create the self-monitoring project was created as part of #26370 (closed).

We need a space for users to trigger the creation of the self-monitoring project.

How we got here

There was a discussion (#26370 (comment 215605616)) about having a button in the admin area on the original issue.

We first tried creating the self-monitoring project automatically via a migration. However, there were a couple of problems with that:

  1. Migrations do not run on new instances. We solved this by adding a production DB fixture.
  2. The migration caused failures (including in downstream repos):
    1. gitlab-org/charts/gitlab#1565 (closed) was a failure in the downstream charts repo caused by the migration needing object storage to be configured.
    2. #13877 (closed) was a heisunbug that we could not reproduce and was not widely reported
    3. gitlab-org/charts/gitlab#1550 (closed) was a spec failure that occurred because the migration was expecting runner secrets to exist in the spec.
    4. #32178 (closed) and gitlab-foss#66540 (closed) were bugs in our migration spec setup code which was not caused by the migration but was triggered by it.
    5. gitlab-foss!32945 (comment 216019821), gitlab-foss#67349 (moved): This was an issue that required a version check in new code as a workaround, due to the migration and its spec using application code.
  3. Also, in general, using application code in migrations is discouraged. (https://docs.gitlab.com/ee/development/migration_style_guide.html#data-migration, https://docs.gitlab.com/ee/development/background_migrations.html#isolation)
  4. A potential issue was reported in https://gitlab.com/gitlab-org/gitlab/issues/31867#note_216658186, due to which we pulled the migration until we can find a better solution.

Design

We can add a section for creating the self-monitoring project in the admin settings for Metrics and Profiling:

Collapsed view Expanded view Project created
admin-area-settings-1 admin-area-settings-2 admin-area-settings-3
  • When the project is successfully created or deleted, we should have a toast message communicating this to users.
  • We should have a confirmation modal verifying that the user wants to delete the self-monitoring project if/when they decide to turn this functionality off.

Implementation

MR Status Details
!21235 (merged) Merged 1. A Sidekiq worker for creating the self-monitoring project. It will store the output of the CreateService in Redis. The job ID will be part of the Redis key (self_monitoring_create_result:#{job_id}).
!21428 (merged) Merged 1. A POST API which will schedule the worker to create the self-monitoring project and return the job ID in the response, along with the path of the API which can be used to check status of the job.

2. A GET API for checking the status of the "Create" job, which takes a job ID as parameter. The job ID is required to construct the redis key that contains the service output. The API will return the service output if it has completed, or it will set the polling header and expect the frontend to poll this API.
!21995 (merged) Merged A DeleteService for deleting the self monitoring project.
!21402 (merged) Merged 1. A Sidekiq worker to run the DeleteService. It will store the output of the service in Redis. The job ID will be part of the Redis key (self_monitoring_delete_result:#{job_id}).
!22428 (merged) Merged Move common requests specs into shared_examples.
!21431 (merged) Merged 1. A DELETE API which will schedule the worker to delete the self-monitoring project and return the job ID in the response, along with the path of the API which can be used to check status of the job.

2. A GET API for checking the status of the "Delete" job, which takes a job ID as parameter. The job ID is required to construct the redis key that contains the service output. The API will return the service output if it has completed, or it will set the polling header and expect the frontend to poll this API.

Backend APIs

There are 4 APIs:

  1. POST /admin/application_settings/create_self_monitoring_project(.:format)

    Triggers an async job to create the self-monitoring project.

    • Takes no parameters.

    • Returns {job_id: job_id , monitor_status: path of status API}. The job_id can be passed to the GET status API.

  2. GET /admin/application_settings/status_create_self_monitoring_project(.:format)

    This API can be polled to get the status of the create job.

    • Takes a job_id as parameter (optional).

    • Returns status 204 with a message ({message: message}) if the job is in progress.

    • Returns 200 with {project_id: project_id, project_full_path: relative_path} if self-monitoring project has been created.

    • Returns 400 with a message if project has not been created and job_id is invalid.

    • This API can be called without the job_id as well. It will return 200 if the project has been created, or 400 if not.

  3. DELETE /admin/application_settings/delete_self_monitoring_project(.:format)

    Triggers an async job to delete the self-monitoring project.

    • Takes no parameters.

    • Returns {job_id: job_id , monitor_status: path of status API}. The job_id can be passed to the GET status API.

  4. GET /admin/application_settings/status_delete_self_monitoring_project(.:format)

    This API can be polled to get the status of the delete job.

    • Takes a job_id as parameter (optional).

    • Returns status 204 with a message if the job is in progress.

    • Returns 200 with a message if self-monitoring project has been deleted.

    • Returns 400 with a message if project has not been deleted and job_id is invalid.

    • This API can be called without the job_id as well. It will return 200 if the project has been deleted, or 400 if not.

Edited by Reuben Pereira