Merge pull request #11452 from thockin/docs-munge-headerlines

Munge headerlines

17 files changed, 41 insertions, 0 deletions

diff --git a/README.md b/README.md
index a06efc8d..9a73d949 100644
--- a/README.md
+++ b/README.md
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
+
 # Kubernetes Developer Guide
 
 The developer guide is for anyone wanting to either write code which directly accesses the
diff --git a/api-conventions.md b/api-conventions.md
index 271efed4..c2d71078 100644
--- a/api-conventions.md
+++ b/api-conventions.md
@@ -456,6 +456,7 @@ The following HTTP status codes may be returned by the API.
   * Returned in response to HTTP OPTIONS requests.
 
 #### Error codes
+
 * `307 StatusTemporaryRedirect`
   * Indicates that the address for the requested resource has changed.
   * Suggested client recovery behavior
diff --git a/api_changes.md b/api_changes.md
index edf227cc..7a0418e8 100644
--- a/api_changes.md
+++ b/api_changes.md
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
+
 # So you want to change the API?
 
 The Kubernetes API has two major components - the internal structures and
@@ -365,6 +366,7 @@ $ hack/update-swagger-spec.sh
 The API spec changes should be in a commit separate from your other changes.
 
 ## Incompatible API changes
+
 If your change is going to be backward incompatible or might be a breaking change for API
 consumers, please send an announcement to `kubernetes-dev@googlegroups.com` before
 the change gets in. If you are unsure, ask. Also make sure that the change gets documented in
diff --git a/cherry-picks.md b/cherry-picks.md
index 1d59eaef..7ed63d08 100644
--- a/cherry-picks.md
+++ b/cherry-picks.md
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
+
 # Overview
 
 This document explains cherry picks are managed on release branches within the
diff --git a/cli-roadmap.md b/cli-roadmap.md
index 45c26827..00b454fa 100644
--- a/cli-roadmap.md
+++ b/cli-roadmap.md
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
+
 # Kubernetes CLI/Configuration Roadmap
 
 See also issues with the following labels:
diff --git a/client-libraries.md b/client-libraries.md
index ae7cb623..69cba1e6 100644
--- a/client-libraries.md
+++ b/client-libraries.md
@@ -30,12 +30,15 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
+
 ## kubernetes API client libraries
 
 ### Supported
+
    * [Go](../../pkg/client/)
 
 ### User Contributed
