Repurpose Gitaly SRE Subpage to GitLab AWS SRE Subpage

What does this MR do?

Creates a GitLab SRE for AWS subpage under implementation patterns and moves the existing Gitaly SRE content there and adds a "Known Issues" section.

Known Issues points to an issues list in AWS alliances via a tag query.

The interested parties for tracking known issues are:

• GitLab Alliances for AWS - we should rightly be expected to know about the challenges. Tracking these issues at our level also exerts leadership.
• GitLab SREs running GitLab on AWS - this community should be able to easily find, interact and subscribe to known issues. Customers and GitLab Channel Partners - what is the status of known issues and what is a complete list of known issues for a platform partner.
• AWS Partner Manager Team - to help keep focus and easy reference to top issues.
• AWS Product Teams - drive issues and us having a listing will help AWS product teams understand when something is important enough to be handled at a partnership level.
• GitLab Product Teams - by enhancing visibility of these issues at the partner level we can be transparent about what issues are important to and being managed through our partnership.

This MR is proposing a two prong solution:

Prong 1 - Meta-issues with a Label Create “meta-issues” in our AWS public tracker that represent “Alliances team issues that are being tracked and possibly worked” These issues can use issue links to link out to an aggregate of technical issues - but they represent the status / tracking at the AWS Alliance Partner level. A new label in our AWS public tracker “AWS Known Issue” to isolate these. Examples: https://gitlab.com/gitlab-com/alliances/aws/public-tracker/-/issues?label_name%5B%5D=AWS+Known+Issue

Prong 2 - A link from a GitLab SRE for AWS page under implementation patterns. The Gitaly SRE for AWS sub-page was a precursor to this page. In this MR I proposing the Gitaly SRE for AWS become GitLab SRE for AWS and the Gitaly content becomes sections. A new section “Known Issues” explains the disposition on known issues and a link to the above Issue query. Conceptually other future segments in this page would be things like:

• Upgrading GitLab Database AWS PostgreSQL RDS to a new PostgreSQL version safely (TESTED)
• Upgrading Redis Elasticache to a new Elasticache version safely (TESTED)
• Upgrading Gitaly Cluster running on AWS safely (TESTED) - updating GitLab software version, updating hardware capacity, updating underlying AMIs.

EFFICIENCY Through:

• meta-issues - anyone - partners, customers, internal can subscribe to an overall resolution status and avoid having to track a random list of many issues.
• By having a label - the documentation on the web site does not need to be updated every time an issue is discovered or resolved.

TRANSPARENCY Through:

• easy for entire internal and external GitLab+AWS Ecosystem to find and track known issues.

Author's checklist

• Consider taking the GitLab Technical Writing Fundamentals course
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• Ensure that the product tier badge is added to topic's h1.
• Request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

Review checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review.
• Ensure a release milestone is set.

Review App Direct Links

http://main-ee-69250.178.62.207.141.nip.io/ee/install/aws/gitlab_sre_for_aws.html