Kube-rs: api.delete can return a status object

[clux]

We had assumed that delete could be modelled as:

pub fn delete(&self, name: &str, dp: &DeleteParams) -> Result<Object<P, U>>;

but turns out kube sends:

{"kind":"Status","apiVersion":"v1","metadata":{},"status":"Success","details":{"name":"baz","group":"clux.dev","kind":"foos","uid":"XXX"}}

on a successful delete.

See #28 for more details. Fix client.request to fix this.

Edit: same is true for delete_collection (when it's not backgrounded).

[clux]

Tempted to use the either crate to make the return types:

pub fn delete(&self, name: &str, dp: &DeleteParams)
  -> Result<Either<Object<P, U>, Status>>;
pub fn delete_collection(&self, lp: &ListParams)
  -> Result<Either<ObjectList<Object<P, U>, Status>>;

[Ploppz]

Hey @clux , I was looking at the api of delete, and I wonder why does it actually return either a resource or a status? Based on the API docs of kubernetes (https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.17/#delete-cronjob-v1beta1-batch) it looks like it should only return a status and never the resource itself?

[clux]

Yeah, kubernetes isn't that great at documenting this. See https://github.com/kubernetes/kubernetes/issues/59501

At any rate, this resource itself does appear out of the api, and it's consistent across all resources. k8s-openapi even has a uniform DeleteResponse type that codifies this behaviour.

[Ploppz]

Thanks! Do you know if it is the case that whenever a status is returned rather than the deleted object, there was an error?

[clux]

No, that should not be true. Kube returns 4xx/5xx errors as Error so errors should not bubble up through Status in an Ok(Either::Right) but should come in as an Err(kube::Error::Api(ae)).

Generally, Ok(Left) (the object return) is "about to be deleted", and then you can poke o.status and often see stuff like:

reason: Some("InstanceDeletionPending"), status: "True", type_: "Terminating"

(that's from crd_api example).

If you get an Ok(Right), it's usually gone-gone. Don't think I've seen other types of responses :thinking:

In the examples we have slept a bit to wait for k8s to catch up, but it's possible to call a watch on object explicitly if you need to wait for a delete to have occurred.

This stuff probably needs better documentation.