<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">No.<br>
<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.):</p>
<p dir="auto">"bazel"</p>
<hr>
<p dir="auto"><strong>Is this a BUG REPORT or FEATURE REQUEST?</strong> (choose one):</p>
<p dir="auto">Bug report.</p>
<p dir="auto"><strong>Kubernetes version</strong> (use <code class="notranslate">kubectl version</code>):</p>
<p dir="auto">master.</p>
<p dir="auto"><strong>What happened</strong>:</p>
<p dir="auto">golang.org/x/net/context clashed with a dependency in my project because it been vendored as source into the tree.</p>
<p dir="auto"><strong>What you expected to happen</strong>:</p>
<p dir="auto">I expected Kubernetes to use go_rules features for vendoring in WORKSPACE, like so</p>
<p dir="auto">new_go_repository(<br>
name = "org_golang_x_net",<br>
importpath="golang.org/x/net",<br>
commit="f4b625ec9b21d620bb5ce57f2dfc3e08ca97fce6"<br>
)</p>
<p dir="auto"><strong>How to reproduce it</strong> (as minimally and precisely as possible):</p>
<p dir="auto">Build a small project that imports Kubernetes as an external dependency like this:</p>
<p dir="auto">git_repository(<br>
name = "io_k8s_kubernetes",<br>
remote = "<a href="https://github.com/kubernetes/kubernetes">https://github.com/kubernetes/kubernetes</a>",<br>
commit = "...",<br>
)</p>
<p dir="auto">This allows use of the Kubernetes BUILD rules in the remote project. Then, import golang.org/x/net as above and try to use it in a go_binary. The link step will fail.</p>
<p dir="auto"><strong>Anything else do we need to know</strong>:</p>
<p dir="auto">I understand there may be concerns I'm not aware of here.  <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/mikedanese/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/mikedanese">@mikedanese</a></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>.): 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>
I searched in the issues and asked for help multiple times on Slack.</p>
<hr>
<p dir="auto"><strong>Is this a BUG REPORT or FEATURE REQUEST?</strong> (choose one): FEATURE REQUEST</p>

<p dir="auto"><strong>Kubernetes version</strong> (use <code class="notranslate">kubectl version</code>): 1.5 beta</p>
<p dir="auto">It is currently not possible to specify the desired FSType when using dynamically provisioned volumes. As I understand it, only a PV resource can specify the FSType. But as we don't create PVs by ourself when using dynamic provisioning, we have no chance to specify it.</p>
<p dir="auto">I tried to understand the source when it comes to dynamic provisioning. As I understand it, the cloud specific VolumeSource (e.g. AzureDiskVolumeSource or AWSElasticBlockStoreVolumeSource) hold the desired FSType. For AzureDiskVolumeSource, I could not find any place where FSType is actually set. For AWSElasticBlockStoreVolumeSource, it is set to ext4 on creation and then never touched again.</p>
<p dir="auto">I would suggest that  FSType should be added to either StorageClass or PersistentVolumeClaim. I'm not sure however which one would best fit, or if it fits at all.</p>