docs: add introduction for multi-project migration

See merge request !171

What
---
Add introduction for migration.

Why
---
It was suggested in
!164 (comment 1435952068)
to add a summary of the document.

Reference: https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/23961


Signed-off-by: Steve Xuereb <sxuereb@gitlab.com>

docs: decommission gitaly servers for migration

See merge request !170

What
---
Change the migration plan to start with the newest Gitaly severs
(nfs-file110) instead of the oldest one (file01)

Why
---
Before we where starting by draining `nfs-file01` first and then moving to
`nfs-file02` and onwards. However this becomes a problem when we want to
decommission the servers, we can't delete it because it's managed via
terraform. Deleting `nfs-file01` by hand will result in terraform state
drift and it's not something we can easily solve.

Reference: https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/24124


Signed-off-by: Steve Xuereb <sxuereb@gitlab.com>

Move the AI-gateway architecture to a blueprint

See merge request !169

This moves the AI-gateway architecture document to a blueprint in
`gitlab-org/gitlab`. This makes it easier to link to from other places
in the documentation there, and should make it easier to find for
people outside of infrastructure.

This needs to be merged after
gitlab-org/gitlab!126484

For
gitlab-org/modelops/applied-ml/code-suggestions/ai-assist#161

AI-gateway API & architecture

See merge request !166

This moves the code-gecko prompt up as above the `editor_content`
prompt-component to show that prompts can be built directly in the
monolith.

Update Zoekt readiness

See merge request !168

1. We remove the requirement that features cannot directly depend on a
   particular AI-provider. The prompts can live in the monolith. Prompt
   improvements won’t be available to older installations.

2. We still keep the requirement for using a structured API for a
   feature to become generally available. This allows us to ensure future
   scalability, security and composability.

3. The goal is to eventually be able to build entire features without
   having to touch the AI-gateway. Similar to Gitaly, it’s a cost to
   pay up-front, but it will pay off in the long run.

4. It is not easier to scale the existing monolith. We will isolate AI
   traffic via a dedicated webservice. We will define an upper bound on
   BC guarantee for AI endpoints. (major version + 1?)

This makes it clearer that multiple features could be using the same
kind of endpoint

Michelle Gill authored 1 year ago and Bob Van Landuyt committed 1 year ago

This explains that self managed instances using beta features could still be using the proxied endpoints

add items to ensure compliance logging is configured if required

See merge request !167

Tying the usage to maturity, experimental features could use this
while in development, but we should not ship an implementation like
this to customers with installations out of our control.

This avoids calling fields in a response from the `/suggestions`
endpoint prefixed with `suggestion`. Since it's coming from that
endpoint, that should already be clear.

For the metadata in telemetry requests, this moves the metadata about
the accepted suggestion into the payload.

Mention this so other implementations can opt for gRPC or websockets
in the future, if needed.

This explains the AI-gateway architecture, using code-suggestions as
an example.

It focuses on the design of feature specific endpoints that the
AI-gateway implements to support GitLab features using AI.

It also touches on how the AI gateway can be used as a proxy for AI
providers for features that GitLab currrently has that call out
directly to external providers.

It touches briefly on the architecture of the AI gateway with a
diagram and documents the way GitLab instances can communicate with
the AI gateway, including the protocol and the schema of the messages
being passed around.

Not covered but mentioned in this:
- Authentication on the AI-gateway
- Requesting and storing embeddings

**This is still being discussed and subject to change, don't make
assumptions or decisions based on this MR**

Add readiness review for cache in redis-cluster

See merge request !165