Support cascading delete on custom resources

[rimesc]

The interface returned by KubernetesClient.customResources(...) doesn't provide a method to set cascading=true.

The object itself (an instance of CustomResourcesOperationsImpl) does have a cascading flag, and a constructor that allows it to be specified, but it's defaulted to false in the only constructor that's actually used.

As a work around, you can construct an instance yourself using the constructor that does have the relevant parameter, but it would be helpful if the interface had a method for setting it, as other resource types do. It's worth noting that while technically the object does have a method for setting cascading=true that it inherits from the base class, casting to the base class and calling the method explodes because it uses reflection to find a suitable constructor and no such constructor exists in this case.

In particular, this makes it difficult to delete Argo workflows and their underlying pods.

[Nighthawk22]

Any idea how to work around the issue?

[rohanKanojia]

@rimesc : Hi, Are you talking about Custom Resource Definition (CRDs) or Custom Resources(CRs). I looked into CustomResourceOperationsImpl and CustomResourceDefinitionOperationsImpl but I could not find the cascading flag you talked about.

We do have cascade deletion of replica sets before deleting deployment. But we do that on our own. So how cascading delete on Custom Resources would work? One thing could be deleting all the Custom Resources(CRs) before deleting Custom Resource Definition (CRDs). Or would cascade deletion's behavior would change depending upon Custom Resource Definition (CRDs)? Do you know how kubectl handles cascade deletion for Custom Resources?

Would really appreciate if you could provide some input so that I can move forward.

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[rohanKanojia]

@rimesc @Nighthawk22: Sorry for the late reply. I'm looking into this issue and found out that it's possible to set both cascading flag and propagation policies( for more fine tuned control) like this:

      NonNamespaceOperation<Dummy, DummyList, DoneableDummy, Resource<Dummy, DoneableDummy>> dummyClient = client.customResources(dummyCRD, Dummy.class, DummyList.class, DoneableDummy.class);
      if (resourceNamespaced) {
        dummyClient = ((MixedOperation<Dummy, DummyList, DoneableDummy, Resource<Dummy, DoneableDummy>>) dummyClient).inNamespace(namespace);

        // Set Cascading flag, which would set OrphanDpendents in DeleteOptions
        dummyClient.withName("xyc").cascading(true).delete();
        // Set propagation policy for deletion
        dummyClient.withName("xyz").withPropagationPolicy("Foreground").delete();
      }

However, our typeless api still hasn't got support for this. I'll add it there also then I would close this.