Change the user-kubeconfig name

[felipeweb]

trafficstars

/kind feature

To be compatible with clusterctl get kubeconfig we need to change the kubeconfigs name. more details here https://github.com/kubernetes-sigs/cluster-api/issues/3645

• [cluster-name]-user-kubeconfig to [cluster-name]-kubeconfig
• [cluster-name]-kubeconfig to [cluster-name]-internal-kubeconfig

[ncdc]

Are you talking about the kubeconfig Secret? If so, it would be very difficult to rename it. It is a breaking contract change. There are lots of consumers using the current naming conventions.

We could consider something like adding a label to the Secret we want clusterctl get kubeconfig to retrieve (this would be something to discuss in the cluster-api repo).

cc @vincepri

[vincepri]

This is interesting, who's creating the "user" secret from above in this case? Is this something very specific to the EKS provider?

clusterctl get kubeconfig could provide the option to get a user specific secret, although I'd like to see a proposal in Cluster API to understand how we'd create the secret and with what permissions. The aim is to provide a consistent user experience across all providers

[felipeweb]

@vincepri it is specific for EKS https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/master/docs/eks.md

[vincepri]

Got it, I'd suggest to use some extra documentation in the CAPI book or here and provide a kubectl command for now, we can open an upstream issue to track a larger story that would apply to all providers for v1alpha4 or later, how does that sound?

[richardcase]

@vincepri @felipeweb - we need the 2 kubeconfigs for the EKS side of the provider. The kubeconfig that a user needs to use to connect uses the aws-iam-authenticator or aws cli binary to generate the token and this caused a problem from capi when it used the kubeconfig as the binary didn't doesn't exist in the capi images so we created. So we decided to create 2 separate kubeconfigs and document this in the EKS specific docs whilst the feature is experimental....it has the kubectl command in that.

Sounds great that this situation for providers be solved upstream in capi in future versions...i just created https://github.com/kubernetes-sigs/cluster-api/issues/3661

[fejta-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

[richardcase]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale

[richardcase]

/lifecycle frozen

[randomvariable]

/priority backlog

[randomvariable]

/area security

[richardcase]

/remove-lifecycle frozen

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.