apply changes

docs/devel/api-conventions.md

@@ -196,12 +196,15 @@ References in the status of the referee to the referrer may be permitted, when t
 Discussed in [#2004](https://github.com/GoogleCloudPlatform/kubernetes/issues/2004) and elsewhere. There are no maps of subobjects in any API objects. Instead, the convention is to use a list of subobjects containing name fields.
 
 For example:
+
 ```yaml
 ports:
   - name: www
     containerPort: 80
 ```
+
 vs.
+
 ```yaml
 ports:
   www:
@@ -518,6 +521,7 @@ A ```Status``` kind will be returned by the API in two cases:
 The status object is encoded as JSON and provided as the body of the response.  The status object contains fields for humans and machine consumers of the API to get more detailed information for the cause of the failure. The information in the status object supplements, but does not override, the HTTP status code's meaning. When fields in the status object have the same meaning as generally defined HTTP headers and that header is returned with the response, the header should be considered as having higher priority.
 
 **Example:**
+
 ```
 $ curl -v -k -H "Authorization: Bearer WhCDvq4VPpYhrcfmF6ei7V9qlbqTubUc" https://10.240.122.184:443/api/v1/namespaces/default/pods/grafana
 

docs/devel/api_changes.md

@@ -282,6 +282,7 @@ conversion functions when writing your conversion functions.
 Once all the necessary manually written conversions are added, you need to
 regenerate auto-generated ones. To regenerate them:
    - run
+
 ```
    $ hack/update-generated-conversions.sh
 ```

docs/devel/developer-guides/vagrant.md

@@ -83,6 +83,7 @@ vagrant ssh minion-3
 ```
 
 To view the service status and/or logs on the kubernetes-master:
+
 ```sh
 vagrant ssh master
 [vagrant@kubernetes-master ~] $ sudo systemctl status kube-apiserver
@@ -96,6 +97,7 @@ vagrant ssh master
 ```
 
 To view the services on any of the nodes:
+
 ```sh
 vagrant ssh minion-1
 [vagrant@kubernetes-minion-1] $ sudo systemctl status docker
@@ -109,17 +111,20 @@ vagrant ssh minion-1
 With your Kubernetes cluster up, you can manage the nodes in your cluster with the regular Vagrant commands.
 
 To push updates to new Kubernetes code after making source changes:
+
 ```sh
 ./cluster/kube-push.sh
 ```
 
 To stop and then restart the cluster:
+
 ```sh
 vagrant halt
 ./cluster/kube-up.sh
 ```
 
 To destroy the cluster:
+
 ```sh
 vagrant destroy
 ```

docs/devel/development.md

@@ -109,6 +109,7 @@ source control system).  Use ```apt-get install mercurial``` or ```yum install m
 directly from mercurial.
 
 2) Create a new GOPATH for your tools and install godep:
+
 ```
 export GOPATH=$HOME/go-tools
 mkdir -p $GOPATH
@@ -116,6 +117,7 @@ go get github.com/tools/godep
 ```
 
 3) Add $GOPATH/bin to your path. Typically you'd add this to your ~/.profile:
+
 ```
 export GOPATH=$HOME/go-tools
 export PATH=$PATH:$GOPATH/bin
@@ -125,6 +127,7 @@ export PATH=$PATH:$GOPATH/bin
 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:
+
 ```
 export KPATH=$HOME/code/kubernetes
 mkdir -p $KPATH/src/github.com/GoogleCloudPlatform/kubernetes
@@ -134,6 +137,7 @@ git clone https://path/to/your/fork .
 ```
 
 2) Set up your GOPATH.
+
 ```
 # Option A: this will let your builds see packages that exist elsewhere on your system.
 export GOPATH=$KPATH:$GOPATH
@@ -143,12 +147,14 @@ export GOPATH=$KPATH
 ```
 
 3) Populate your new GOPATH.
+
 ```
 cd $KPATH/src/github.com/GoogleCloudPlatform/kubernetes
 godep restore
 ```
 
 4) Next, you can either add a new dependency or update an existing one.
+
 ```
 # To add a new dependency, do:
 cd $KPATH/src/github.com/GoogleCloudPlatform/kubernetes
@@ -218,6 +224,7 @@ KUBE_COVER=y hack/test-go.sh
 At the end of the run, an the HTML report will be generated with the path printed to stdout.
 
 To run tests and collect coverage in only one package, pass its relative path under the `kubernetes` directory as an argument, for example:
+
 ```
 cd kubernetes
 KUBE_COVER=y hack/test-go.sh pkg/kubectl
