Run gendocs

docs/proposals/autoscaling.md

@@ -30,7 +30,9 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
+
 ## Abstract
+
 Auto-scaling is a data-driven feature that allows users to increase or decrease capacity as needed by controlling the
 number of pods deployed within the system automatically.  
 
@@ -230,6 +232,7 @@ Since an auto-scaler is a durable object it is best represented as a resource.
 ```
 
 #### Boundary Definitions
+
 The `AutoScaleThreshold` definitions provide the boundaries for the auto-scaler.  By defining comparisons that form a range
 along with positive and negative increments you may define bi-directional scaling.  For example the upper bound may be
 specified as "when requests per second rise above 50 for 30 seconds scale the application up by 1" and a lower bound may
@@ -251,6 +254,7 @@ Of note: If the statistics gathering mechanisms can be initialized with a regist
 potentially piggyback on this registry.
 
 ### Multi-target Scaling Policy
+
 If multiple scalable targets satisfy the `TargetSelector` criteria the auto-scaler should be configurable as to which
 target(s) are scaled.  To begin with, if multiple targets are found the auto-scaler will scale the largest target up
 or down as appropriate.  In the future this may be more configurable.  

docs/proposals/federation.md

@@ -30,12 +30,15 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
-#Kubernetes Cluster Federation   
-##(a.k.a. "Ubernetes")
+
+# Kubernetes Cluster Federation   
+
+## (a.k.a. "Ubernetes")
 
 ## Requirements Analysis and Product Proposal
 
 ## _by Quinton Hoole ([quinton@google.com](mailto:quinton@google.com))_  
+
 _Initial revision: 2015-03-05_  
 _Last updated: 2015-03-09_  
 This doc: [tinyurl.com/ubernetesv2](http://tinyurl.com/ubernetesv2)  
@@ -417,7 +420,7 @@ TBD: All very hand-wavey still, but some initial thoughts to get the conversatio
 
 ![image](federation-high-level-arch.png)
 
-##  Ubernetes API
+## Ubernetes API
 
 This looks a lot like the existing Kubernetes API but is explicitly multi-cluster.  
 

docs/proposals/high-availability.md

@@ -30,10 +30,13 @@ Documentation for other releases can be found at
 <!-- END STRIP_FOR_RELEASE -->
 
 <!-- END MUNGE: UNVERSIONED_WARNING -->
+
 # High Availability of Scheduling and Controller Components in Kubernetes
+
 This document serves as a proposal for high availability of the scheduler and controller components in kubernetes.  This proposal is intended to provide a simple High Availability api for kubernetes components with the potential to extend to services running on kubernetes.  Those services would be subject to their own constraints.
 
 ## Design Options
+
 For complete reference see [this](https://www.ibm.com/developerworks/community/blogs/RohitShetty/entry/high_availability_cold_warm_hot?lang=en)
 
 1. Hot Standby: In this scenario, data and state are shared between the two components such that an immediate failure in one component causes the standby daemon to take over exactly where the failed component had left off.  This would be an ideal solution for kubernetes, however it poses a series of challenges in the case of controllers where component-state is cached locally and not persisted in a transactional way to a storage facility.  This would also introduce additional load on the apiserver, which is not desirable.  As a result, we are **NOT** planning on this approach at this time.
@@ -43,6 +46,7 @@ For complete reference see [this](https://www.ibm.com/developerworks/community/b
 3. Active-Active (Load Balanced): Clients can simply load-balance across any number of servers that are currently running.  Their general availability can be continuously updated, or published, such that load balancing only occurs across active participants.  This aspect of HA is outside of the scope of *this* proposal because there is already a partial implementation in the apiserver.
 
 ## Design Discussion Notes on Leader Election
+
 Implementation References:
 * [zookeeper](http://zookeeper.apache.org/doc/trunk/recipes.html#sc_leaderElection)
 * [etcd](https://groups.google.com/forum/#!topic/etcd-dev/EbAa4fjypb4)
@@ -55,11 +59,13 @@ The first component to request leadership will become the master.  All other com
 The component that becomes master should create a thread to manage the lease.  This thread should be created with a channel that the main process can use to release the master lease.  The master should release the lease in cases of an unrecoverable error and clean shutdown.  Otherwise, this process will renew the lease and sleep, waiting for the next renewal time or notification to release the lease.  If there is a failure to renew the lease, this process should force the entire component to exit.  Daemon exit is meant to prevent potential split-brain conditions.  Daemon restart is implied in this scenario, by either the init system (systemd), or possible watchdog processes.  (See Design Discussion Notes)
 
 ## Options added to components with HA functionality
+
 Some command line options would be added to components that can do HA:
 
 * Lease Duration - How long a component can be master
 
 ## Design Discussion Notes
+
 Some components may run numerous threads in order to perform tasks in parallel.  Upon losing master status, such components should exit instantly instead of attempting to gracefully shut down such threads.  This is to ensure that, in the case there's some propagation delay in informing the threads they should stop, the lame-duck threads won't interfere with the new master.  The component should exit with an exit code indicating that the component is not the master.  Since all components will be run by systemd or some other monitoring system, this will just result in a restart.
 
 There is a short window after a new master acquires the lease, during which data from the old master might be committed.  This is because there is currently no way to condition a write on its source being the master.  Having the daemons exit shortens this window but does not eliminate it.  A proper solution for this problem will be addressed at a later date.  The proposed solution is:
@@ -75,6 +81,7 @@ There is a short window after a new master acquires the lease, during which data
 5. When the API server makes the corresponding write to etcd, it includes it in a transaction that does a compare-and-swap on the "current master" entry (old value == new value == host:port and sequence number from the replica that sent the mutating operation). This basically guarantees that if we elect the new master, all transactions coming from the old master will fail. You can think of this as the master attaching a "precondition" of its belief about who is the latest master.
 
 ## Open Questions
+
 * Is there a desire to keep track of all nodes for a specific component type?