Fix trailing whitespace in all docs

docs/devel/api-conventions.md

@@ -173,11 +173,11 @@ Objects that contain both spec and status should not contain additional top-leve
 ##### Typical status properties
 
 * **phase**: The phase is a simple, high-level summary of the phase of the lifecycle of an object. The phase should progress monotonically. Typical phase values are `Pending` (not yet fully physically realized), `Running` or `Active` (fully realized and active, but not necessarily operating correctly), and `Terminated` (no longer active), but may vary slightly for different types of objects. New phase values should not be added to existing objects in the future. Like other status fields, it must be possible to ascertain the lifecycle phase by observation. Additional details regarding the current phase may be contained in other fields.
-* **conditions**: Conditions represent orthogonal observations of an object's current state. Objects may report multiple conditions, and new types of conditions may be added in the future. Condition status values may be `True`, `False`, or `Unknown`. Unlike the phase, conditions are not expected to be monotonic -- their values may change back and forth. A typical condition type is `Ready`, which indicates the object was believed to be fully operational at the time it was last probed. Conditions may carry additional information, such as the last probe time or last transition time. 
+* **conditions**: Conditions represent orthogonal observations of an object's current state. Objects may report multiple conditions, and new types of conditions may be added in the future. Condition status values may be `True`, `False`, or `Unknown`. Unlike the phase, conditions are not expected to be monotonic -- their values may change back and forth. A typical condition type is `Ready`, which indicates the object was believed to be fully operational at the time it was last probed. Conditions may carry additional information, such as the last probe time or last transition time.
 
 TODO(@vishh): Reason and Message.
 
-Phases and conditions are observations and not, themselves, state machines, nor do we define comprehensive state machines for objects with behaviors associated with state transitions. The system is level-based and should assume an Open World. Additionally, new observations and details about these observations may be added over time. 
+Phases and conditions are observations and not, themselves, state machines, nor do we define comprehensive state machines for objects with behaviors associated with state transitions. The system is level-based and should assume an Open World. Additionally, new observations and details about these observations may be added over time.
 
 In order to preserve extensibility, in the future, we intend to explicitly convey properties that users and components care about rather than requiring those properties to be inferred from observations.
 
@@ -376,7 +376,7 @@ Late-initializers should only make the following types of modifications:
  - Adding keys to maps
  - Adding values to arrays which have mergeable semantics (`patchStrategy:"merge"` attribute in
   the type definition).
-  
+
 These conventions:
  1. allow a user (with sufficient privilege) to override any system-default behaviors by setting
     the fields that would otherwise have been defaulted.

docs/devel/api_changes.md

@@ -309,7 +309,7 @@ a panic from the `serialization_test`.  If so, look at the diff it produces (or
 the backtrace in case of a panic) and figure out what you forgot.  Encode that
 into the fuzzer's custom fuzz functions.  Hint: if you added defaults for a field,
 that field will need to have a custom fuzz function that ensures that the field is
-fuzzed to a non-empty value. 
+fuzzed to a non-empty value.
 
 The fuzzer can be found in `pkg/api/testing/fuzzer.go`.
 

docs/devel/collab.md

@@ -61,7 +61,7 @@ Maintainers will do merges of appropriately reviewed-and-approved changes during
 
 There may be discussion an even approvals granted outside of the above hours, but merges will generally be deferred.
 
