Skip to content

Move SyncServiceTokenWorker to CC namespace. Iteration 1

Aleksei Lipniagov requested to merge 439570-move-SyncServiceTokenWorker-from-ai-to-cc-namespace into master

What does this MR do and why?

We want to move SyncServiceTokenWorker from Ai:: to CloudConnector:: namespace.

This worker is only used for Self-Managed. To keep GitLab fully backward-compatible and forward-compatible, as described in https://docs.gitlab.com/ee/development/sidekiq/compatibility_across_updates.html, we need to do it in three steps (3 milestones):

  • 16.9: Introduce an identical worker with a new name. Keep the old named worker in 16.9 in case something is already scheduled.
  • 16.10: Replace the references of the Ai::SyncServiceTokenWorker with CloudConnector::SyncServiceTokenWorker. This can't be done in the same milestone as previous step (16.9) to avoid the situation when the new application code schedules a job that will be executed on the Sidekiq with the old application code (will result in unknown const).
  • 16.11: Drop the old name.

Implementation choice

To start with, we don't the case or renaming the worker covered in docs (I will consider opening an MR to solve this later): https://docs.gitlab.com/ee/development/sidekiq/compatibility_across_updates.html

My original approach was to rely on https://github.com/sidekiq/sidekiq/wiki/FAQ#how-do-i-safely-rename-a-worker and do something similar. So in the ee/app/workers/ai/sync_service_token_worker.rb I wanted to introduce an alias:

module Ai
  SyncServiceTokenWorker = CloudConnector::SyncServiceTokenWorker

but I noticed that after running bin/rake gitlab:sidekiq:all_queues_yml:generate (required), the queue metadata for the original queue is being removed, which does not seem backward & forward- compatible. So I decided to play safe and keep both classes and queues for one milestone.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

How to set up and validate locally

Manual testing aims to check that both old ::Ai::SyncServiceTokenWorker and ::CloudConnector::SyncServiceTokenWorker could be executed.

  • Firstly, you need to run CustomersDot locally, connect it to your GitLab instance, and have a valid Cloud license issued to your GitLab instance.
  • Make sure FF is enabled for your local CDot instance: cloud_connector_available_services.
  • On your local GitLab, pull this branch
  • Open rails console: export GITLAB_LICENSE_MODE=test && export CUSTOMER_PORTAL_URL='http://localhost:5000' && bundle exec rails c (adjust CDot URL accordingly)
  • Delete all records from the CC Access table: CloudConnector::Access.delete_all
  • Run the job with the old name: ::Ai::SyncServiceTokenWorker.perform_sync
  • Check that it worked: CloudConnector::Access.last (main focus is the absence of missing const type of errors)
  • Again, delete all records from the CC Access table: CloudConnector::Access.delete_all
  • Run the job with the new name: ::CloudConnector::SyncServiceTokenWorker.perform_sync
  • Check that it worked: CloudConnector::Access.last

Related to #439570 (closed)

Edited by Aleksei Lipniagov

Merge request reports