Identify opportunities for improving our Kubernetes version support
What is this about?
This issue is motivated by the following discussion triggered by @plu8 about having a global Kubernetes support policy to be adopted by all the teams which develop Kubernetes related features:
@Alexand
- It would be great if we can identify the overlapping. By comparing the Epics from groupdistribution and groupenvironments
Proposal
Origial proposal sumarized here:
🍎
Low hanging fruit
- Review K8S release log and identity any potential compatibility issue
We would share a parent epic on every new Kubernetes version. To share findings and match expectations. Then Ideally, we would only publicly adopt a new version when all the responsible teams have confirmed they are ready for it. We can simply keep doing what we already do, but start pinging all the groups that should be involved. I.e.:
- Open a child-epic of this very own epic with the title: 'Add support for Kubernetes version X.Y'
- Ping all the Product/Engineering managers to schedule the work to investigate the impact to their own features.
- Findings that might affect everyone are shared in the shared epic.
- Once all managers confirm they are ready, we can publicly announce adopting a new version.
But this depends on whether we agree that we should share the same upgrade policy.
👨👨👧👧
Groups developing Kubernetes related features There are at least five groups (maybe more?) are developing Kubernetes related features, and should be asked to validate their features against a new version:
- groupcomposition analysis
- groupdistribution
- grouprunner
- groupenvironments
- ~"group::editor"
- integrating Remote Development with KAS.
Possibly sharing and environment with automated testing for validation
This is one is challenging because we currently have many different environments.
If our QA test suite would be comprehensive enough to test all of our features, perhaps we could rely on a single shared pipeline, like so -- Deploy the GitLab chart with the Operator, then run all the QA tests against the new K8s version.
This could be the final validation of a new version. But unfortunately, it wouldn't be optimal to rely solely on this. For example, imagine there's a Kubernetes API deprecation that affects not only a GitLab feature, but also the GitLab installation itself. The group that owns the feature would only acknowledge the problem once groupdistribution fixes the pipeline to install GitLab at first place.
To avoid this, many of the GitLab features that use Kubernetes are not validated against a GitLab instance, but use unit tests which are good enough to verify problems faster. The features are sometimes also not all written completely in gitlab-org/gitlab
, but are developed through many dependency-chained upstream gitlab-org/x/y/z
projects managed by different groups. So adding support to a Kubernetes version might mean having to push merge request to all these upstream dependencies. Meaning, all these different projects will have different environments which are setup to do their unit tests against a certain Kubernetes version.
I.e., I don't think we could rely on sharing the same environment with all groups and solve all problems.
Kick starting
I think the best we can do immediately is to:
- Try to arrive at a common support policy.
📝 - Start with the low hanging fruit described above based on epic/issue documentation and communication.
🍎
Future Steps
Each group should work towards having all their features validated as part of our gitlab-qa
framework, so that a final supreme validation through a single CI/CD pipeline can be done. If we reach this point, then we don't need to get any specific DRI approval to announce support, but rather just trigger the CI/CD Pipeline.
Still, the DRI's will still have to be pinged when a new version is out, so they can start working on it.