"cancel/undo/rollback" PV delete

102 views
Skip to first unread message

Pippin Wallace

unread,
Jul 29, 2018, 11:35:55 PM7/29/18
to kubernetes-sig-storage
I apologize in advance for asking here, but where should I seek assistance for how to  "cancel/undo/rollback" a PV delete?

I have asked on stackoverflow and entered a case with GCP but with over 60 PV's in a "Status: Terminating (lasts 4h)" the suggestions are not practical.


Regards and apologizes again,

Pippin 

Tim Hockin

unread,
Jul 30, 2018, 12:17:40 AM7/30/18
to Pippin Wallace, kubernetes-sig-storage
Kubernetes does not have a concept of cancelling a delete.  Can you explain what you are trying to do?

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-st...@googlegroups.com.
To post to this group, send email to kubernetes-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-storage/9677fd3a-90ac-4f1e-ba91-fb11f3c974f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pippin Wallace

unread,
Jul 30, 2018, 12:25:54 AM7/30/18
to kubernetes-sig-storage
Hello Tim.

First, thank you very much for replying.  You are one of the top k8s leaders and I grateful for your contributions!

What I did was try to shoot my foot off by thinking that PV's where namespace scoped like PVC so I ran a # kubectl delete pv -n <namespace> and it tried to nuke them all.

So at this point I have all my PV's in a "Status: Terminating" but since they still have bound PVC's they are not being deleted.

What I would love to do is get the PV's back to a sane state with minimal data lose if possible.

Kind regards,

Pippin


On Sunday, July 29, 2018 at 10:17:40 PM UTC-6, Tim Hockin wrote:
Kubernetes does not have a concept of cancelling a delete.  Can you explain what you are trying to do?

On Sun, Jul 29, 2018, 8:35 PM Pippin Wallace <nip...@gmail.com> wrote:
I apologize in advance for asking here, but where should I seek assistance for how to  "cancel/undo/rollback" a PV delete?

I have asked on stackoverflow and entered a case with GCP but with over 60 PV's in a "Status: Terminating (lasts 4h)" the suggestions are not practical.


Regards and apologizes again,

Pippin 

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsub...@googlegroups.com.

Tim Hockin

unread,
Jul 30, 2018, 12:42:00 AM7/30/18
to Pippin Wallace, kubernetes-sig-storage, K8s API Machinery SIG, Daniel Smith, kubernete...@googlegroups.com, Saad Ali, Jing Xu, kubernetes-sig-architecture
Yikes!  Boy, we should really make that safer.  Maybe the API and/or CLI should fail somehow if namespace is specified for non-namespaced operations.

That said, there isn't really an undo.  It's not part of the object lifecycle, as currently defined.  Your only guaranteed option, probably, is to make new PVs as clones of the current ones (did you say which cloud?). This is probably something you have to do manually, though it may get easier in the future.

The problem is that, while you have a finalizer blocking progress, we don't know generically that no other finalizers have already run.  Something else might have been first and done some non-reversible operation.  So we can only go forward or stop, but not backwards.

I am sorry to say this.  It seems like an easy landmine to step on.  I didn't even know we supported bulk-delete like this - maybe we just shouldn't?

Tim

On Sun, Jul 29, 2018, 9:25 PM Pippin Wallace <nip...@gmail.com> wrote:
Hello Tim.

First, thank you very much for replying.  You are one of the top k8s leaders and I grateful for your contributions!

What I did was try to shoot my foot off by thinking that PV's where namespace scoped like PVC so I ran a # kubectl delete pv -n <namespace> and it tried to nuke them all.

So at this point I have all my PV's in a "Status: Terminating" but since they still have bound PVC's they are not being deleted.

What I would love to do is get the PV's back to a sane state with minimal data lose if possible.

Kind regards,

Pippin


On Sunday, July 29, 2018 at 10:17:40 PM UTC-6, Tim Hockin wrote:
Kubernetes does not have a concept of cancelling a delete.  Can you explain what you are trying to do?

On Sun, Jul 29, 2018, 8:35 PM Pippin Wallace <nip...@gmail.com> wrote:
I apologize in advance for asking here, but where should I seek assistance for how to  "cancel/undo/rollback" a PV delete?

I have asked on stackoverflow and entered a case with GCP but with over 60 PV's in a "Status: Terminating (lasts 4h)" the suggestions are not practical.


Regards and apologizes again,

Pippin 

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-st...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-st...@googlegroups.com.

To post to this group, send email to kubernetes-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-storage/a581c6f3-8b62-4de7-b433-200a6d6ab2d2%40googlegroups.com.

Pippin Wallace

unread,
Jul 30, 2018, 12:50:25 AM7/30/18
to kubernetes-sig-storage
When I get a "Yikes" from you I know I should back away from the keyboard ;)

If it helps I am on GKE and have these set in my PV's "Finalizers: [kubernetes.io/pv-protection foregroundDeletion]"

I have made snapshots of all disks with something like the following --> but what does a " PV clone " look?

    ==> for i in `cat only.PDs-used-by-PVs  | awkp1` ; do gcloud compute disks snapshot $i  ; done

Thanks again Tim!

Pippin


On Sunday, July 29, 2018 at 10:42:00 PM UTC-6, Tim Hockin wrote:
Yikes!  Boy, we should really make that safer.  Maybe the API and/or CLI should fail somehow if namespace is specified for non-namespaced operations.

That said, there isn't really an undo.  It's not part of the object lifecycle, as currently defined.  Your only guaranteed option, probably, is to make new PVs as clones of the current ones (did you say which cloud?). This is probably something you have to do manually, though it may get easier in the future.

The problem is that, while you have a finalizer blocking progress, we don't know generically that no other finalizers have already run.  Something else might have been first and done some non-reversible operation.  So we can only go forward or stop, but not backwards.

I am sorry to say this.  It seems like an easy landmine to step on.  I didn't even know we supported bulk-delete like this - maybe we just shouldn't?

Tim

On Sun, Jul 29, 2018, 9:25 PM Pippin Wallace <nip...@gmail.com> wrote:
Hello Tim.

First, thank you very much for replying.  You are one of the top k8s leaders and I grateful for your contributions!

What I did was try to shoot my foot off by thinking that PV's where namespace scoped like PVC so I ran a # kubectl delete pv -n <namespace> and it tried to nuke them all.

So at this point I have all my PV's in a "Status: Terminating" but since they still have bound PVC's they are not being deleted.

What I would love to do is get the PV's back to a sane state with minimal data lose if possible.

Kind regards,

Pippin


On Sunday, July 29, 2018 at 10:17:40 PM UTC-6, Tim Hockin wrote:
Kubernetes does not have a concept of cancelling a delete.  Can you explain what you are trying to do?

On Sun, Jul 29, 2018, 8:35 PM Pippin Wallace <nip...@gmail.com> wrote:
I apologize in advance for asking here, but where should I seek assistance for how to  "cancel/undo/rollback" a PV delete?

I have asked on stackoverflow and entered a case with GCP but with over 60 PV's in a "Status: Terminating (lasts 4h)" the suggestions are not practical.


Regards and apologizes again,

Pippin 

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsub...@googlegroups.com.

Mo Khan

unread,
Jul 30, 2018, 1:47:15 AM7/30/18
to Tim Hockin, Pippin Wallace, kubernetes-sig-storage, K8s API Machinery SIG, Daniel Smith, kubernete...@googlegroups.com, Saad Ali, Jing Xu, kubernetes-sig-architecture, Maciej Szulik
https://github.com/kubernetes/kubernetes/pull/62167 seems relevant?  I thought we already had a check for this type of error though...




You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAO_RewYkkOrbJ%3Dxydj%2BJj50pRSbqzR25ysALCOZo5VhmBgXyxQ%40mail.gmail.com.

Pippin Wallace

unread,
Jul 30, 2018, 1:53:14 AM7/30/18
to kubernetes-sig-storage
Here is the setup I am running.  Please let me know if you would like more details.

==> kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-06-06T00:44:24Z", GoVersion:"go1.9.6", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.2-gke.3", GitCommit:"d2c7a2bd41036f9474287579a725dc54c904e92d", GitTreeState:"clean", BuildDate:"2018-05-23T00:19:39Z", GoVersion:"go1.9.3b4", Compiler:"gc", Platform:"linux/amd64"}
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.

Clayton

unread,
Jul 30, 2018, 9:00:39 AM7/30/18
to Tim Hockin, Pippin Wallace, kubernetes-sig-storage, K8s API Machinery SIG, Daniel Smith, kubernete...@googlegroups.com, Saad Ali, Jing Xu, kubernetes-sig-architecture
kubectl should absolutely not allow “kubectl delete -n ‘’” to work.  We have —all-namespaces —all for that.  No one would typo the latter.

Please file a high severity issue and we’ll fix this for 1.12.
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAO_RewYkkOrbJ%3Dxydj%2BJj50pRSbqzR25ysALCOZo5VhmBgXyxQ%40mail.gmail.com.

Pippin Wallace

unread,
Jul 30, 2018, 9:05:23 AM7/30/18
to kubernetes-sig-storage
Claton, might you have a suggested way to "fix" this besides recreating all PV's and claims?  I am still trying to undo this mess.

Thank you -- Pippin
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.

David Eads

unread,
Jul 30, 2018, 9:08:44 AM7/30/18
to Clayton, Tim Hockin, nip...@gmail.com, kubernetes-...@googlegroups.com, K8s API Machinery SIG, Daniel Smith, kubernetes-sig-cli, Saad Ali, ji...@google.com, kubernetes-sig-architecture
I'll argue Jordan's side until he gets in.  When you are creating many items from multiple manifests that contain both namespaced and non-namespaced resources (imagine something creating a CRD), you may very well do `kubectl apply -f /dir/ -n my-namespace`.  When you do this, you want the namespaced things to be namespaced and non-namespaced ones created.  If we make that command start failing instead, the user will be very frustrated.  Similarly, to clean up I want to do `kubectl delete -f /dir/ -n my-namespace`.

In addition to the you "fixed" this and broke kubectl backwards compatibility, the experience and consistency of kubectl would be broken.  I feel for the user (I've been in this situation before), but when you're managing resources with cluster-admin rights you need to be very careful about what you do.

You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-m...@googlegroups.com.
To post to this group, send email to kubernetes-sig...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/3DA6A16B-EA72-4307-B568-98FC784E58B8%40gmail.com.

Clayton Coleman

unread,
Jul 30, 2018, 9:14:08 AM7/30/18
to Clayton, Tim Hockin, Pippin Wallace, kubernetes-sig-storage, K8s API Machinery SIG, Daniel Smith, kubernete...@googlegroups.com, Saad Ali, Jing Xu, kubernetes-sig-architecture
It’s probably also time we consider requiring delete of bulk cluster scoped resource to require an additional flag to confirm the action, possibly just in interactive mode.  There’s just so few scenarios that it’s  done that the extra check is ok.
You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-m...@googlegroups.com.
To post to this group, send email to kubernetes-sig...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/3DA6A16B-EA72-4307-B568-98FC784E58B8%40gmail.com.

Pippin Wallace

unread,
Jul 30, 2018, 9:14:55 AM7/30/18
to kubernetes-sig-storage
David, Would a warning be acceptable for admins who are new or just tired ;) 
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-machinery+unsub...@googlegroups.com.

Clayton Coleman

unread,
Jul 30, 2018, 9:18:18 AM7/30/18
to David Eads, Clayton, Tim Hockin, nip...@gmail.com, kubernetes-...@googlegroups.com, K8s API Machinery SIG, Daniel Smith, kubernetes-sig-cli, Saad Ali, ji...@google.com, kubernetes-sig-architecture
I was talking about explicitly breaking how deleting cluster scoped resources work to be safer.

A human at a keyboard should never accidentally delete all pv.  No matter what.  There needs to be a safety harness.  If the user then gets in the habit of bypassing the safety harness, that’s fine.  But not offering the safety harness isn’t really an acceptable outcome - you deserve to be sued.

I’m not disagreeing to your point about not running as cluster admin and using sudo impersonate (that’s safer), or that we might make this something that only happens in interactive shells.

Tim Hockin

unread,
Jul 30, 2018, 11:31:05 AM7/30/18
to Clayton Coleman, David Eads, Clayton Coleman, Pippin Wallace, kubernetes-sig-storage, K8s API Machinery SIG, Daniel Smith, kubernete...@googlegroups.com, Saad Ali, Jing Xu, kubernetes-sig-architecture
I can buy the argument that having a dir of mixed namespaced and non-namespaced is supported today, so breaking it would be bad.

I'm not arguing that any form of `kubectl <something> -f <dir>` should change.

I am agreeing with Clayton that any form of bulk delete be more safe.  User suggested that `kubectl delete pv -n <namespace>` is what caused this, but I can't seem to repro that:  `error: resource(s) were provided, but no name, label selector, or --all flag specified`

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-storage/CAH16Sh%2BCPv0BRo_wYgbW0OwPdveEESxVppT3jf4FHGZDLv2xuw%40mail.gmail.com.

Clayton

unread,
Jul 30, 2018, 11:38:50 AM7/30/18
to Tim Hockin, Clayton Coleman, David Eads, Pippin Wallace, kubernetes-sig-storage, K8s API Machinery SIG, Daniel Smith, kubernete...@googlegroups.com, Saad Ali, Jing Xu, kubernetes-sig-architecture
You’d have this with

kubectl delete —all -n foo pv

Arguably specifying both -n and -all for cluster scoped resources should error.  

kubectl delete —all -n foo pv
error: PersistentVolumes are cluster scoped

kubectl delete —all -n foo pv,pvc
<we assume you know what you’re doing>

Pippin Wallace

unread,
Jul 30, 2018, 11:50:26 AM7/30/18
to kubernetes-sig-storage
Here is what was run -->

#! /bin/bash
NAMESPACE=application

kubectl delete $(kubectl get pvc -o name --namespace=$NAMESPACE) --namespace=$NAMESPACE
kubectl delete $(kubectl get pv -o name --namespace=$NAMESPACE) --namespace=$NAMESPACE
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-machinery+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-machinery+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-storage+unsub...@googlegroups.com.

