Workaround for gson-syntax-exception upon deletion even if the deletion succeeds

[yue9944882]

Fixes: #86

this pull will be suppressing the GsonSyntaxException on deletion by adapting non-status resources into status during deserialization.

@brendandburns i think we should get this into 11.0.x releases.

[brendandburns]

Do we really want to do this? Doesn't this make every delete look like it's not done yet?

[yue9944882]

Doesn't this make every delete look like it's not done yet?

@brendandburns upon deletion calls, the kube-apiserver can return either a status object or the deleted state of the target object. however the method generated from openapi is only returning the status object. that's why we had this issue in the past. now it seems feasible to workaround by the extension provided by gson-fire library.

the only change this pull will bring to the project is making gson suppressing the runtime exception when deserializing a non-status object (e.g. deployment, pod) into a V1Status which will be happening when we successfully did a background deletion. this is actually done by casting/transforming the deleted object into a status object by removing "status" fields in order to solve the gson exception --- there's still information loss but it's way better than throwing a gson runtime exception surprisingly even if the deletion succeeded.. the failing behavior will not be changed anyway.

[brendandburns]

Ok, I went and dug up the actual code in the apiserver:

https://github.com/kubernetes/apiserver/blob/93ffe41e75d9d1c6cfe6d9224f8f5f474606b5b2/pkg/endpoints/handlers/delete.go#L144

I had thought that it returned V1Status when the delete wasn't completed, and the object when the delete was completed, but it looks like it's actually dependent on the deleter.

Given that, I think that this change is ok, even though it is a little lossy.

Let's file an issue to fix this better via oneOf instead of this work-around, so that we don't forget about the problem.

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: brendandburns, yue9944882

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [brendandburns,yue9944882]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment