I'd like to see the same behavior with kubeadm reset when the node being acted upon would remove etcd quorum.

kubeadm reset shows a confirmation prompt, unless the user passes -f.

$ kubeadm reset 
[reset] Reading configuration from the cluster...
[reset] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[reset] WARNING: Changes made to this host by 'kubeadm init' or 'kubeadm join' will be reverted.
[reset] Are you sure you want to proceed? [y/N]: 

its phases are documented, can be executed on demand or skipped:
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-reset/

Maybe the resolution to this is after the user presses 'y' and the cluster is determined to go unstable after such a request, a second warning is displayed alerting to such.

suggest default to N. e.g. Are you sure? (y/N)

Good call. Changed and explicitly called out.

Is y/N is the standard across Kubernetes ? In some places, we do use Yes/No.

I'll check for precedent.

Just tried locally, how initial development looks like (pardon for the verbose/warning :) )

@thockin @liggitt @eddiezane - If the interactive flag is not given, it suppose to go for delay. we can delay it using ticker but every second is expect to log as a line like ( Ignore the Order ascending or descending )

->resources will be deleted in 9 sec
->resources will be deleted in 8 sec... ??

Not sure if it is possible to do like state changes/clock in node/UI - resources will be delete in (9..8..7.....) ?

I agree with the statement - intent not to delete resource but accidentally being deleted. However, there are things that cannot be deleted are at different levels in Kubernetes like Kube-* namespaces, default namespaces if you try to delete it using the same kubectl command, it is 403 forbidden.

Do you think is it worth re-phrasing not that there are things that should never be deleted ?

how does this interact with other consumers of stdin in kubectl (e.g. client-go credential plugins that make use of stdin, or manifest reading from stdin like -f -)

I think it will matter where in the call stack we read stdin. The client-go credential plugins probably happen early the flow? I see this living near the end right inside the delete command.

Will need to play around with it with. We can have some integration tests for these.

What would you like to see about it in the KEP?

The client-go credential plugins probably happen early the flow?

I think it depends on where the client config is constructed.

What would you like to see about it in the KEP?

Describing specific places we use stdin in conjunction with kubectl delete calls today (-f -, exec plugins, etc), and that this --interactive option cannot be used in combination with those (and exercising the behavior when both are attempted with a testcase)

is this being proposed for delete invocations for:

• all --all invocations
• cluster-scoped resources
• namespacesd

is this being proposed for delete invocations for:

• all --all invocations

Yes.

• cluster-scoped resources
• namespacesd

Not specifically. Only when deleted with --all or --all-namespaces.

Scripts will see an x second delay unless they explicitly set -i=false.

I expected us to attempt to detect interactive invocations and only delay in those cases. That would limit the delay for scripts to environments which mimic interactive terminals, which seems better.

These were @thockin's thoughts.

I think I'd rather they set -i false explicitly
that is obvious AT THE CALL SITE as opposed to looking for ${CI} being set somewhere else
it's a big declaration of "I meant to do that"
When it comes to scary stuff I'll take "annoyingly explicit" every time
e.g. there's not a ${UNSAFE_RM} variable that implies -f

I did digging on detecting a TTY and it's a pretty mixed bag. A handful of CI/CD providers spoof a TTY to get nicer color output. I don't think we can reliably go that route.

A handful of CI/CD providers spoof a TTY to get nicer color output. I don't think we can reliably go that route.

If the issue is false positive detection of interactive invocations, introducing delays to those false positives seems ok to me