Clarify the CloudConnector setup difference between SM and Gitlab.com and how developers can test it
- We should document how CC is configured and set up, and what the difference is between Gitlab.com and SM setup/configuration.
- We should also document the best way someone can setup and use CC AI features in their local environment.
CloudConnector Configuration gap between SM and COM
- For SM, we use cloud_connector.yml configuration as SSoT.
- We synchronize the
available_services
data from CDOT based on above configuration, and store them in CloudConnector::Access data table.
- We synchronize the
- For Gitlab.com, we use access_data.yml configuration as SSoT. (This is a copy of cloud_connector.yml file that lives on CDOT)
- We don't sync
CloudConnector::Access
with CDot (yet), so we read and rely on access_data.yml configuration instead.
- We don't sync
The configuration file is used to configure
- how the unit primitives are bundled with add-ons
- how they are accessed/grouped by service (user interface). Is it part of the Duo Chat platform or stand-alone feature.
- It also contains information about the cut-off date and minimum Gitlab versions per service.
- The scopes included in JWT instance token are based on this configuration file and your license/add_on purchase records.
This is the place where stage groups should add/configure UP
CloudConnector Access tokens
- For SM, we are refreshing the instance JWT access token from customers.gitlab.com. The scopes are issued based on the instance purchase record and how UP is configured in cloud_connector.yml file
- For .COM, the token is self-issued by Gitlab.com. The scopes are issued based on the user purchase record/seat_assignments and how UPs are configured in the access_data.yml file.
Testing CloudConnector features
Currently, there is no scalable/simple way to test CloudConnector AI features in your local environment.
For this to be scalable, as more and more developers would like to be able to test AI features in non-SaaS mode, it would be simplest if we could just use staging CDOT and staging AI Gateway. But as mentioned in https://gitlab.com/gitlab-org/fulfillment/meta/-/issues/1500#note_1647941219, there are some caveats:
- gitlab-developers have no means to purchase duo_pro add-on and add them to their license
- GitLab Team Member License is not the cloud license (It's a Legacy License).
The best approach would be if developers could request a cloud license for customers.staging.gitlab.com
with the duo_pro addon purchased, and they can simply configure their GDK environment.
For developers who are actively developing/working on our AI features, there are alternative options:
- Set up local AI Gateway and local CDOT - Setting up local CDOT requires help from the Fulfillment team, as it requires configuring Zuora secret keys.
- Set up local AI Gateway and run GDK in SAAS mode. - Setting up a local AI gateway for testing is fine if we use fake models. But could be challenging.
- Setup local AI gateway and seed CC data (create CloudConnector::Access data manually and self issue a token and store it in CloudConnector::ServiceAccessToken
The last alternative option Setup local AI gateway and seed CC data
would make sense to be expanded more and documented as a workaround until we have proper scalable solution instead of this troubleshooting that is not quite correct.
It would be helpful if we could provide a simple mechanism to seed missing data (rake task? similar or maybe part of a gitlab:duo:enable_feature_flags
)
This way, if someone is already running local AI Gateway, we could enable them to use CC AI feature immediately. See #462694 (comment 1914945224)