Proposal: rename 'debug' to 'debug-pod'

[ahmetb]

The current debug plugin’s name was discussed in #248, but I was not aware that @aylei's https://github.com/aylei/kubectl-debug plugin was already very popular.

We assigned the name debug to @verb's experimental plugin in #248 because that has a supporting KEP (and therefore a path to be an official subcommand).

However, at the same time, we assign submitted plugins with their original name (despite when the name is too generic) if they're already popular (ex: kubectl kubeval #259, or kubectl trace).

Since @verb's plugin is new and doesn't have many users, I think there's a small window of opportunity here:

• See if @aylei is interested in claiming name "debug" (please respond)
• If so, onboard aylei/kubectl-debug as debug, rename debug to debug-pod.
• If verb's proposal goes through and is incorporated to kubectl as a builtin, it will shadow any plugin with name "debug".
• This means existing debug users will switch to a different plugin upon upgrading, which I think is ok.

I think we'd love to have aylei/kubectl-debug on this repo regardless. Looks like this was gonna happen on #135, but we never got a follow-up PR. :)

[verb]

SGTM. I'll wait for @aylei to respond before renaming.

[corneliusweig]

After today's SIG CLI meeting I'm somewhat in favor of keeping the current name, despite @aylei's plugin having more users. @verb's KEP (kubernetes/enhancements#1204) has received good feedback and has good chances to make it into vanilla kubectl.
When this becomes a mainline kubectl sub-command, users will silently switch over from whatever is currently kubectl-debug. If that happens, I'd wish that the builtin command and the plugin be as similar as possible, otherwise the confusion becomes even worse.

In essence, this means that the plugin implementation with the better chances to become mainline should claim the debug name. And as far as I understand, this candidate is @verb's implementation.

[ahmetb]

Yes, since there's now a pseudo-agreement in SIG CLI (ref: today's meeting) to merge these two plugins (1) and offer a builtin kubectl debug, I think we can keep it as is.

(1) my understanding is that verb's plugin uses ephemeral pods, and aylei’s plugin uses launching a new pod in shared namespaces.

[corneliusweig]

ping @aylei
What are your thoughts about the kubectl-debug plugin naming in krew?

[aylei]

@corneliusweig @ahmetb
Sorry for missing the earlier threads, I prefer keeping the current kubectl-debug naming.

@corneliusweig 's opinion about the similarity in behavior before/after the mainline merges the debug implementation is exactly what I thought. My "kubectl-debug" still does not support CRI besides docker yet and is better to be considered as an alternative for old versions of kubernetes. And I'm going to join the effort of @verb 's propose to help landing the kubectl-debug in mainline😉

[ahmetb]

Thanks for the update.

Let's keep the plugins as is. @aylei if you're still interested in distributing via Krew, we're open to it!

Otherwise we'll wait until the day debug becomes a builtin kubectl command that automatically shadows any exiting plugin.

/close

[k8s-ci-robot]

@ahmetb: Closing this issue.

In response to this:

Thanks for the update.

Let's keep the plugins as is. @aylei if you're still interested in distributing via Krew, we're open to it!

Otherwise we'll wait until the day debug becomes a builtin kubectl command that automatically shadows any exiting plugin.

/close

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.

[markzhang0928]

@aylei give me a ride.. 😁