add documentation for the server & client side timeout

[Priyankasaggu11929]

What type of PR is this?

/kind documentation

What this PR does / why we need it:

This PR documents information about server-side & client-side timeout in the examples/pod_namespace_watch.py example script.

Which issue(s) this PR fixes:

Fixes #1402

Does this PR introduce a user-facing change?

NONE

Signed-off-by: Priyanka Saggu [email protected]

[Priyankasaggu11929]

Thank you @yliaog for all the pointers.

I'll read through the links to understand the concepts better, & will update the PR.

[Priyankasaggu11929]

@yliaog, I've tried to redo the previous attempt of documentation, adding more information after reading & understanding through the links/pointers you provided above.

Please review. Thank you!

[yliaog]

what kind of network outage would cause this? it hangs when not accounting for the client side timeout described below, right?

[Priyankasaggu11929]

Re:

what kind of network outage would cause this?

I'm not sure how to define or specify the what kind of network outage part. Could you please phrase it or point me somewhere that talks more about the kind of network outage, I'll read more & try to add a proper definition here.

Thank you!

Re:

It hangs when not accounting for the client side timeout described below, right?

I might be wrong with my understanding, but so far, what I understood is ~

that it is the server side timeout (i.e. value of argument timeout_seconds, that would have no effect in case of the said network outage),

but in the same network outage situation, if there is a client-side timeout value set (i.e. a value for argument _requests_timeout) then the client would honor that timeout duration value & would wait for the same before dropping the connection.

Just a pointer from this comment here ~ #1148 (comment)

[Priyankasaggu11929]

@yliaog, no hurries at all. Just pointing in case, it was missed!

could you please take a look at this review comment too, as what more could be done to improve this section here?

Thank you so much!

[yliaog]

i think probably add the condition that client side timeout is not specified, something like below:

this timeout value will have no effect & the client will hang indefinitely without raising any exception if client side timeout (see below) is not specified

[Priyankasaggu11929]

@yliaog, Thank you for the pointers.

I'm rephrasing it as following: ~

In case of a network outage, the server side timeout value will have no effect & the client will hang indefinitely without raising any exception. Note, that this is the case provided when there is no other client-side timeout (i.e., _request_timeout) value specified.

(See the section below for information on client side timeout)

[Priyankasaggu11929]

@yliaog, I've updated the PR with the suggested review changes.

[yliaog]

thanks for the pr
/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Priyankasaggu11929, yliaog

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 [yliaog]

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

[Priyankasaggu11929]

/retest

[k8s-ci-robot]

@Priyankasaggu11929: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/retest

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.

[roycaihw]

travis-ci.org is in read-only mode