Document semantic of resourceVersion=0.

[oxddr]

/assign @mm4tt @wojtek-t

[k8s-ci-robot]

Welcome @oxddr!

It looks like this is your first PR to kubernetes/website 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/website has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign chenopis
You can assign the PR to them by writing /assign @chenopis in a comment when ready.

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

Needs approval from an approver in each of these files:

• content/en/OWNERS

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

[liggitt]

This isn't guaranteed to be served from the API server cache (watch cache is optional). I also don't think we should encourage use of this (see problems discussed in kubernetes/kubernetes#74022).

If we document this, it should come with big warnings and discourage use.

[oxddr]

Thanks for a pointer, I'll read it. I think @mm4tt or @wojtek-t may have more context on why we want this feature to be documented. We recently had problem due to this feature being undocumented well. That said I'm fine with adding warning sign here.

[wojtek-t]

I agree with first two things:

• the cache is not guaranteed
• this requires a huge warning and we need to mention consequences and describe cases where it may work

But I actually don't agree with the "discouraging" part - there are some cases where it is really needed for scalability. But yeah - we need to be much more careful when adding note about it.

[liggitt]

I actually don't agree with the "discouraging" part - there are some cases where it is really needed for scalability

this is in the watch section. we don't want people watching from 0.

[wojtek-t]

Ooops sorry - I thought it's about LIST. I agree we don't want people watching from 0.

[wojtek-t]

So to clarify: I'm not trying to say that now everyone should be using it - absolutely not. But there are cases, where you may need it if you need to scale (though I fully agree that it requires very good understanding of potential consequences).

BTW - I believe that we will fix at least majority of time-travel problems in 1.17 - @jpbetz

[liggitt]

I strongly fall in the "first be correct, then be performant" camp.

With reflectors, we got ourselves in a situation where we realized too late the pitfalls of what we were doing, and couldn't easily back out changes without regressing performance to the point of breaking existing clusters.

I would not recommend anyone who is not using this already start using it until the issues are resolved. If that is in 1.17, great, we can make the warning conditional at that point.

[wojtek-t]

I strongly fall in the "first be correct, then be performant" camp.

I agree - but I don't think that exclude what I'm saying.

What I'm saying is that, we know the circumstances under which time-travel can happen - so we can describe those here. It's up to the user to understand what are the consequences of time-travel in their case and if those can be mitigated on their side - we will never make it a default - it will always be user`s decision.

[jpbetz]

In #16910 I've attempted to put in ample warnings about the RV="0" semantic. E.g. "...any starting resource version is allowed. In high availabiliy configurations, it is possible for the watch to start at a much older resource version that the client has previously observed, due to partitions or stale caches. Clients that cannot tolerate this should not start a watch with this semantic" (https://github.com/kubernetes/website/pull/16910/files#diff-909a5da840997c07f02b50d20399d9a1R725).

The language is not quite as strong as "using RV=0 voids your warranty", but tries to express the "be sure you know what you're doing". WDYT?

[wojtek-t]

The language is not quite as strong as "using RV=0 voids your warranty", but tries to express the "be sure you know what you're doing". WDYT?

That is exactly the message that I would like to pass here.

[netlify]

Deploy preview for kubernetes-io-master-staging ready!

Built with commit 35108ec

https://deploy-preview-16944--kubernetes-io-master-staging.netlify.com

[jpbetz]

I've opened a PR yesterday to document the resourceVersion semantic as well: #16910

Okay if I incorporate thoughts in the comments here into that PR?

[mm4tt]

I've opened a PR yesterday to document the resourceVersion semantic as well: #16910

Okay if I incorporate thoughts in the comments here into that PR?

Sure, thanks, @jpbetz.

In that case I believe we can close this one.

[oxddr]

I've opened a PR yesterday to document the resourceVersion semantic as well: #16910

Okay if I incorporate thoughts in the comments here into that PR?

Sure, let's move the discussion to your PR!

/close

[k8s-ci-robot]

@oxddr: Closed this PR.

In response to this:

I've opened a PR yesterday to document the resourceVersion semantic as well: #16910

Okay if I incorporate thoughts in the comments here into that PR?

Sure, let's move the discussion to your PR!

/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.