Am testing it out

@k8s-bot node e2e test this issue #24479

Verified that it works as expected on GKE

One minor nit. LGTM otherwise. Please feel free to self-apply the label.

Thanks fixed. Adding LGTM. Also adding P1 since this is for federation which is release blocker for 1.3

Turns out "_" is not allowed in secret names and the context that GKE script creates in kubeconfig is named gke_myprojectname_us-central1-f_nikhiljindal-gke. We use the same name to create the secret and hence it fails with the following error:

The Secret "gke_myprojectname_us-central1-f_nikhiljindal-gke" is invalid.
metadata.name: Invalid value: "gke_myprojectname_us-central1-f_nikhiljindal-gke": must match the regex [a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)* (e.g. 'example.com')

Removing LGTM.

Pushed another commit to fix the context name before using it as cluster and secret names.
Fixing it by replacing "_" by "-" and truncating the string to 253 chars (so that it passes api validation).
Note that this only affects the test setup. For other users, they have to choose the name themselves while running the kubectl create commands.
Have updated E2EContext.Name to be this fixed name which is used everywhere. Added the original name as E2EContext.RawName which no one is using right now, but can be used for debugging.

PTAL.

Tracking issue for flake is #26290

@quinton-hoole
You must link to the test flake issue which caused you to request this manual re-test.
Re-test requests should be in the form of: k8s-bot test this issue: #<number>
Here is the list of open test flakes.

@nikhiljindal the kubeconfig contexts should already be created for you- I don't understand why you are creating additional kubeconfig files in the various cluster/<provider>/util.sh files.

By the time the e2e framework is running GetUnderlyingFederatedContexts is all ready to go without any additional changes on to of master.

@colhom You are right. By the time the e2e framework is done, the default kubeconfig is setup with credentials for all the clusters. That enables kubectl to be able to talk to any cluster. That flow is working great.

This change is to be able to create a secret. This secret is used by the federation controller manager (specifically the cluster controller) to be able to talk to each k8s cluster that is part of federation. There is a secret for each k8s cluster. The secret contains the kubeconfig record corresponding to that cluster. For this we create a new kubeconfig file that contains record for only one cluster (vs the default kubeconfig which contains records for all clusters) and then use that newly created kubeconfig file to create the secret.

And yes to be clear, there is another way to do this. Instead of creating those individual kubeconfigs in these shell scripts at cluster bring up time, we can extract those individual records from the single unified kubeconfig (which framework.GetUnderlyingFederatedContexts uses). That way we wont have to write cloud provider specific code and it will be go code so we can have good tests.
But then we will depend on kubeconfig structure and will break if that changes. With the current code, we are immune to that.

Changing the shell script for GCE was easy enough (just 4 lines of code) and the changes were a lot less brittle than the alternative so I went that route.
We can revisit this if maintaining code for all cloud providers turns out too complex.

@nikhiljindal the format that comes out of cluster/kubectl.sh config view is guaranteed to match what federation-apiserver is expecting, as they're using the same resource models and parsing logic?

I don't see the advantage of keeping redundant copies of the kubeconfig around on a per-provider basis. I do see a number of detriments (maintainability, further bloating artifact tree, more potentially non-portable build state, etc)

@nikhiljindal and I discussed this offline- I agree that this is the "least bad" way of doing this as of now.

LGTM

[sorry for the late comment]

Updated the code to use kubectl config view --minify --flatten everywhere.
PTAL

lgtm

GCE e2e build/test passed for commit 864b267.

• Build Log
• Test Artifacts
• Internal Jenkins Results

LGTM.

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

GCE e2e build/test passed for commit 864b267.

• Build Log
• Test Artifacts
• Internal Jenkins Results

Automatic merge from submit-queue