Keep namespace name in sync with CustomersDot

What does this MR do and why?

Ref issue: customers-gitlab-com#2902 (closed)

When the name for namespace changes in GitLab.com, no notice of the change is sent to CustomersDot.

As a result, the subscription information on CustomersDot gets out of sync and displays the outdated name within the customer's subscription page.

This MR delivers a sync mechanism to send the updated namespace name to CustomersDot upon namespace name update, behind the :sync_namespace_name_with_cdot Feature Flag.

Delivery plan

This logic is part of a bigger picture

• CustomersDot: Add endpoint that receives a namespace(id, name) and updates the namespace name for all the orders associated to this namespace: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3797
• GitLab: Add sync capabilities every time the name for a namespace with an associated subscription is updated: [THIS MR]

Rollout issue

#341056 (closed)

Screenshots or screen recordings

Does not apply. This is a backend change.

How to set up and validate locally

Enable the :sync_namespace_name_with_cdot feature flag by running:

Feature.enable(:sync_namespace_name_with_cdot)

With gdk, customers and ngrok running locally:

• Go to Gitlab -> Groups and update the name for an existing group.
• Locate the group name in CustomersDot (via the subscriptions page or directly in the DB (table orders) and make sure all occurrences of the old name are replaced with the new name.

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

• 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

• 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

• 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

• 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

• 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.

assigned to @vshumilo

added backend label

	1 Message
	CHANGELOG missing: If you want to create a changelog entry for GitLab FOSS, add the Changelog trailer to the commit message you want to add to the changelog. If you want to create a changelog entry for GitLab EE, also add the EE: true trailer to your commit message. If this merge request doesn't need a CHANGELOG entry, feel free to ignore this message.

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	Valery Sizov (@vsizov) (UTC+2, 7 hours ahead of @vshumilo)	Alex Kalderimis (@alexkalderimis) (UTC-4, 1 hour ahead of @vshumilo)

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.

Sidekiq queue changes

This merge request contains changes to Sidekiq queues. Please follow the documentation on changing a queue's urgency.

These queues were added:

• namespaces_sync_namespace_name

If needed, you can retry the danger-review job that generated this comment.

Generated by Danger

changed milestone to %14.3

added 1 commit

• 7abbff20 - Keep namespace name in sync with CustomersDot

Compare with previous version

added groupprovision sectionfulfillment typefeature labels

changed the description

marked the checklist item Confirmed as completed

marked the checklist item Confirmed as completed

marked the checklist item Confirmed as completed

marked the checklist item Confirmed as completed

marked the checklist item Confirmed as completed

Acceptance checklist followup

Based on the changelog entry requirement guidelines I consider these changes do not require an entry.

Based on the documentation requirement guidelines I consider these changes do not require documentation update.

added 1 commit

• fec92944 - Keep namespace name in sync with CustomersDot

Compare with previous version

Setting label(s) ~"Category:License" devopsfulfillment based on grouplicense.

added devopsfulfillment + 1 deleted label

added 1 commit

• 48633c5a - Keep namespace name in sync with CustomersDot

Compare with previous version

changed the description

marked this merge request as ready

@rcobb Would you please run the initial review for these changes? Thank you

requested review from @rcobb

changed the description

Thanks @vshumilo! One comment but otherwise this looks good. Back to you!

unrelated side note: This has me thinking about larger architectural changes like some sort of pub/sub system to keep attributes like this in sync. This current implementation works well if we only care about a couple of attributes but I imagine our interdependence will only continue to grow and keeping things in-sync between three services (gitlab, customers and zuora) will get increasingly difficult.

removed review request for @rcobb

changed the description

approved this merge request

@rcobb, 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:

• rspec minimal jobs
• jest minimal jobs
• merging a merge request.

@stanhu Would you please run the maintainer review for these changes when you have the opportunity?

TIA

requested review from @stanhu

removed review request for @stanhu

added 1 commit

• 833d44c9 - Keep namespace name in sync with CustomersDot

Compare with previous version

requested review from @stanhu

removed review request for @stanhu

requested review from @stanhu

removed review request for @stanhu

mentioned in issue #341056 (closed)

added 1 commit

• 1bdb376a - Set namespace name sync with Cdot behind FF

Compare with previous version

added feature flag label

removed feature flag label

added feature flag label

changed the description