#396

/triage accepted
/help

We need to take a look if these types are pulled in by config as a start.

@eddiezane:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

@eddiezane I tried to resolve this issue, the AuthProviderConfig is a Ptr type of struct that define field of Name and Config. there is not a case to corresponding to the type in the switch. can you give me some advice?

After some review, this appears (I think) to be an issue with the client-go API rather than kubectl itself. The way that the paths are walked from the config key assumes that the AuthProvider field will be a map[string]*AuthProviderConfig. This is how we get from users.foo to auth-provider even though there is no valid field name in AuthInfo named foo.

Unsure if there should be a workaround for this specific struct in kubectl or if we should be open an issue with client-go repo to update the Config.AuthInfo.AuthProvider field to be a map to a pointer instead of just a raw pointer.

Also of note it looks like ExecConfig (e.g. users.foo.exec.command and similar) suffers the same issue.

@tewe Does kubectl config set-credential solve your use case? I think this may be a bit of a confusion in the docs (and maybe just update the error messages to point to the proper commands) here rather than a feature request.

Example:

❯ kubectl config set-credentials test --auth-provider=test --auth-provider-arg=refresh-token=test
User "test" set.

Resulting config:

❯ kubectl config view                                                                            
apiVersion: v1
<OMITTED>
- name: test
  user:
    auth-provider:
      config:
        refresh-token: test
      name: test

(My solution has been kubelogin)

Can --auth-provider-arg remove a key? Then it should be equivalent.

(In the case of the refresh token, setting it to a bogus value probably has the same effect)

It looks like if you were to use kubectl config set-credentials test --auth-provider=test --auth-provider-arg=refresh-token- (notice the - at the end) it will remove the specified arg key.

Thanks! I'll leave this open due to the confusing error message.

I noticed today that kubectl config set-credentials did not permit setting of the interactiveMode field, and kubectl config set users.my-user.exec.interactiveMode "IfAvailable" wouldn't patch it up afterwards.

It would be great to be able to set this field from the CLI.

Are there lists of what can and cannot be set easily available? That would be a nice quality of life improvement to have documented, perhaps in the --help. If this ticket accomplishes all fields, it won't be necessary to do that.

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

/remove-lifecycle stale

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

/remove-lifecycle stale

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

/remove-lifecycle stale

Is this still broken? The last pull request seems to have been closed.

Yes, unfortunately this became a rather monumental task. I had something working but it was decided that the sig did not wish to extend the existing dot delimited syntax (which makes sense) and instead we would look to moving to using jsonpath instead. Unfortunately I have not had time to do this and I don't think anyone else has tried to pick it up.

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

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

This bot triages un-triaged 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:

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

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

/lifecycle stale