Ensure we’re directing users towards the Kubernetes Agent
This issue links to other issues and epics that we aim to ship in order to direct users towards the GitLab Kubernetes Agent, instead of the legacy integrations and to ensure that the UI and documentation is easy to follow for them.
Issues and MRs might be linked as related, while epics need to be added here in the description.
Scope
Many changes have been done already. This scope is defined on 2021-12-21 and focuses on the work ahead of us.
The following table lists all the major topics using two categories:
- Feature development (including necessary documentation changes)
- Documentation changes
and a few statuses:
- An in progress
👷 item is actively being worked on - The planned
⏳ status means that the issue is well understood and is on the roadmap, we should get started with the development as our bandwidth allows. - The status solution validation
🤔 means that technical investigation is needed before moving on with the development. This investigation is likely planned already but development is not started yet. -
Problem validation
❓ means that we need more insights from our users and a better understanding of the problem space to make sure we can deliver a superior product without wasting development resources. -
Done
✅ is considered done, only minor follow-up issues are expected
| # | Topic | Type | Status |
|---|---|---|---|
| 1 | Ensure that Auto DevOps works with the Agent (review apps) | Feature development | Done |
| 2 | Change the GitLab provided Terraform templates from certificate-connections to Agent-based connections (EKS, GKE) | Feature development | Done |
| 3 | Simplify the experience of getting started with the Agent (multiple issues) | Feature development | Done |
| 4 | Provide minimal observability around agent-based connections | Feature development | In progress |
| 5 | Provide some level of dashboarding for managed Kubernetes resources (an alpha feature is acceptable) | Feature development | Solution validation |
| 6 | Validate the requirements for the previous "GitLab Managed Clusters", and come up with an alternative implementation that serves our users at least as well as GMC did | Feature development | Solution validation |
| 7 | Provide support for scaling deployments with GitOps, likely via support for templating tools | Feature development | Problem validation |
| 9 | Focus the installation docs on installing agentk, mentioning kas as a pre-requisite |
Documentation only | Done |
| 9 | Create a page for GitOps deployments, merge the inventory object page into it | Documentation only | Done |
| 10 | Extend the "Deploy and Release" page with deployment content, focusing on Kubernetes and the Agent | Documentation only | Done |
| 11 | Rename from "GitLab Kubernetes Agent" to "GitLab Agent for Kubernetes" everywhere | Documentation only | Done |
| 12 | Support migrating from cert-based to agent-based connections | Documentation only | Done |
| 13 | Deprecate the certificate-based integrations | Feature development | In progress |
Epics
- Deprecate the certificate based cluster integration - highlights all the related features that need to be deprecated and discusses an action plan to make the least harm along the way by providing migration plans where possible and needed
- New infrastructure management navigation structure in the docs
- Review the docs to make the content Agent focused
Weekly update
Weekly updates are provided below using the following template
## Weekly update: 2021-mm-dd
Edited by Viktor Nagy (GitLab)