Make SM configurable with a token for Code Suggestions
Context
To support our PoC and the first iteration for Code suggestions API for SM users with SaaS redirect, we need to configure the SM instance with the access token.
Using this token, the SM instance authenticates itself against the SaaS instance and obtains a JWT token to access the model.
You could refer to step 3
from the diagram: #411676 (closed)
In the future, the plan is to use Service Accounts or Cloud Licensing to do SM instance <=> SaaS - instance level authentication.
For our initial iteration, PAT (Personal Access Token) obtained by SM admin using their gitlab.com Account is a starting solution.
Focus of this issue
- Provide SM instance admin with the ability to configure their instance with PAT we'll use for Code Suggestion auth flow. The solutions will be discussed below.
- Simplify our PoC and the first iteration diff by providing an API in the code to access PAT for SM instance (whether it's ENV var or instance setting). We want to split this aspect entirely out of PoC to make one less thing to discuss there.
Implementation options
There are two main ways we configure SM instances: ENV var and application setting.
aspect | ENV var | Application Setting | Separate table + FE |
---|---|---|---|
Requires changes to the code | No, we just rely on the contract with SM admin that it's provided | Yes, potentially a little | Yes, more than other options, probably separate FE logic and so on |
Requires SM instance restart to make changes | Yes (not convenient) | No | No |
Deprecation/Change process (e.g. changing the name or switching to Service Accounts) | TBD | TBD. We could name it "abstractly", e.g. "ai_token" to avoid renames in the future when we'll move PAT -> SAs. If we decide to go with our table, we'll migrate a number of fields to it | Probably the most convenient in terms of evolving the data because it's our table |
Make it visible for early adopters only | We just share ENV var configuration instructions with early adopters | We need some FF to show the setting only to those who are selected and hide it from most SM instances during the early adoption phase | Similar to application setting |
Docs changes needed | On adding ENV var | On enabling FF to make the setting visible if we don't enable for every SM. Describe configuring PAT with the new setting | Similar to application setting |
Summary
Taking into account the instance restart is inconvenient for our SM users, there is a strong argument for Application Setting.
Also, it's much easier to guide our users toward enabling it.
The only potential downside is that we may change or deprecate this setting entirely during the relatively near future, so we need to understand the setting deprecation process and if there are any challenges associated with that.