Fox, Kevin M

unread,
Jul 30, 2018, 11:57:33 AM7/30/18
to Tim Hockin, Pippin Wallace, kubernetes-sig-storage, K8s API Machinery SIG, Daniel Smith, kubernete...@googlegroups.com, Saad Ali, Jing Xu, kubernetes-sig-architecture
Yeah. Is it ever a good idea to allow such an easy bulk delete of all pv's? I'd say, no.

you can always list them out and do a for loop over them to delete if you really really wanted to nuke the universe.

Perhaps a 'do you really want to delete these items Y/N' should be added to all the delete all type operations too, unless the user specifies a -y.

Thanks,
Kevin
From: 'Tim Hockin' via kubernetes-sig-storage [kubernetes-...@googlegroups.com]
Sent: Sunday, July 29, 2018 9:41 PM
To: Pippin Wallace
Cc: kubernetes-sig-storage; K8s API Machinery SIG; Daniel Smith; kubernete...@googlegroups.com; Saad Ali; Jing Xu; kubernetes-sig-architecture
Subject: Re: "cancel/undo/rollback" PV delete

Tim Hockin

unread,
Jul 30, 2018, 12:22:07 PM7/30/18
to Kevi...@pnnl.gov, Pippin Wallace, kubernetes-sig-storage, K8s API Machinery SIG, Daniel Smith, kubernete...@googlegroups.com, Saad Ali, Jing Xu, kubernetes-sig-architecture
We have to be careful not to break scripts that people have already written.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-storage/1A3C52DFCD06494D8528644858247BF01C15E563%40EX10MBOX03.pnnl.gov.

imi...@figure.com

unread,
Jul 30, 2018, 1:17:10 PM7/30/18
to kubernetes-sig-storage
It seems logical to me that when a given resource is not scoped by namespace ... if a command is scoped with the `--namespace` flag then kubectl should not return that resource at all... 

In other words if `kubectl get pv --namespace=foo` is executed ... nothing should be returned as the PV is not part of the foo namespace.

Regards,

Ira

Tim Hockin

unread,
Jul 30, 2018, 1:33:44 PM7/30/18
to imi...@figure.com, kubernetes-sig-storage
I don't disagree, but that is fundamentally a breaking change to the CLI.  This has to be handled carefully.

This message and its contents are confidential. If you received this message in error, do not use or rely upon it. Instead, please inform the sender and then delete it. Thank you.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-storage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-st...@googlegroups.com.
To post to this group, send email to kubernetes-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-storage/7d0cde63-ebfe-4bd2-aba7-5373ada480fa%40googlegroups.com.

Mehdy Bohlool

unread,
Jul 31, 2018, 6:48:28 PM7/31/18
to Tim Hockin, Kevi...@pnnl.gov, nip...@gmail.com, kubernetes-...@googlegroups.com, K8s API Machinery SIG, Daniel Smith, kubernete...@googlegroups.com, Saad Ali, Jing Xu, kubernetes-si...@googlegroups.com
Maybe something like this:

$ kubectl delete -all pv  # regardless of -n flag
*** This action marked as dangerous ***
You are about to delete 36 Cluster scoped Persistent Volumes. 
If that is not your intention, you have 30 seconds to stop this by pressing Ctrl+C ...

and count down the seconds in the message. We may want to do that for all cluster-scoped types or apply some rule on the type and number of items to be deleted. We can even make this configurable (what types are dangerous to delete, etc.) by cluster admin. This will not break any script and the message can be silenced by a flag (--sure?).


Mehdy Bohlool | Software Engineer | me...@google.com | mbohlool@github 



You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-m...@googlegroups.com.
To post to this group, send email to kubernetes-sig...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/CAO_RewZN%3DOHga1hTs4Zs%2BVbN9SyafN%3DevwjZSHH_HDvQo9D2kA%40mail.gmail.com.

Clayton

unread,
Jul 31, 2018, 7:00:18 PM7/31/18
to Mehdy Bohlool, Tim Hockin, Kevi...@pnnl.gov, nip...@gmail.com, kubernetes-...@googlegroups.com, K8s API Machinery SIG, Daniel Smith, kubernete...@googlegroups.com, Saad Ali, Jing Xu, kubernetes-si...@googlegroups.com
That will just slow scripts down, without actually making them safer.

Interactive mode vs not as the cue to prompt is pretty normal in this case (require confirmation), which doesn’t affect scripts.

I’m not sure I’ve seen a CLI that does something quite like you describe, and the time limit could be just as dangerous if someone looks away.

Our goal is identify and warn users predictably.  Confirmation before broad bulk action is usually a flag, a prompt, or similar interaction.  I’d suggest we don’t stray too far from common practice. 
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CACd0WeE-nQKFS-J5k004W8qs0CraPZsxgku%3DOb051yh_Q6QxuQ%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages