Issue 1:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.): no

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): branch, revert

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG

Kubernetes version (use kubectl version): master branch

Environment:

Cloud provider or hardware configuration: none

OS (e.g. from /etc/os-release): N/A

Kernel (e.g. uname -a): N/A

Install tools: N/A

Others: N/A

What happened:

Document doc/design/versioning.md describes official branches to be used in Kubernetes project repositories: "master", "release-X.Y", "release-X.Y.Z".

At the moment, we have in kubernetes/kubernetes repository bunch of branches that are violating those naming conventions and most of them seems to be accidental pushes by people who has direct push rights to the repository. I think it is needed to be cleaned up from repository and potentially automatic check to be implemented to automatically clean-up them on appearance.

$ git branch -a | grep remotes/origin | grep -Ev "origin/(master|release-|gh-pages)"
remotes/origin/1.3.6
remotes/origin/1.3.7
remotes/origin/Dec/mounttype
remotes/origin/Dec/nfsv3
remotes/origin/Nov/nfshung
remotes/origin/caesarxuchao-patch-1
remotes/origin/eparis-unset-class-doc-typo
remotes/origin/foxish-add-cla
remotes/origin/foxish-patch-1
remotes/origin/foxish-remove-google-cla
remotes/origin/jszczepkowski-ha-e2e-disabled
remotes/origin/jszczepkowski-ha-feature
remotes/origin/kube-volume-owner
remotes/origin/mbohlool-patch-1
remotes/origin/patch-owners-vsphere
remotes/origin/revert-26501-scheduler
remotes/origin/revert-30701-28695_suppress_noisy_output
remotes/origin/revert-32200-storage-03-enable-test
remotes/origin/revert-32251-fix-oom-policy
remotes/origin/revert-32841-revert-32251-fix-oom-policy
remotes/origin/revert-33014-feature/set-image-id-manifest-digest
remotes/origin/revert-33209-automated-cherry-pick-of-#33143-upstream-release-1.4
remotes/origin/revert-33343-automated-cherry-pick-of-#33342-upstream-release-1.3
remotes/origin/revert-33347-fix_32900
remotes/origin/revert-33795-add-network-node-e2e
remotes/origin/revert-33850-add_e2e_test_for_kubectl_in_pod
remotes/origin/revert-34011-revert-33795-add-network-node-e2e
remotes/origin/revert-34570-Oct/pd-tests
remotes/origin/revert-35167-err
remotes/origin/revert-35697-upgrade-tests
remotes/origin/revert-36166-remove_mount_rootfs_flag
remotes/origin/revert-36210-flex_node_conditions
remotes/origin/revert-36610-Nov/nfsv3
remotes/origin/revert-36625-branch-eliminate-recursive-call-attemptToUpdateMasterRoleLabelsAndTaints
remotes/origin/revert-36864-fix-path-to-kubectl-in-gke-test
remotes/origin/revert-37085-rv
remotes/origin/revert-37095-kubemark_logrotation
remotes/origin/revert-37243-petset-e2e-rename
remotes/origin/revert-37356-jszczepkowski-ha-feature
remotes/origin/revert-37389-statefulset-skip-gke
remotes/origin/revert-37582-Nov/retrynfsv3
$

What you expected to happen:

$ git branch -a | grep remotes/origin | grep -Ev "origin/(master|gh-pages|release-)"
$

How to reproduce it (as minimally and precisely as possible):

$ git clone https://github.com/kubernetes/kubernetes
$ cd kubernets
$ git branch -a | grep remotes/origin | grep -Ev "origin/(master|gh-pages|release-)"

Anything else do we need to know:

Issue 2:
This proposal is related to the following issues, but (I believe) not entirely duplicative of them: #18623, #6363, #19443, #18174. If it is duplicative, then you know what to do ;-)

The way it is now:

The APIserver and supports leader election, allowing for nearly seamless failover of the kube-master with simple configurations. However kube-proxy and the kubelets on the workers will not see the new apiserver until their configuration is updated and restarted. The official recommendation for this is to use an external load-balancer, but that's just kicking the problem down the road; Kubernetes should, as much as possible, be the source of its own HA.

The simple fix:

Kubelet and Kube-proxy could allow use of etcd-based service discovery for locating the apiserver. Combined with running an etcd node (in small clusters) or an etcd standby node (in larger clusters). Combined with the other features which already exist, this would allow small to medium clusters to have fully automated kube-master failover "out of the box", using only tools we already use.

Drawbacks:

For larger clusters, load on etcd is already a bottleneck, and adding additional service discovery wouldn't help. However, dedicated clustered load-balancers make a lot more sense for a larger cluster, and should still be the recommended configuration for those.