mirror of https://github.com/k3s-io/k3s
9925b68038
Automatic merge from submit-queue Curating Owners: cluster/juju cc @castrojo @mbruzek @chuckbutler @marcoceppi In an effort to expand the existing pool of reviewers and establish a two-tiered review process (first someone lgtms and then someone experienced in the project approves), we are adding new reviewers to existing owners files. If You Care About the Process: ------------------------------ We did this by algorithmically figuring out who’s contributed code to the project and in what directories. Unfortunately, that doesn’t work well: people that have made mechanical code changes (e.g change the copyright header across all directories) end up as reviewers in lots of places. Instead of using pure commit data, we generated an excessively large list of reviewers and pruned based on all time commit data, recent commit data and review data (number of PRs commented on). At this point we have a decent list of reviewers, but it needs one last pass for fine tuning. Also, see https://github.com/kubernetes/contrib/issues/1389. TLDR: ----- As an owner of a sig/directory and a leader of the project, here’s what we need from you: 1. Use PR https://github.com/kubernetes/kubernetes/pull/35715 as an example. 2. The pull-request is made editable, please edit the `OWNERS` file to remove the names of people that shouldn't be reviewing code in the future in the **reviewers** section. You probably do NOT need to modify the **approvers** section. Names asre sorted by relevance, using some secret statistics. 3. Notify me if you want some OWNERS file to be removed. Being an approver or reviewer of a parent directory makes you a reviewer/approver of the subdirectories too, so not all OWNERS files may be necessary. 4. Please use ALIAS if you want to use the same list of people over and over again (don't hesitate to ask me for help, or use the pull-request above as an example) |
||
|---|---|---|
| .. | ||
| addons | ||
| aws | ||
| azure | ||
| azure-legacy | ||
| centos | ||
| gce | ||
| gke | ||
| images | ||
| juju | ||
| kubemark | ||
| lib | ||
| libvirt-coreos | ||
| local | ||
| openstack-heat | ||
| ovirt | ||
| photon-controller | ||
| rackspace | ||
| saltbase | ||
| skeleton | ||
| ubuntu | ||
| vagrant | ||
| vsphere | ||
| OWNERS | ||
| README.md | ||
| common.sh | ||
| get-kube-binaries.sh | ||
| get-kube-local.sh | ||
| get-kube.sh | ||
| kube-down.sh | ||
| kube-push.sh | ||
| kube-up.sh | ||
| kube-util.sh | ||
| kubeadm.sh | ||
| kubectl.sh | ||
| log-dump.sh | ||
| options.md | ||
| restore-from-backup.sh | ||
| test-e2e.sh | ||
| test-network.sh | ||
| test-smoke.sh | ||
| update-storage-objects.sh | ||
| validate-cluster.sh | ||
README.md
Cluster Configuration
Deprecation Notice: This directory has entered maintenance mode and will not be accepting new providers. Please submit new automation deployments to kube-deploy. Deployments in this directory will continue to be maintained and supported at their current level of support.
The scripts and data in this directory automate creation and configuration of a Kubernetes cluster, including networking, DNS, nodes, and master components.
See the getting-started guides for examples of how to use the scripts.
cloudprovider/config-default.sh contains a set of tweakable definitions/parameters for the cluster.
The heavy lifting of configuring the VMs is done by SaltStack.