Update the Infrasec portions of the Readiness template

See merge request !181

Updates the readiness template

See merge request !176

Cloud Seed Production Readiness Review

See merge request !125

docs: update gitaly naming convention

See merge request !177

What
---
- Document how we'll drain the group wiki repositories.
- Document how we'll drain the snippet wiki repositories.

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


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

What
---
Update the naming convention for Gitaly.

Why
---
In https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/24155+ we
had to rethink how our Gitaly servers are provisioned and ended up
ditching the `uid` idea since it became extremly hard to do single node
recovery.

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


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

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.