-If a PR is considered complex or controversial, the merge of that PR should be delayed to give all interested parties in all timezones the opportunity to provide feedback.  Concretely, this means that such PRs should be held for 24 
+If a PR is considered complex or controversial, the merge of that PR should be delayed to give all interested parties in all timezones the opportunity to provide feedback.  Concretely, this means that such PRs should be held for 24
 hours before merging.  Of course "complex" and "controversial" are left to the judgment of the people involved, but we trust that part of being a committer is the judgment required to evaluate such things honestly, and not be
 motivated by your desire (or your cube-mate's desire) to get their code merged.  Also see "Holds" below, any reviewer can issue a "hold" to indicate that the PR is in fact complicated or complex and deserves further review.
 

docs/devel/scheduler_algorithm.md

@@ -44,7 +44,7 @@ The purpose of filtering the nodes is to filter out the nodes that do not meet c
 - `PodFitsPorts`: Check if any HostPort required by the Pod is already occupied on the node.
 - `PodFitsHost`: Filter out all nodes except the one specified in the PodSpec's NodeName field.
 - `PodSelectorMatches`: Check if the labels of the node match the labels specified in the Pod's `nodeSelector` field ([Here](../user-guide/node-selection/) is an example of how to use `nodeSelector` field).
-- `CheckNodeLabelPresence`: Check if all the specified labels exist on a node or not, regardless of the value. 
+- `CheckNodeLabelPresence`: Check if all the specified labels exist on a node or not, regardless of the value.
 
 The details of the above predicates can be found in [plugin/pkg/scheduler/algorithm/predicates/predicates.go](http://releases.k8s.io/HEAD/plugin/pkg/scheduler/algorithm/predicates/predicates.go). All predicates mentioned above can be used in combination to perform a sophisticated filtering policy. Kubernetes uses some, but not all, of these predicates by default. You can see which ones are used by default in [plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go](http://releases.k8s.io/HEAD/plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go).
 
@@ -53,7 +53,7 @@ The details of the above predicates can be found in [plugin/pkg/scheduler/algori
 The filtered nodes are considered suitable to host the Pod, and it is often that there are more than one nodes remaining. Kubernetes prioritizes the remaining nodes to find the "best" one for the Pod. The prioritization is performed by a set of priority functions. For each remaining node, a priority function gives a score which scales from 0-10 with 10 representing for "most preferred" and 0 for "least preferred". Each priority function is weighted by a positive number and the final score of each node is calculated by adding up all the weighted scores. For example, suppose there are two priority functions, `priorityFunc1` and `priorityFunc2` with weighting factors `weight1` and `weight2` respectively, the final score of some NodeA is:
 
     finalScoreNodeA = (weight1 * priorityFunc1) + (weight2 * priorityFunc2)
-    
+
 After the scores of all nodes are calculated, the node with highest score is chosen as the host of the Pod. If there are more than one nodes with equal highest scores, a random one among them is chosen.
 
 Currently, Kubernetes scheduler provides some practical priority functions, including:

docs/devel/writing-a-getting-started-guide.md

@@ -70,7 +70,7 @@ These guidelines say *what* to do.  See the Rationale section for *why*.
  - Setup a cluster and run the [conformance test](development.md#conformance-testing) against it, and report the
    results in your PR.
  - Versioned distros should typically not modify or add code in `cluster/`.  That is just scripts for developer
-   distros.  
+   distros.
  - When a new major or minor release of Kubernetes comes out, we may also release a new
    conformance test, and require a new conformance test run to earn a conformance checkmark.
 
@@ -82,20 +82,20 @@ Just file an issue or chat us on IRC and one of the committers will link to it f
 
 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`.  
+    network management).  This means implementing a new `pkg/cloudprovider/$IAAS_NAME`.
   - Development distros should use Saltstack for Configuration Management.
   - development distros need to support automated cluster creation, deletion, upgrading, etc.
     This mean writing scripts in `cluster/$IAAS_NAME`.
   - all commits to the tip of this repo need to not break any of the development distros
     - the author of the change is responsible for making changes necessary on all the cloud-providers if the
       change affects any of them, and reverting the change if it breaks any of the CIs.
-  - a development distro needs to have an organization which owns it.  This organization needs to: 
+  - a development distro needs to have an organization which owns it.  This organization needs to:
     - Setting up and maintaining Continuous Integration that runs e2e frequently (multiple times per day) against the
       Distro at head,  and which notifies all devs of breakage.
     - being reasonably available for questions and assisting with
       refactoring and feature additions that affect code for their IaaS.
 
-## Rationale 
+## 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
@@ -114,19 +114,19 @@ These guidelines say *what* to do.  See the Rationale section for *why*.
    learning curve to understand our automated testing scripts.  And it is considerable effort
    to fully automate setup and teardown of a cluster, which is needed for CI.  And, not everyone
    has the time and money to run CI.  We do not want to
-   discourage people from writing and sharing guides because of this.  
+   discourage people from writing and sharing guides because of this.
  - Versioned distro authors are free to run their own CI and let us know if there is breakage, but we
    will not include them as commit hooks -- there cannot be so many commit checks that it is impossible
    to pass them all.
  - We prefer a single Configuration Management tool for development distros.  If there were more
    than one, the core developers would have to learn multiple tools and update config in multiple
    places.  **Saltstack** happens to be the one we picked when we started the project.  We
-   welcome versioned distros that use any tool; there are already examples of 
+   welcome versioned distros that use any tool; there are already examples of
    CoreOS Fleet, Ansible, and others.
  - You can still run code from head or your own branch
    if you use another Configuration Management tool -- you just have to do some manual steps
    during testing and deployment.
-      
+
 
 
 <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->