delete all duplicate empty blanks

Signed-off-by: Xiang Dai <[email protected]>

Kubernetes-commit: 36065c6dd717c14e0a90131041e20345a7e5e324

Author: daixiang0

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,2 +1,2 @@
-Sorry, we do not accept changes directly against this repository. Please see 
+Sorry, we do not accept changes directly against this repository. Please see
 CONTRIBUTING.md for information on where and how to contribute instead.

CONTRIBUTING.md

@@ -2,6 +2,6 @@
 
 Do not open pull requests directly against this repository, they will be ignored. Instead, please open pull requests against [kubernetes/kubernetes](https://git.k8s.io/kubernetes/).  Please follow the same [contributing guide](https://git.k8s.io/kubernetes/CONTRIBUTING.md) you would follow for any other pull request made to kubernetes/kubernetes.
 
-This repository is published from [kubernetes/kubernetes/staging/src/k8s.io/sample-controller](https://git.k8s.io/kubernetes/staging/src/k8s.io/sample-controller) by the [kubernetes publishing-bot](https://git.k8s.io/publishing-bot). 
+This repository is published from [kubernetes/kubernetes/staging/src/k8s.io/sample-controller](https://git.k8s.io/kubernetes/staging/src/k8s.io/sample-controller) by the [kubernetes publishing-bot](https://git.k8s.io/publishing-bot).
 
 Please see [Staging Directory and Publishing](https://git.k8s.io/community/contributors/devel/sig-architecture/staging.md) for more information

docs/controller-client-go.md

@@ -1,11 +1,11 @@
 # client-go under the hood
 
-The [client-go](https://github.com/kubernetes/client-go/) library contains various mechanisms that you can use when 
-developing your custom controllers. These mechanisms are defined in the 
+The [client-go](https://github.com/kubernetes/client-go/) library contains various mechanisms that you can use when
+developing your custom controllers. These mechanisms are defined in the
 [tools/cache folder](https://github.com/kubernetes/client-go/tree/master/tools/cache) of the library.
 
-Here is a pictorial representation showing how the various components in 
-the client-go library work and their interaction points with the custom 
+Here is a pictorial representation showing how the various components in
+the client-go library work and their interaction points with the custom
 controller code that you will write.
 
 <p align="center">
@@ -19,7 +19,7 @@ watches the Kubernetes API for the specified resource type (kind).
 The function in which this is done is *ListAndWatch*.
 The watch could be for an in-built resource or it could be for a custom resource.
 When the reflector receives notification about existence of new
-resource instance through the watch API, it gets the newly created object 
+resource instance through the watch API, it gets the newly created object
 using the corresponding listing API and puts it in the Delta Fifo queue
 inside the *watchHandler* function.
 
@@ -38,27 +38,27 @@ that generates an object’s key as `<namespace>/<name>` combination for that ob
 
 ## Custom Controller components
 
-* Informer reference: This is the reference to the Informer instance that knows 
-how to work with your custom resource objects. Your custom controller code needs 
+* Informer reference: This is the reference to the Informer instance that knows
+how to work with your custom resource objects. Your custom controller code needs
 to create the appropriate Informer.
 
-* Indexer reference: This is the reference to the Indexer instance that knows 
-how to work with your custom resource objects. Your custom controller code needs 
-to create this. You will be using this reference for retrieving objects for 
+* Indexer reference: This is the reference to the Indexer instance that knows
+how to work with your custom resource objects. Your custom controller code needs
+to create this. You will be using this reference for retrieving objects for
 later processing.
 
 The base controller in client-go provides the *NewIndexerInformer* function to create Informer and Indexer.
 In your code you can either [directly invoke this function](https://github.com/kubernetes/client-go/blob/master/examples/workqueue/main.go#L174) or [use factory methods for creating an informer.](https://github.com/kubernetes/sample-controller/blob/master/main.go#L61)
 
-* Resource Event Handlers: These are the callback functions which will be called by 
-the Informer when it wants to deliver an object to your controller. The typical 
+* Resource Event Handlers: These are the callback functions which will be called by
+the Informer when it wants to deliver an object to your controller. The typical
 pattern to write these functions is to obtain the dispatched object’s key
 and enqueue that key in a work queue for further processing.
 
-* Work queue: This is the queue that you create in your controller code to decouple 
-delivery of an object from its processing. Resource event handler functions are written 
+* Work queue: This is the queue that you create in your controller code to decouple
+delivery of an object from its processing. Resource event handler functions are written
 to extract the delivered object’s key and add that to the work queue.
 
-* Process Item: This is the function that you create in your code which processes items 
-from the work queue. There can be one or more other functions that do the actual processing. 
+* Process Item: This is the function that you create in your code which processes items
+from the work queue. There can be one or more other functions that do the actual processing.
 These functions will typically use the [Indexer reference](https://github.com/kubernetes/client-go/blob/master/examples/workqueue/main.go#L73), or a Listing wrapper to retrieve the object corresponding to the key.