Repository navigation
Blocking defect: api.deleteStack does not seem to work #2
Description
Activity
- changed the title
[-]api.deleteStack does not seem to work[/-][+]Blocking defect:api.deleteStack does not seem to work[/+]on Feb 15, 2020 - changed the title
[-]Blocking defect:api.deleteStack does not seem to work[/-][+]Blocking defect: api.deleteStack does not seem to work[/+]on Feb 15, 2020 see around line 761 in cli_1.log above
FYI:
I have also tried the old delete method as a work around, but it no longer works (gets a 404), I suspect because of version arrays in Spec now:
int rc = KubeUtils.deleteKubeResource(apiClient, namespace, name, group, version, "stacks");
@davco01a ok a couple of things here... I have a test program:
public static void main(String[] parms) { try { ApiClient client = Config.defaultClient(); Configuration.setDefaultApiClient(client); V1DeleteOptions deleteOptions = new V1DeleteOptions(); deleteOptions.setGracePeriodSeconds((long)3); deleteOptions.setOrphanDependents(true); deleteOptions.setKind("Stacks"); deleteOptions.setApiVersion("kabanero.io/v1alpha2"); StackApi stackApi = new StackApi(); System.out.println("Attempting to delete java-microprofile stack"); V1Status status = stackApi.deleteStack("kabanero", "java-microprofile", deleteOptions, 0, true, ""); System.out.println("Return status: " + status.toString()); } catch (Throwable t) { System.out.println("Caught an exception: " + t.toString()); t.printStackTrace(System.out); if (t instanceof ApiException) { ApiException ae = (ApiException) t; System.out.println("Message: " + ae.getMessage()); System.out.println("Code: " + ae.getCode()); System.out.println("Body: " + ae.getResponseBody()); } } }
and I am able to reproduce the 500 internal server error.
- If I don't pass a
V1DeleteOptionsobject then the delete works, but.... - then I get a JSON parsing exception because the kube server is not returning a
Statusobject, but is returning theStackobject that I deleted instead.
For 1) I think that there is some conflict between the
V1DeleteOptionsyou're passing, and the rest of the parameters. For 2) I need to research why the Kube API server is returning the deleted object instance instead of aStatusobject. In the end I guess I'll just change the code to read what it's sending back, but it makes no sense to me why it would return the object instance when every other delete operation says it returns status.If you look at the
StackApiit's really just a pass-thru, and I actually based it on what the CLI service was doing before. You should be able to continue doing what you were doing before. I don't know why you're getting a 404 when you do it the old way, but it has nothing to do with how the Stack object is structured. From the Kubernetes perspective, it doesn't care what's in the stack, it's just trying to delete it.- If I don't pass a
I've tried deleting
KabaneroandStackusing the REST API and in both cases it returns the object instance that we're deleting, not theV1Statusas the kube REST documentation suggests. So I'll update the return types on those.For the V1DeleteOptions I would suggest just not setting any of these if you don't need to (just pass null). There is no need to set a delete policy or grace period or anything unless you really need these (and understand what they do).
returning a stack object is consistent with stack=api.updateStack(
so it would be good to leave it as such
I wish I got to pick what the kube API server handed us back, we just have to go with what we get (which happens to be what you want, a Stack).
I'm closing this as fixed in release 0.6.1.
OK - so there may be more going on here. See this issue in the kube java client:
kubernetes-client/java#86I'm not sure I followed all of the conversation here, but, what may be happening is:
- If the deletion completes immediately, or if there's some other problem, you'll get a
V1Statusback - If something is taking a long time (ie if there's a finalizer we're waiting for) then you'll get the object instance back (in this case,
Stack) so that you can see that the deletion timestamp is set.
I have been writing unit tests for the operator bindings, and the kubernetes cluster where I'm testing does not have any part of Kabanero installed, just the CRDs. So, there are no finalizers. When I call
deleteStack()I get aV1Statusobject back, which of course now fails with a JSON parse exception because it's expecting aStack.The discussion in the java client issue seem to say that OpenAPI needs to support being able to return one or the other type. Java obviously allows only a single return type. The suggested workarounds included catching the exception, retry the delete, and see if the object is still there. That's hard to encapsulate in a client wrapper that shouldn't block. I suspect that where we'll end up is that we'll have to invent some return object type, that wraps both a
V1Statusand aStack, and only one or the other will actually get populated. Perhaps there'll be a boolean on there too which indicates whether the delete was actually successful (theStatuswas successful, or the returnedStackobject has the deletion timestamp set).- If the deletion completes immediately, or if there's some other problem, you'll get a
api.deleteStack does not seem to work
trying to delete a stack that only has one version and this call fails and does not return any response object to debug what went wrong:
`
V1DeleteOptions deleteOptions = new V1DeleteOptions();
deleteOptions.setGracePeriodSeconds((long)3);
deleteOptions.setOrphanDependents(true);
deleteOptions.setKind("stacks");
deleteOptions.setApiVersion(apiVersion);
v1status=api.deleteStack(namespace, kabStack.getSpec().getName(), deleteOptions, 0, true, "");