Deleting pods fails because the server returns a Pod object instead of a Status object

[qmfrederik]

When you delete a Pod, the server responds with a Pod object instead of a Status object.
The C# client tries to parse the Pod object as a Status object and fails.

This seems to be a general issue with the Swagger/OpenAPI definition of the Kubernetes API, see kubernetes/kubernetes#59501, kubernetes-client/java#86, kubernetes/kubernetes#25716, kubernetes/kubernetes#30537

Opening an issue here mainly to make it discoverable for others.

[qmfrederik]

OK - so it took me some digging to find out that was discussed before in #44 and an attempt to mitigate this has been made in #46 & #47.

I don't think the API is very intuitive but you can do something like this:

public static async Task<object> SafeDeleteNamespacedPodAsync(this IKubernetes client, V1DeleteOptions body, string name, string namespaceParameter, int? gracePeriodSeconds = null, bool? orphanDependents = null, string propagationPolicy = null, string pretty = null, CancellationToken cancellationToken = default)
{
   var result = await client.DeleteNamespacedPodAsync(body, name, namespaceParameter, gracePeriodSeconds, orphanDependents, propagationPolicy, pretty, cancellationToken).ConfigureAwait(false);

    if (result.ApiVersion != null || !result.HasObject)
    {
        return result;
    }
    else
    {
        return result.ObjectView<V1Pod>();
    }
}

[tg123]

the design wants to avoid returning an untyped object type.
I don't have any better idea,

[tintoy]

This behaviour was one of the issues that led to my suggestion in #101 :)

For what it's worth, here's how I handled it in dotnet-kube-client:

https://github.com/tintoy/dotnet-kube-client/blob/ff2d9bf577663e9c29994b383e67125ea60c13d0/src/KubeClient/ResourceClients/DeploymentClientV1Beta1.cs#L193-L212
https://github.com/tintoy/dotnet-kube-client/blob/ff2d9bf577663e9c29994b383e67125ea60c13d0/src/KubeClient/Models/StatusV1.cs#L11
https://github.com/tintoy/dotnet-kube-client/blob/ff2d9bf577663e9c29994b383e67125ea60c13d0/src/KubeClient/Models/KubeResourceListV1.cs#L13-L14
https://github.com/tintoy/dotnet-kube-client/blob/ff2d9bf577663e9c29994b383e67125ea60c13d0/src/KubeClient/Models/KubeObjectV1.cs#L11

Inheriting from KubeResourceList is non-obvious but according to the Swagger definitions, StatusV1 actually has a metadata property of type ListMetaV1 for some reason (rather than ObjectMetaV1) so that seemed like the simplest way to go about it.

[qmfrederik]

@tintoy That makes sense, so the API could look like this:

Task<KubeObjectV1> DeleteNamespacedPodAsync(this IKubernetes client, V1DeleteOptions body, string name, string namespaceParameter, int? gracePeriodSeconds = null, bool? orphanDependents = null, string propagationPolicy = null, string pretty = null, CancellationToken cancellationToken = default)

And calling code would be something like:

var result = await DeleteNamespacedPodAsync(...);
if(result.Kind == "Pod")
{
    ...
}
else if(result.Kind == "Status")
{
    ...
}

The advantage of this over the current implementation is that the caller can use the Kind property to determine what object is being returned, and make a decision based on that.

[tintoy]

Yep! Or if you're using newer C# versions you can use pattern matching :)

[hossambarakat]

Should we close this issue since the pull request has been merged?

[brendandburns]

I don't think that the Delete* code has been updated to return the parent type?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[qmfrederik]

I don't think that the Delete* code has been updated to return the parent type?

Correct, this issue still persists.

[tg123]

reopen for investigation

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.