Skip to content

[self-hosted] Platform Support Matrix #2657

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
csweichel opened this issue Jan 4, 2021 · 2 comments
Closed

[self-hosted] Platform Support Matrix #2657

csweichel opened this issue Jan 4, 2021 · 2 comments
Assignees
Labels
meta: stale This issue/PR is stale and will be closed soon self-hosted

Comments

@csweichel
Copy link
Contributor

csweichel commented Jan 4, 2021

At the moment we have no defined set of platforms we support/test for with Gitpod Self-Hosted. We must produce a defined set of platforms we support, maintain this set and subsequently test those platforms. As a first step, we should produce this list and add it to the documentation.

The Platform Support Matrix would be structured along the following dimensions:

  • Kubernetes version
  • Operating System / Linux Distribution
  • Linux Kernel version
  • Kubernetes Platform Provider (e.g. GKE, Amazon EKS, Azure Kubernetes Service, Kubermatic)
  • Object Store (e.g. GCP Buckets, Amazon S3, MinIO)

For example:

Kubernetes Platform Provider Kubernetes Version Kernel Version Operating System Object Store
Google Kubernetes Engine 1.17 > 4.14 Ubuntu Containerd GCP Buckets
Amazon Elastic Container Service > 1.16 >= 5.0 TBD. Amazon S3
kubeadm 1.17 >= 5.0 Ubuntu 20.04 MinIO

We could also add another column to indicate something of a support/test level. I.e. there are probably many more combinations we expect to work but don't explicitly test. Also, we'll want to deprecate combinations in the future and should be able to mark them as deprecated.

@csweichel
Copy link
Contributor Author

We might want to split this up even for specific features. In general we're following a strategy best summed up as "common features with common requirements; specialised features can use specialised requirements".

For example:

  • common feature, common requirements: when user-namespaced workspaces become the default, this feature must not impose specialised requirements anymore (e.g. Ubuntu as OS)
  • specialised feature, specialised requirement: dynamic resource limiting done by ws-daemon requires containerd in a particular version.

On top of the matrix described above, we should explicitly list what we consider specialised features, and what requirements they impose.

@stale
Copy link

stale bot commented Mar 16, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the meta: stale This issue/PR is stale and will be closed soon label Mar 16, 2021
@stale stale bot closed this as completed Mar 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta: stale This issue/PR is stale and will be closed soon self-hosted
Projects
None yet
Development

No branches or pull requests

2 participants