diff options
| author | Daniel Smith <dbsmith@google.com> | 2015-07-13 17:13:09 -0700 |
|---|---|---|
| committer | Daniel Smith <dbsmith@google.com> | 2015-07-13 17:48:40 -0700 |
| commit | b8889dc9532b5b58504d8b0ab52df2d5c386e449 (patch) | |
| tree | 26c079dac82595dee7877228641f52df61e85497 | |
| parent | 37813afc4bc36b2f617cdac0233e1d02b45352eb (diff) | |
Apply mungedocs changes
| -rw-r--r-- | README.md | 3 | ||||
| -rw-r--r-- | api_changes.md | 2 | ||||
| -rw-r--r-- | cherry-picks.md | 2 | ||||
| -rw-r--r-- | coding-conventions.md | 3 | ||||
| -rw-r--r-- | collab.md | 2 | ||||
| -rw-r--r-- | developer-guides/vagrant.md | 2 | ||||
| -rw-r--r-- | development.md | 6 | ||||
| -rw-r--r-- | faster_reviews.md | 3 | ||||
| -rw-r--r-- | flaky-tests.md | 2 | ||||
| -rw-r--r-- | getting-builds.md | 2 | ||||
| -rw-r--r-- | instrumentation.md | 2 | ||||
| -rw-r--r-- | issues.md | 2 | ||||
| -rw-r--r-- | logging.md | 2 | ||||
| -rw-r--r-- | making-release-notes.md | 3 | ||||
| -rw-r--r-- | profiling.md | 2 | ||||
| -rw-r--r-- | pull-requests.md | 3 | ||||
| -rw-r--r-- | releasing.md | 2 | ||||
| -rw-r--r-- | scheduler.md | 2 | ||||
| -rw-r--r-- | scheduler_algorithm.md | 6 | ||||
| -rw-r--r-- | writing-a-getting-started-guide.md | 4 |
20 files changed, 47 insertions, 8 deletions
@@ -47,4 +47,7 @@ Docs in this directory relate to developing Kubernetes. * **Getting Recent Builds** ([getting-builds.md](getting-builds.md)): How to get recent builds including the latest builds to pass CI. + +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> diff --git a/api_changes.md b/api_changes.md index 3ad1847d..3a0c1991 100644 --- a/api_changes.md +++ b/api_changes.md @@ -356,4 +356,6 @@ the change gets in. If you are unsure, ask. Also make sure that the change gets TODO(smarterclayton): write this. +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> diff --git a/cherry-picks.md b/cherry-picks.md index 03f2ebb5..04811f0b 100644 --- a/cherry-picks.md +++ b/cherry-picks.md @@ -46,4 +46,6 @@ against a release is a GitHub query: For example, [this query is all of the v0.21.x cherry-picks](https://github.com/GoogleCloudPlatform/kubernetes/pulls?utf8=%E2%9C%93&q=is%3Apr+%22automated+cherry+pick%22+base%3Arelease-0.21) +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> diff --git a/coding-conventions.md b/coding-conventions.md index e61398ee..54d9aaa6 100644 --- a/coding-conventions.md +++ b/coding-conventions.md @@ -20,5 +20,6 @@ Coding style advice for contributors - https://gist.github.com/lavalamp/4bd23295a9f32706a48f - +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> @@ -54,4 +54,6 @@ PRs that are incorrectly judged to be merge-able, may be reverted and subject to Any maintainer or core contributor who wants to review a PR but does not have time immediately may put a hold on a PR simply by saying so on the PR discussion and offering an ETA measured in single-digit days at most. Any PR that has a hold shall not be merged until the person who requested the hold acks the review, withdraws their hold, or is overruled by a preponderance of maintainers. +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> diff --git a/developer-guides/vagrant.md b/developer-guides/vagrant.md index 1316e26b..1b716648 100644 --- a/developer-guides/vagrant.md +++ b/developer-guides/vagrant.md @@ -351,4 +351,6 @@ export KUBERNETES_MINION_MEMORY=2048 ```vagrant suspend``` seems to mess up the network. It's not supported at this time. +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> diff --git a/development.md b/development.md index 157f49d6..ba9b9897 100644 --- a/development.md +++ b/development.md @@ -281,8 +281,8 @@ go run hack/e2e.go -v -ctl='delete pod foobar' ## Conformance testing End-to-end testing, as described above, is for [development -distributions](../../docs/devel/writing-a-getting-started-guide.md). A conformance test is used on -a [versioned distro](../../docs/devel/writing-a-getting-started-guide.md). +distributions](writing-a-getting-started-guide.md). A conformance test is used on +a [versioned distro](writing-a-getting-started-guide.md). The conformance test runs a subset of the e2e-tests against a manually-created cluster. It does not require support for up/push/down and other operations. To run a conformance test, you need to know the @@ -300,4 +300,6 @@ hack/run-gendocs.sh ``` +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> diff --git a/faster_reviews.md b/faster_reviews.md index 99e60fb1..eb3b25e9 100644 --- a/faster_reviews.md +++ b/faster_reviews.md @@ -190,5 +190,6 @@ a bit of thought into how your work can be made easier to review. If you do these things your PRs will flow much more easily. - +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> diff --git a/flaky-tests.md b/flaky-tests.md index ee93bf19..d26fc406 100644 --- a/flaky-tests.md +++ b/flaky-tests.md @@ -76,4 +76,6 @@ If you do a final check for flakes with ```docker ps -a```, ignore tasks that ex Happy flake hunting! +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> diff --git a/getting-builds.md b/getting-builds.md index 5a1a4dde..770d486c 100644 --- a/getting-builds.md +++ b/getting-builds.md @@ -35,4 +35,6 @@ gsutil ls gs://kubernetes-release/release # list all official re ``` +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> diff --git a/instrumentation.md b/instrumentation.md index 762d1980..22cd38e1 100644 --- a/instrumentation.md +++ b/instrumentation.md @@ -47,4 +47,6 @@ https://github.com/prometheus/client_golang/blob/master/prometheus/histogram.go https://github.com/prometheus/client_golang/blob/master/prometheus/summary.go +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> @@ -33,4 +33,6 @@ Definitions * untriaged - anything without a priority/X label will be considered untriaged +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> @@ -40,4 +40,6 @@ The following conventions for the glog levels to use. [glog](http://godoc.org/g As per the comments, the practical default level is V(2). Developers and QE environments may wish to run at V(3) or V(4). If you wish to change the log level, you can pass in `-v=X` where X is the desired maximum level to log. +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> diff --git a/making-release-notes.md b/making-release-notes.md index 0dfbeebe..877c1364 100644 --- a/making-release-notes.md +++ b/making-release-notes.md @@ -47,5 +47,6 @@ With the final markdown all set, cut and paste it to the top of ```CHANGELOG.md` * Press Save. - +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> diff --git a/profiling.md b/profiling.md index 51635424..41737414 100644 --- a/profiling.md +++ b/profiling.md @@ -48,4 +48,6 @@ to get 30 sec. CPU profile. To enable contention profiling you need to add line ```rt.SetBlockProfileRate(1)``` in addition to ```m.mux.HandleFunc(...)``` added before (```rt``` stands for ```runtime``` in ```master.go```). This enables 'debug/pprof/block' subpage, which can be used as an input to ```go tool pprof```. +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> diff --git a/pull-requests.md b/pull-requests.md index e82d2d00..1c6bbe5f 100644 --- a/pull-requests.md +++ b/pull-requests.md @@ -42,4 +42,7 @@ Once those requirements are met, they will be labeled [ok-to-merge](https://gith These restrictions will be relaxed after v1.0 is released. + +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> diff --git a/releasing.md b/releasing.md index 29e685cf..5cdbde2f 100644 --- a/releasing.md +++ b/releasing.md @@ -314,4 +314,6 @@ by plain mortals (in a perfect world PR/issue's title would be enough but often it is just too cryptic/geeky/domain-specific that it isn't). +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> diff --git a/scheduler.md b/scheduler.md index 3e1ae0e1..d9fccefc 100644 --- a/scheduler.md +++ b/scheduler.md @@ -61,4 +61,6 @@ If you want to get a global picture of how the scheduler works, you can start in [plugin/cmd/kube-scheduler/app/server.go](../../plugin/cmd/kube-scheduler/app/server.go) +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> diff --git a/scheduler_algorithm.md b/scheduler_algorithm.md index 96789422..119b0c86 100644 --- a/scheduler_algorithm.md +++ b/scheduler_algorithm.md @@ -14,7 +14,7 @@ certainly want the docs that go with that version.</h1> <!-- END MUNGE: UNVERSIONED_WARNING --> # Scheduler Algorithm in Kubernetes
-For each unscheduled Pod, the Kubernetes scheduler tries to find a node across the cluster according to a set of rules. A general introduction to the Kubernetes scheduler can be found at [docs/devel/scheduler.md](../../docs/devel/scheduler.md). In this document, the algorithm of how to select a node for the Pod is explained. There are two steps before a destination node of a Pod is chosen. The first step is filtering all the nodes and the second is ranking the remaining nodes to find a best fit for the Pod.
+For each unscheduled Pod, the Kubernetes scheduler tries to find a node across the cluster according to a set of rules. A general introduction to the Kubernetes scheduler can be found at [scheduler.md](scheduler.md). In this document, the algorithm of how to select a node for the Pod is explained. There are two steps before a destination node of a Pod is chosen. The first step is filtering all the nodes and the second is ranking the remaining nodes to find a best fit for the Pod.
## Filtering the nodes
The purpose of filtering the nodes is to filter out the nodes that do not meet certain requirements of the Pod. For example, if the free resource on a node (measured by the capacity minus the sum of the resource limits of all the Pods that already run on the node) is less than the Pod's required resource, the node should not be considered in the ranking phase so it is filtered out. Currently, there are several "predicates" implementing different filtering policies, including:
@@ -44,7 +44,9 @@ Currently, Kubernetes scheduler provides some practical priority functions, incl - `CalculateSpreadPriority`: Spread Pods by minimizing the number of Pods belonging to the same service on the same node.
- `CalculateAntiAffinityPriority`: Spread Pods by minimizing the number of Pods belonging to the same service on nodes with the same value for a particular label.
-The details of the above priority functions can be found in [plugin/pkg/scheduler/algorithm/priorities](../../plugin/pkg/scheduler/algorithm/priorities/). Kubernetes uses some, but not all, of these priority functions by default. You can see which ones are used by default in [plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go](../../plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go). Similar as predicates, you can combine the above priority functions and assign weight factors (positive number) to them as you want (check [docs/devel/scheduler.md](../../docs/devel/scheduler.md) for how to customize). +The details of the above priority functions can be found in [plugin/pkg/scheduler/algorithm/priorities](../../plugin/pkg/scheduler/algorithm/priorities/). Kubernetes uses some, but not all, of these priority functions by default. You can see which ones are used by default in [plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go](../../plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go). Similar as predicates, you can combine the above priority functions and assign weight factors (positive number) to them as you want (check [scheduler.md](scheduler.md) for how to customize). +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> diff --git a/writing-a-getting-started-guide.md b/writing-a-getting-started-guide.md index 7b94d9a3..dec4d9c9 100644 --- a/writing-a-getting-started-guide.md +++ b/writing-a-getting-started-guide.md @@ -43,7 +43,7 @@ These guidelines say *what* to do. See the Rationale section for *why*. search for uses of flags by guides. - We may ask that you host binary assets or large amounts of code in our `contrib` directory or on your own repo. - - Setup a cluster and run the [conformance test](../../docs/devel/development.md#conformance-testing) against it, and report the + - Setup a cluster and run the [conformance test](development.md#conformance-testing) against it, and report the results in your PR. - Add or update a row in [The Matrix](../../docs/getting-started-guides/README.md). - State the binary version of kubernetes that you tested clearly in your Guide doc and in The Matrix. @@ -113,4 +113,6 @@ These guidelines say *what* to do. See the Rationale section for *why*. +<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() +<!-- END MUNGE: GENERATED_ANALYTICS --> |