From 27230004ec413694a8e2da919b46245c1acd2767 Mon Sep 17 00:00:00 2001
From: Christian Bell <csbell@google.com>
Date: Fri, 23 Jun 2017 11:39:56 -0700
Subject: [PATCH] [Federation] Account for caching in kubectl

---
 federation/cluster/federation-up.sh | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/federation/cluster/federation-up.sh b/federation/cluster/federation-up.sh
index 01aaf05a56..fd20e22049 100755
--- a/federation/cluster/federation-up.sh
+++ b/federation/cluster/federation-up.sh
@@ -81,14 +81,14 @@ function init() {
   kube::log::status "DNS_ZONE_NAME: \"${DNS_ZONE_NAME}\", DNS_PROVIDER: \"${DNS_PROVIDER}\""
   kube::log::status "Image: \"${kube_registry}/hyperkube-amd64:${kube_version}\""
 
-  # The very first thing that kubefed does when it comes up is run RBAC
-  # API discovery. We believe this sometimes fail on new clusters and as
-  # a result causes kubefed to assume that the RBAC API doesn't exist.
-  # Therefore, we are applying this workaround for now to ensure that the
-  # RBAC API is available before running kubefed.
+  # The very first thing that kubefed does when it comes up is run RBAC API
+  # discovery. If it doesn't appear to be available, issue 'get role' to ensure
+  # that kubectl updates its cache.
+  ${KUBE_ROOT}/cluster/kubectl.sh get role
   timeout 1m bash <<EOF
     while [[ ! "$(${KUBE_ROOT}/cluster/kubectl.sh api-versions)" =~ "rbac.authorization.k8s.io/" ]]; do
-      kube::log::status "Waiting for rbac.authorization.k8s.io API group to appear"
+      ${KUBE_ROOT}/cluster/kubectl.sh get role
+      echo "Waiting for rbac.authorization.k8s.io API group to appear"
       sleep 2
     done
 EOF