@@ -230,6 +237,7 @@ Coverage results for the project can also be viewed on [Coveralls](https://cover
 ## Integration tests
 
 You need an [etcd](https://github.com/coreos/etcd/releases/tag/v2.0.0) in your path, please make sure it is installed and in your ``$PATH``.
+
 ```
 cd kubernetes
 hack/test-integration.sh
@@ -238,12 +246,14 @@ hack/test-integration.sh
 ## End-to-End tests
 
 You can run an end-to-end test which will bring up a master and two nodes, perform some tests, and then tear everything down. Make sure you have followed the getting started steps for your chosen cloud platform (which might involve changing the `KUBERNETES_PROVIDER` environment variable to something other than "gce".
+
 ```
 cd kubernetes
 hack/e2e-test.sh
 ```
 
 Pressing control-C should result in an orderly shutdown but if something goes wrong and you still have some VMs running you can force a cleanup with this command:
+
 ```
 go run hack/e2e.go --down
 ```
@@ -281,6 +291,7 @@ hack/ginkgo-e2e.sh --ginkgo.focus=Pods.*env
 ```
 
 ### Combining flags
+
 ```sh
 # Flags can be combined, and their actions will take place in this order:
 # -build, -push|-up|-pushup, -test|-tests=..., -down

docs/devel/flaky-tests.md

@@ -42,6 +42,7 @@ _Note: these instructions are mildly hacky for now, as we get run once semantics
 There is a testing image ```brendanburns/flake``` up on the docker hub.  We will use this image to test our fix.
 
 Create a replication controller with the following config:
+
 ```yaml
 apiVersion: v1
 kind: ReplicationController
@@ -63,6 +64,7 @@ spec:
         - name: REPO_SPEC
           value: https://github.com/GoogleCloudPlatform/kubernetes
 ```
+
 Note that we omit the labels and the selector fields of the replication controller, because they will be populated from the labels field of the pod template by default.
 
 ```

docs/devel/getting-builds.md

@@ -45,6 +45,7 @@ usage:
 ```
 
 You can also use the gsutil tool to explore the Google Cloud Storage release bucket. Here are some examples:
+
 ```
 gsutil cat gs://kubernetes-release/ci/latest.txt          # output the latest ci version number
 gsutil cat gs://kubernetes-release/ci/latest-green.txt    # output the latest ci version number that passed gce e2e

docs/devel/making-release-notes.md

@@ -40,6 +40,7 @@ _TODO_: Figure out a way to record this somewhere to save the next release engin
 Find the most-recent PR that was merged with the current .0 release.  Remeber this as $CURRENTPR.
 
 ### 2) Run the release-notes tool
+
 ```bash
 ${KUBERNETES_ROOT}/build/make-release-notes.sh $LASTPR $CURRENTPR
 ```

docs/devel/profiling.md

@@ -41,24 +41,30 @@ Go comes with inbuilt 'net/http/pprof' profiling library and profiling web servi
 ## Adding profiling to services to APIserver.
 
 TL;DR: Add lines:
+
 ```
   m.mux.HandleFunc("/debug/pprof/", pprof.Index)
   m.mux.HandleFunc("/debug/pprof/profile", pprof.Profile)
   m.mux.HandleFunc("/debug/pprof/symbol", pprof.Symbol)
 ```
+
 to the init(c *Config) method in 'pkg/master/master.go' and import 'net/http/pprof' package.
 
 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:
+
 ```
   ssh kubernetes_master -L<local_port>:localhost:8080
 ```
+
 or analogous one for you Cloud provider. Afterwards you can e.g. run
+
 ```
 go tool pprof http://localhost:<local_port>/debug/pprof/profile
 ```
+
 to get 30 sec. CPU profile.
 
 ## Contention profiling

docs/devel/releasing.md

@@ -78,9 +78,11 @@ and you're trying to cut a release, don't hesitate to contact the GKE
 oncall.
 
 Before proceeding to the next step:
+
 ```
 export BRANCHPOINT=v0.20.2-322-g974377b
 ```
+
 Where `v0.20.2-322-g974377b` is the git hash you decided on. This will become
 our (retroactive) branch point.