Change 'Mac OS X' and OS X' to 'macOS'
Mac OS X was renamed to OS X in 2012, and then renamed again to macOS in 2016. I suggest that the current name (macOS) should be used whenever referencing the Apple OS.
This commit is contained in:
Patrik Erdes
parent
1791183e5d
commit
8798cc13a6
|
|
@ -5,7 +5,7 @@ The current local cluster experience is sub-par and often not functional.
|
|||
There are several options to setup a local cluster (docker, vagrant, linux processes, etc) and we do not test any of them continuously.
|
||||
Here are some highlighted issues:
|
||||
- Docker based solution breaks with docker upgrades, does not support DNS, and many kubelet features are not functional yet inside a container.
|
||||
- Vagrant based solution are too heavy and have mostly failed on OS X.
|
||||
- Vagrant based solution are too heavy and have mostly failed on macOS.
|
||||
- Local linux cluster is poorly documented and is undiscoverable.
|
||||
From an end user perspective, they want to run a kubernetes cluster. They care less about *how* a cluster is setup locally and more about what they can do with a functional cluster.
|
||||
|
||||
|
|
@ -15,7 +15,7 @@ From an end user perspective, they want to run a kubernetes cluster. They care l
|
|||
From a high level the goal is to make it easy for a new user to run a Kubernetes cluster and play with curated examples that require least amount of knowledge about Kubernetes.
|
||||
These examples will only use kubectl and only a subset of Kubernetes features that are available will be exposed.
|
||||
|
||||
- Works across multiple OSes - OS X, Linux and Windows primarily.
|
||||
- Works across multiple OSes - macOS, Linux and Windows primarily.
|
||||
- Single command setup and teardown UX.
|
||||
- Unified UX across OSes
|
||||
- Minimal dependencies on third party software.
|
||||
|
|
@ -68,7 +68,7 @@ This is only a part of the overall local cluster solution.
|
|||
|
||||
The kube-up.sh script included in Kubernetes release supports a few Vagrant based local cluster deployments.
|
||||
kube-up.sh is not user friendly.
|
||||
It typically takes a long time for the cluster to be set up using vagrant and often times is unsuccessful on OS X.
|
||||
It typically takes a long time for the cluster to be set up using vagrant and often times is unsuccessful on macOS.
|
||||
The [Core OS single machine guide](https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagrant-single.html) uses Vagrant as well and it just works.
|
||||
Since we are targeting a single command install/teardown experience, vagrant needs to be an implementation detail and not be exposed to our users.
|
||||
|
||||
|
|
@ -90,8 +90,8 @@ For running and managing the kubernetes components themselves, we can re-use [S
|
|||
Localkube is a self-contained go binary that includes all the master components including DNS and runs them using multiple go threads.
|
||||
Each Kubernetes release will include a localkube binary that has been tested exhaustively.
|
||||
|
||||
To support Windows and OS X, minikube will use [libmachine](https://github.com/docker/machine/tree/master/libmachine) internally to create and destroy virtual machines.
|
||||
Minikube will be shipped with an hypervisor (virtualbox) in the case of OS X.
|
||||
To support Windows and macOS, minikube will use [libmachine](https://github.com/docker/machine/tree/master/libmachine) internally to create and destroy virtual machines.
|
||||
Minikube will be shipped with an hypervisor (virtualbox) in the case of macOS.
|
||||
Minikube will include a base image that will be well tested.
|
||||
|
||||
In the case of Linux, since the cluster can be run locally, we ideally want to avoid setting up a VM.
|
||||
|
|
@ -105,7 +105,7 @@ Alternatives to docker for running the localkube core includes using [rkt](https
|
|||
|
||||
To summarize the pipeline is as follows:
|
||||
|
||||
##### OS X / Windows
|
||||
##### macOS / Windows
|
||||
|
||||
minikube -> libmachine -> virtualbox/hyper V -> linux VM -> localkube
|
||||
|
||||
|
|
@ -126,7 +126,7 @@ minikube -> docker -> localkube
|
|||
##### Cons
|
||||
|
||||
- Not designed to be wrapped, may be unstable
|
||||
- Might make configuring networking difficult on OS X and Windows
|
||||
- Might make configuring networking difficult on macOS and Windows
|
||||
- Versioning and updates will be challenging. We can mitigate some of this with testing at HEAD, but we'll - inevitably hit situations where it's infeasible to work with multiple versions of docker.
|
||||
- There are lots of different ways to install docker, networking might be challenging if we try to support many paths.
|
||||
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ instructions](http://releases.k8s.io/HEAD/build/README.md).
|
|||
Kubernetes development helper scripts assume an up-to-date GNU tools
|
||||
environment. Recent Linux distros should work out-of-the-box.
|
||||
|
||||
Mac OS X ships with outdated BSD-based tools. We recommend installing [OS X GNU
|
||||
macOS ships with outdated BSD-based tools. We recommend installing [macOS GNU
|
||||
tools].
|
||||
|
||||
### etcd
|
||||
|
|
@ -171,7 +171,7 @@ see [Build with Bazel].
|
|||
To check out code to work on, please refer to [this guide](/contributors/guide/github-workflow.md).
|
||||
|
||||
|
||||
[OS X GNU tools]: https://www.topbug.net/blog/2013/04/14/install-and-use-gnu-command-line-tools-in-mac-os-x
|
||||
[macOS GNU tools]: https://www.topbug.net/blog/2013/04/14/install-and-use-gnu-command-line-tools-in-mac-os-x
|
||||
[build/build-image/cross]: https://git.k8s.io/kubernetes/build/build-image/cross
|
||||
[build/common.sh]: https://git.k8s.io/kubernetes/build/common.sh
|
||||
[e2e-image]: https://git.k8s.io/test-infra/jenkins/e2e-image
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ passing, so it is often a good idea to make sure the e2e tests work as well.
|
|||
* The preferred method of testing multiple scenarios or input is
|
||||
[table driven testing](https://github.com/golang/go/wiki/TableDrivenTests)
|
||||
- Example: [TestNamespaceAuthorization](https://git.k8s.io/kubernetes/test/integration/auth/auth_test.go)
|
||||
* Unit tests must pass on OS X and Windows platforms.
|
||||
* Unit tests must pass on macOS and Windows platforms.
|
||||
- Tests using linux-specific features must be skipped or compiled out.
|
||||
- Skipped is better, compiled out is required when it won't compile.
|
||||
* Concurrent unit test runs must pass.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Updated: 1/24/2018
|
|||
- https://google.github.io/styleguide/shell.xml
|
||||
|
||||
- Ensure that build, release, test, and cluster-management scripts run on
|
||||
OS X
|
||||
macOS
|
||||
|
||||
- Go
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ example, see [TestNamespaceAuthorization](https://git.k8s.io/kubernetes/test/int
|
|||
[end-to-end (test/e2e) tests](/contributors/devel/e2e-tests.md)
|
||||
- Including new kubectl commands and major features of existing commands
|
||||
|
||||
- Unit tests must pass on OS X and Windows platforms - if you use Linux
|
||||
- Unit tests must pass on macOS and Windows platforms - if you use Linux
|
||||
specific features, your test case must either be skipped on windows or compiled
|
||||
out (skipped is better when running Linux specific commands, compiled out is
|
||||
required when your code does not compile on Windows).
|
||||
|
|
|
|||
Loading…
Reference in New Issue