LGTM. Thanks @nikhiljindal!

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

GCE e2e build/test passed for commit 98c9fbb.

• Build Log
• Test Artifacts
• Internal Jenkins Results

Automatic merge from submit-queue

@nikhiljindal I am a little confused for this change, per my understand we did not support secret in federation-apiserver right? how can you create the secret and retrieve it? are we going to add the support?

curl localhost:8080/api/v1
{
  "kind": "APIResourceList",
  "groupVersion": "v1",
  "resources": [
    {
      "name": "services",
      "namespaced": true,
      "kind": "Service"
    },
    {
      "name": "services/status",
      "namespaced": true,
      "kind": "Service"
    }
  ]

By reading the e2e code, it seems now we already require a bootstrap k8s cluster to boot federation? and the code is load the info from the bootstrap cluster. sorry for the noise as my info is out-of-date.

Yes you are right. We need a bootstrap k8s cluster. The secret containing kubeconfig for federation-apiserver is stored in the bootstrap k8s apiserver. But it is not intuitive. We will move it to federation-apiserver when we start supporting secrets in federation-apiserver.

Yeah, it's super important to move those secrets into the ubernetes control
plane asap.

On Mon, Jun 6, 2016 at 10:37 AM, Nikhil Jindal notifications@github.com
wrote:

Yes you are right. We need a bootstrap k8s cluster. The secret containing
kubeconfig for federation-apiserver is stored in the bootstrap k8s
apiserver. But it is not intuitive. We will move it to federation-apiserver
when we start supporting secrets in federation-apiserver.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#26819 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAngloclz7fyi8Gv6SavD421nOtBeWT6ks5qJFrVgaJpZM4It8wP
.

@nikhiljindal Does this PR require action by the user when upgrading from 1.2.x to 1.3.0? (Think about non-developer users.) If so, please edit your first comment to have a release-note block, like in #28132. If it is just an optional feature, please change the label to just release-note. If it is not a complete feature by itself, then apply "release-note-none" label instead.

@erictune Changed the label to release-note-none

@nikhiljindal and others who might be interested.
Reason: federation-controller-manager did not even exist in 1.2. So there is no action to be taken by the users while going from 1.2 to 1.3. Also, it is not a feature by itself. So it is not that useful to have it in the release note.

Thought: we should consider maintaining a federation change log (or keep the federation release note compiled) to make the life of release czar easier.