<p dir="auto"><strong>Is this a request for help?</strong> (If yes, you should use our troubleshooting guide and community support channels, see <a href="http://kubernetes.io/docs/troubleshooting/" rel="nofollow">http://kubernetes.io/docs/troubleshooting/</a>.):<br>
No</p>
<p dir="auto"><strong>What keywords did you search in Kubernetes issues before filing this one?</strong> (If you have found any duplicates, you should instead reply there.):<br>
NA</p>
<hr>
<p dir="auto"><strong>Is this a BUG REPORT or FEATURE REQUEST?</strong> (choose one):<br>
Feature Request</p>

<p dir="auto"><strong>Kubernetes version</strong> (use <code class="notranslate">kubectl version</code>):<br>
1.3 1.4 master</p>
<p dir="auto"><strong>Environment</strong>:</p>
<ul dir="auto">
<li><strong>Cloud provider or hardware configuration</strong>: vSphere</li>
<li><strong>OS</strong> (e.g. from /etc/os-release): Linux</li>
<li><strong>Kernel</strong> (e.g. <code class="notranslate">uname -a</code>): NA</li>
<li><strong>Install tools</strong>: kube-up.sh</li>
<li><strong>Others</strong>:</li>
</ul>
<p dir="auto"><strong>What happened</strong>:<br>
Currently credentials for communicating with vCenter are stored on each node. There does not seem an inherent need to do this and might be a question of code clean in the cloud provider or code change in kubernetes.</p>
<p dir="auto"><strong>What you expected to happen</strong>:<br>
Only the master node needs access to vCenter</p>
<p dir="auto"><strong>How to reproduce it</strong> (as minimally and precisely as possible):<br>
Kubelet fails to come up if vSphere cloud provider is used and is not configured with credentials.</p>
<p dir="auto"><strong>Anything else do we need to know</strong>:</p>
<p dir="auto"><strong>Is this a request for help?</strong> (If yes, you should use our troubleshooting guide and community support channels, see <a href="http://kubernetes.io/docs/troubleshooting/" rel="nofollow">http://kubernetes.io/docs/troubleshooting/</a>.):</p>
<p dir="auto">Yes</p>
<p dir="auto"><strong>What keywords did you search in Kubernetes issues before filing this one?</strong> (If you have found any duplicates, you should instead reply there.):<br>
1.4.0</p>
<h2 dir="auto">yosemite</h2>
<p dir="auto"><strong>Is this a BUG REPORT or FEATURE REQUEST?</strong> (choose one):<br>
BUG REPORT</p>

<p dir="auto"><strong>Kubernetes version</strong> (use <code class="notranslate">kubectl version</code>):<br>
1.4.0</p>
<p dir="auto"><strong>Environment</strong>:</p>
<ul dir="auto">
<li><strong>Cloud provider or hardware configuration</strong>:</li>
<li><strong>OS</strong> (e.g. from /etc/os-release): OSX Yosemite (homebrew bot)</li>
<li><strong>Kernel</strong> (e.g. <code class="notranslate">uname -a</code>):</li>
<li><strong>Install tools</strong>:</li>
<li><strong>Others</strong>:</li>
</ul>
<p dir="auto"><strong>What happened</strong>:<br>
Homebrew build bot fails due to race condition</p>
<p dir="auto"><strong>What you expected to happen</strong>:<br>
Homebrew build bot should succeed</p>
<p dir="auto"><strong>How to reproduce it</strong> (as minimally and precisely as possible):<br>
In OSX Yosemite, run <code class="notranslate">make WHAT=/bin/kubectl GOFLAGS=-v</code></p>
<p dir="auto"><strong>Anything else do we need to know</strong>:<br>
Link to this issue here<br>
<a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="180781268" data-permission-text="Title is private" data-url="https://github.com/Homebrew/homebrew-core/issues/5558" data-hovercard-type="pull_request" data-hovercard-url="/Homebrew/homebrew-core/pull/5558/hovercard" href="https://github.com/Homebrew/homebrew-core/pull/5558">Homebrew/homebrew-core#5558</a></p>