Create criteria for cloud providers to graduate to beta or GA
Decide and document criteria for a cloud provider to graduate to beta or GA status.
Things to consider:
- e2e tests
- e2e presubmit
- kops toolbox instance-selector
- UseKopsControllerForNodeBootstrap
- dns-controller
- apiserver node role
- instancegroup volumes
- serviceaccount IAM
- encryptEtcdStorage by default for new clusters
- private topology
- terraform target
- rolling-update surge
- non-legacy nodeidentity.Identifier (node labels from cloud tags)
- default NTP host
Things that are likely AWS specific, so out of scope:
- warm pools
- Vault for secretstore and keystore
- Cilium ENI IPAM
- Node Termination Handler
- IPv6
- ARM instances
- instance group tenancy
- external-dns (it's still feature flagged)
Feature-wise I think these are good points.
I also think we need some criterias around
- active maintainers
- access to dev environments
I doubt a cloud provider would meet whatever feature parity requirement we set without an active maintainer.
Does AWS even meet an "access to dev environments" requirement? My access to an AWS dev environment is through my employer, without which I would have to give AWS my credit card and risk four-figure bills due to AWS's lack of spending limits.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale /lifecycle frozen