+
 *Note: Libraries provided by outside parties are supported by their authors, not the core Kubernetes team*
 
    * [Java (OSGI)](https://bitbucket.org/amdatulabs/amdatu-kubernetes)
diff --git a/collab.md b/collab.md
index 38b6d586..96db64c8 100644
--- a/collab.md
+++ b/collab.md
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
+
 # On Collaborative Development
 
 Kubernetes is open source, but many of the people working on it do so as their day job.  In order to avoid forcing people to be "at work" effectively 24/7, we want to establish some semi-formal protocols around development.  Hopefully these rules make things go more smoothly.  If you find that this is not the case, please complain loudly.
diff --git a/developer-guides/vagrant.md b/developer-guides/vagrant.md
index 2b6fcc42..e704bf3b 100644
--- a/developer-guides/vagrant.md
+++ b/developer-guides/vagrant.md
@@ -30,11 +30,13 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
+
 ## Getting started with Vagrant
 
 Running kubernetes with Vagrant (and VirtualBox) is an easy way to run/test/develop on your local machine (Linux, Mac OS X).
 
 ### Prerequisites
+
 1. Install latest version >= 1.6.2 of vagrant from http://www.vagrantup.com/downloads.html
 2. Install one of:
    1. The latest version of Virtual Box from https://www.virtualbox.org/wiki/Downloads
@@ -371,6 +373,7 @@ export KUBERNETES_MINION_MEMORY=2048
 ```
 
 #### I ran vagrant suspend and nothing works!
+
 ```vagrant suspend``` seems to mess up the network.  It's not supported at this time.
 
 
diff --git a/development.md b/development.md
index e258f841..6822ab5e 100644
--- a/development.md
+++ b/development.md
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
+
 # Development Guide
 
 # Releases and Official Builds
@@ -45,6 +46,7 @@ Kubernetes is written in [Go](http://golang.org) programming language. If you ha
 Below, we outline one of the more common git workflows that core developers use. Other git workflows are also valid.
 
 ### Visual overview
+
 ![Git workflow](git_workflow.png)
 
 ### Fork the main repository
@@ -93,6 +95,7 @@ $ git push -f origin myfeature
 ```
 
 ### Creating a pull request
+
 1. Visit http://github.com/$YOUR_GITHUB_USERNAME/kubernetes
 2. Click the "Compare and pull request" button next to your "myfeature" branch.
 
@@ -102,6 +105,7 @@ $ git push -f origin myfeature
 Kubernetes uses [godep](https://github.com/tools/godep) to manage dependencies. It is not strictly required for building Kubernetes but it is required when managing dependencies under the Godeps/ tree, and is required by a number of the build and test scripts. Please make sure that ``godep`` is installed and in your ``$PATH``.
 
 ### Installing godep
+
 There are many ways to build and host go binaries. Here is an easy way to get utilities like ```godep``` installed:
 
 1) Ensure that [mercurial](http://mercurial.selenic.com/wiki/Download) is installed on your system. (some of godep's dependencies use the mercurial
@@ -124,6 +128,7 @@ export PATH=$PATH:$GOPATH/bin
 ```
 
 ### Using godep
+
 Here's a quick walkthrough of one way to use godeps to add or update a Kubernetes dependency into Godeps/_workspace. For more details, please see the instructions in [godep's documentation](https://github.com/tools/godep).
 
 1) Devote a directory to this endeavor:
@@ -259,6 +264,7 @@ go run hack/e2e.go --down
 ```
 
 ### Flag options
+
 See the flag definitions in `hack/e2e.go` for more options, such as reusing an existing cluster, here is an overview:
 
 ```sh
@@ -309,6 +315,7 @@ go run hack/e2e.go -v -ctl='delete pod foobar'
 ```
 
 ## Conformance testing
+
 End-to-end testing, as described above, is for [development
 distributions](writing-a-getting-started-guide.md).  A conformance test is used on
 a [versioned distro](writing-a-getting-started-guide.md).
@@ -320,6 +327,7 @@ intended to run against a cluster at a specific binary release of Kubernetes.
 See [conformance-test.sh](../../hack/conformance-test.sh).
 
 ## Testing out flaky tests
+
 [Instructions here](flaky-tests.md)
 
 ## Regenerating the CLI documentation
diff --git a/faster_reviews.md b/faster_reviews.md
index 20e3e990..d28e9b55 100644
--- a/faster_reviews.md
+++ b/faster_reviews.md
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
+
 # How to get faster PR reviews
 
 Most of what is written here is not at all specific to Kubernetes, but it bears
diff --git a/flaky-tests.md b/flaky-tests.md
index 0fbf643c..1e7f5fcb 100644
--- a/flaky-tests.md
+++ b/flaky-tests.md
@@ -30,7 +30,9 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
+
 # Hunting flaky tests in Kubernetes
+
 Sometimes unit tests are flaky.  This means that due to (usually) race conditions, they will occasionally fail, even though most of the time they pass.
 
 We have a goal of 99.9% flake free tests.  This means that there is only one flake in one thousand runs of a test.
diff --git a/getting-builds.md b/getting-builds.md
index f59a753b..4c92a446 100644
--- a/getting-builds.md
+++ b/getting-builds.md
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
+
 # Getting Kubernetes Builds
 
 You can use [hack/get-build.sh](../../hack/get-build.sh) to or use as a reference on how to get the most recent builds with curl. With `get-build.sh` you can grab the most recent stable build, the most recent release candidate, or the most recent build to pass our ci and gce e2e tests (essentially a nightly build).
diff --git a/making-release-notes.md b/making-release-notes.md
index 343b9203..d76f7415 100644
--- a/making-release-notes.md
+++ b/making-release-notes.md
@@ -30,10 +30,13 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
+
 ## Making release notes
+
 This documents the process for making release notes for a release.
 
 ### 1) Note the PR number of the previous release
+
 Find the most-recent PR that was merged with the previous .0 release.  Remember this as $LASTPR.
 _TODO_: Figure out a way to record this somewhere to save the next release engineer time.
 
@@ -46,6 +49,7 @@ ${KUBERNETES_ROOT}/build/make-release-notes.sh $LASTPR $CURRENTPR
 ```
 
 ### 3) Trim the release notes
+
 This generates a list of the entire set of PRs merged since the last minor
 release.  It is likely long and many PRs aren't worth mentioning.  If any of the
 PRs were cherrypicked into patches on the last minor release, you should exclude
@@ -57,9 +61,11 @@ Remove, regroup, organize to your hearts content.
 
 
 ### 4) Update CHANGELOG.md
+
 With the final markdown all set, cut and paste it to the top of ```CHANGELOG.md```
 
 ### 5) Update the Release page
+
    * Switch to the [releases](https://github.com/GoogleCloudPlatform/kubernetes/releases) page.
    * Open up the release you are working on.
    * Cut and paste the final markdown from above into the release notes
diff --git a/profiling.md b/profiling.md
index fbb54c9f..d36885dd 100644
--- a/profiling.md
+++ b/profiling.md
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
+
 # Profiling Kubernetes
 
 This document explain how to plug in profiler and how to profile Kubernetes services.
@@ -53,6 +54,7 @@ to the init(c *Config) method in 'pkg/master/master.go' and import 'net/http/ppr
 In most use cases to use profiler service it's enough to do 'import _ net/http/pprof', which automatically registers a handler in the default http.Server. Slight inconvenience is that APIserver uses default server for intra-cluster communication, so plugging profiler to it is not really useful. In 'pkg/master/server/server.go' more servers are created and started as separate goroutines. The one that is usually serving external traffic is secureServer. The handler for this traffic is defined in 'pkg/master/master.go' and stored in Handler variable. It is created from HTTP multiplexer, so the only thing that needs to be done is adding profiler handler functions to this multiplexer. This is exactly what lines after TL;DR do.
 
 ## Connecting to the profiler
+
 Even when running profiler I found not really straightforward to use 'go tool pprof' with it. The problem is that at least for dev purposes certificates generated for APIserver are not signed by anyone trusted and because secureServer serves only secure traffic it isn't straightforward to connect to the service. The best workaround I found is by creating an ssh tunnel from the kubernetes_master open unsecured port to some external server, and use this server as a proxy. To save everyone looking for correct ssh flags, it is done by running:
 
 ```
diff --git a/releasing.md b/releasing.md
index 8b1a661c..65db081d 100644
--- a/releasing.md
+++ b/releasing.md
@@ -30,6 +30,7 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
+
 # Releasing Kubernetes
 
 This document explains how to cut a release, and the theory behind it. If you
@@ -87,6 +88,7 @@ Where `v0.20.2-322-g974377b` is the git hash you decided on. This will become
 our (retroactive) branch point.
 
 #### Branching, Tagging and Merging
+
 Do the following:
 
 1. `export VER=x.y` (e.g. `0.20` for v0.20)
diff --git a/scheduler_algorithm.md b/scheduler_algorithm.md
index 791de7c4..e73e4f27 100644
--- a/scheduler_algorithm.md
+++ b/scheduler_algorithm.md
@@ -30,11 +30,13 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- 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 [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:

 

 - `NoDiskConflict`: Evaluate if a pod can fit due to the volumes it requests, and those that are already mounted.

diff --git a/writing-a-getting-started-guide.md b/writing-a-getting-started-guide.md
index 3e67b632..c22d9204 100644
--- a/writing-a-getting-started-guide.md
+++ b/writing-a-getting-started-guide.md
@@ -32,6 +32,7 @@ Documentation for other releases can be found at
 <!-- END MUNGE: UNVERSIONED_WARNING -->
 
 # Writing a Getting Started Guide
+
 This page gives some advice for anyone planning to write or update a Getting Started Guide for Kubernetes.
 It also gives some guidelines which reviewers should follow when reviewing a pull request for a
 guide.
@@ -57,6 +58,7 @@ Distros fall into two categories:
 There are different guidelines for each.
 
 ## Versioned Distro Guidelines
+
 These guidelines say *what* to do.  See the Rationale section for *why*.
  - Send us a PR.
  - Put the instructions in `docs/getting-started-guides/...`. Scripts go there too.  This helps devs easily
@@ -77,6 +79,7 @@ we still want to hear from you.  We suggest you write a blog post or a Gist, and
 Just file an issue or chat us on IRC and one of the committers will link to it from the wiki.
 
 ## Development Distro Guidelines
+
 These guidelines say *what* to do.  See the Rationale section for *why*.
   - the main reason to add a new development distro is to support a new IaaS provider (VM and
     network management).  This means implementing a new `pkg/cloudprovider/$IAAS_NAME`.  
@@ -93,6 +96,7 @@ These guidelines say *what* to do.  See the Rationale section for *why*.
       refactoring and feature additions that affect code for their IaaS.
 
 ## Rationale 
+
  - We want people to create Kubernetes clusters with whatever IaaS, Node OS,
    configuration management tools, and so on, which they are familiar with.  The
    guidelines for **versioned distros** are designed for flexibility.