grace_period_seconds=0 ignored for stop requests

[oalbrigt]

What happened (please include outputs or screenshots):
grace_period_seconds=0 is ignored when running the following code:

        from kubernetes import config
        from openshift.dynamic import DynamicClient
        kubeconfig = options.get('--kubeconfig')
        k8s_client = config.new_client_from_config(config_file=kubeconfig)
        conn = DynamicClient(k8s_client)
        conn.request('put', path, header_params={'accept': '*/*'}, grace_period_seconds=0 if action == 'stop' else None)

https://github.com/ClusterLabs/fence-agents/pull/616/files

We have upgraded to the following lib versions to try to solve the issue (the earlier openshift version was overriding the request() function):
openshift: 0.13.2
kubernetes: 32.0.1

What you expected to happen:
I expected instant force-off, but instead it takes the same amount of time to stop as regular stop.

How to reproduce it (as minimally and precisely as possible):
Use fence_kubevirt from the PR linked above.

Anything else we need to know?:

Environment:

• Kubernetes version (kubectl version): 4.17
• OS (e.g., MacOS 10.13.6): RHEL 9.5
• Python version (python --version): 3.9.21
• Python client version (pip list | grep kubernetes):

[yliaog]

/help

[k8s-ci-robot]

@yliaog:
This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

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-sigs/prow repository.

[p172913]

/assign

[p172913]

Checked using grace_period_seconds option in DynamicClient in kubernetes. Got following results.
it is showing
📊 Benchmark Results:
Average time (grace_period_seconds=0): 0.029348 seconds
Average time (grace_period_seconds=None): 39.410963 seconds

By using DynamicClient from Openshift gave
Average time (grace_period_seconds=0): 0.043907 seconds
Average time (grace_period_seconds=None): 36.797628 seconds

[oalbrigt]

My test was with /stop requests, not /delete. I got the same results with and without specifying grace_period_seconds=0.

[p172913]

I am not sure with DynamicClient has stop attribute

@yliaog can you confirm there is stop function in DynamicClient ...

[yliaog]

@fabianvf could you help answer the question about DynamicClient?

[p172913]

@yliaog , @fabianvf is there any update on this...?

[p172913]

@yliaog , @fabianvf is there any update on this...?

[yliaog]

i'll leave it to @fabianvf

[fabianvf]

No, I don't believe there is a built-in stop function in the dynamic client. If it's a subresource call, it'll be exposed automatically after discovery for the resources that expose it, but there is no bespoke implementation for most subresources. If the behavior of the subresource differs from the typical, and it is not a built-in kubernetes one (like exec/logs), you're probably better off with a more specific client that can handle those differences in behavior that can't be discovered/handled by just looking at the API endpoint