The committers listed above are authorized under a signed CLA.

• ✅ login: lalitc375 / name: Lalit Chauhan (00b4498)

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Hi @lalitc375. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

This PR may require API review.

If so, when the changes are ready, complete the pre-review checklist and request an API review.

Status of requested reviews is tracked in the API Review project.

Previously, there was a PR about remove this flag #122104.

/cc @saschagrunert @haircommander

Previously, there was a PR about remove this flag #122104.

/cc @saschagrunert @haircommander

I am just marking this field deprecated, not removing it. To make it obvious to the users.

what is the alternative way to configure it today?

/ok-to-test

/retest

what is the alternative way to configure it today?

There is stream_idle_timeout in the containerd config, that is also broken if it is greater than 5 secs. containerd/containerd#5563

cc: @aojea

what is the alternative way to configure it today?

There is stream_idle_timeout in the containerd config, that is also broken if it is greater than 5 secs. containerd/containerd#5563

cc: @aojea

This had a problem with the implementation and the semantics of the flag didn't match, and also the place to implement it was in the wrong place see #102569 (comment) ... so it is indeed broken and confusing, if users want to implement session timeout the right place should be in the client that is able to do per session timeouts configurable and proper context support was added some time ago #103177 so it is perfectly possible to implement session timeout client side

I can't find now the issue or the discussion but I think there was also a proposal somewhere to add this session timeout to kubectl cc: @seans3 @soltysh

/lgtm

LGTM label has been added.

I can't find now the issue or the discussion but I think there was also a proposal somewhere to add this session timeout to kubectl cc: @seans3 @soltysh

I can't recall, maybe Sean has. I don't think that specific options is something we'd want to expose, though. Not in kubectl at least, we have other options to timeout the connection.

/label api-review
since this is modifying API, it has to go through the proper review process, I'm going to take the initial stab at it, as an api reviewer shadow

since this is modifying API, it has to go through the proper review process, I'm going to take the initial stab at it, as an api reviewer shadow

FYI @soltysh this option/flag is a noop in the kubelet 😄

/lgtm
/approve

since this is noop for some time and the replacement will require it's own feature, let's fix this to avoid confusions

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: lalitc375, SergeyKanzhelev
Once this PR has been reviewed and has the lgtm label, please assign smarterclayton for approval. For more information see the Code Review Process.

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

/assign @thockin

for api-approvers