Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

watch loses resource version when watching custom object list #700

Closed
juliantaylor opened this issue Dec 11, 2018 · 4 comments
Closed

watch loses resource version when watching custom object list #700

juliantaylor opened this issue Dec 11, 2018 · 4 comments

Comments

@juliantaylor
Copy link
Contributor

juliantaylor commented Dec 11, 2018 •
edited

kubernetes often resets watches when no changes happen (kubernetes/kubernetes#55230 (comment)), thus I have added a restart at the last resource version to my application

But the python api library resets this to zero on iteration of this loop and thus retrieves all objects again.
https://github.com/kubernetes-client/python-base/blob/83ebb9d5fdc0d46bbb2e30afcd8eec42c5da4ad1/watch/watch.py
This happens in current master using the list_cluster_custom_object function as a watch running against kubernetes 1.12.3.

Can this please be updated to respect the resource version set by the application or fix that it resets to version zero each time.
@juliantaylor
Copy link
Contributor Author

juliantaylor commented Dec 11, 2018 •
edited

reproducing script:

manifests:

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: mycustoms.crd.mycustom.org
spec:
  version: v1
  group: crd.mycustom.org
  names:
    kind: MyCustom
    plural: mycustoms
    singular: mycustom
  scope: Namespaced
  subresources:
    status: {}
---
apiVersion: crd.mycustom.org/v1
kind: MyCustom
metadata:
  name: customobj
  namespace: default
spec:
  data: test

import kubernetes as k8s
k8s.config.load_kube_config()
api = k8s.client.CustomObjectsApi()
group = "crd.mycustom.org"
plural = "mycustoms"
version = "v1"
items = api.list_cluster_custom_object(group=group, plural=plural, version=version)
ver = items["metadata"]["resourceVersion"]

kwargs = {}
kwargs["resource_version"] = ver
kwargs["watch"] = True
for event in k8s.watch.Watch().stream(api.list_cluster_custom_object, group, version, plural, **kwargs):
    print(event["metadata"]["resourceVersion"])

Run with printing the resource version in kubernetes/client/apis/custom_objects_api.py list_cluster_custom_object_with_http_info

[('resourceVersion', '1209375'), ('watch', True)] # correct first watch
[('resourceVersion', 0), ('watch', True)] # incorrect version on first reset

@juliantaylor juliantaylor changed the title watch loses resource version when resetting custom object list watch loses resource version when watching custom object list Dec 11, 2018
@juliantaylor
Copy link
Contributor Author

juliantaylor commented Dec 11, 2018 •
edited

probably a duplicate of #693

@juliantaylor juliantaylor mentioned this issue Dec 11, 2018
Closed
@max-rocket-internet
Copy link

probably a duplicate of what issue? You've linked back to this one. Maybe you meant #693 ?

@juliantaylor
Copy link
Contributor Author

fixed and updated the reproducer with manifests

@juliantaylor juliantaylor mentioned this issue Dec 11, 2018
Closed
juliantaylor added a commit to juliantaylor/python-base that referenced this issue Dec 11, 2018
@juliantaylor
fix watching with a specified resource version
f75e421 
The watch code reset the version to the last found in the
response.
When you first list existing objects and then start watching from that
resource version the existing versions are older than the version you
wanted and the watch starts from the wrong version after the first
restart.
This leads to for example already deleted objects ending in the stream
again.

Fix this by not resetting to an older version than the one specified in
the watch.
It does not handle overflows of the resource version but they are 64 bit
integers so they should not realistically overflow even in the most loaded
clusters.

Closes kubernetes-client/python#700
@juliantaylor juliantaylor mentioned this issue Dec 11, 2018
Merged
juliantaylor added a commit to juliantaylor/python-base that referenced this issue Dec 11, 2018
@juliantaylor
fix watching with a specified resource version
7c6f480 
The watch code reset the version to the last found in the
response.
When you first list existing objects and then start watching from that
resource version the existing versions are older than the version you
wanted and the watch starts from the wrong version after the first
restart.
This leads to for example already deleted objects ending in the stream
again.

Fix this by not resetting to an older version than the one specified in
the watch.
It does not handle overflows of the resource version but they are 64 bit
integers so they should not realistically overflow even in the most loaded
clusters.

Closes kubernetes-client/python#700
juliantaylor added a commit to juliantaylor/python-base that referenced this issue Dec 11, 2018
@juliantaylor
fix watching with a specified resource version
5cab3de 
The watch code reset the version to the last found in the
response.
When you first list existing objects and then start watching from that
resource version the existing versions are older than the version you
wanted and the watch starts from the wrong version after the first
restart.
This leads to for example already deleted objects ending in the stream
again.

Fix this by not resetting to an older version than the one specified in
the watch.
It does not handle overflows of the resource version but they are 64 bit
integers so they should not realistically overflow even in the most loaded
clusters.

Closes kubernetes-client/python#700
juliantaylor added a commit to juliantaylor/python-base that referenced this issue Dec 12, 2018
@juliantaylor
fix watching with a specified resource version
5eb6633 
The watch code reset the version to the last found in the
response.
When you first list existing objects and then start watching from that
resource version the existing versions are older than the version you
wanted and the watch starts from the wrong version after the first
restart.
This leads to for example already deleted objects ending in the stream
again.

Fix this by not resetting to an older version than the one specified in
the watch.
It does not handle overflows of the resource version but they are 64 bit
integers so they should not realistically overflow even in the most loaded
clusters.

Closes kubernetes-client/python#700
juliantaylor added a commit to juliantaylor/python-base that referenced this issue Jan 19, 2019
@juliantaylor
fix watching with a specified resource version
3219b84 
The watch code reset the version to the last found in the
response.
When you first list existing objects and then start watching from that
resource version the existing versions are older than the version you
wanted and the watch starts from the wrong version after the first
restart.
This leads to for example already deleted objects ending in the stream
again.

Fix this by setting the minimum resource version to reset from to the
input resource version. As long as k8s returns all objects in order in
the watch this should work.
We cannot use the integer value of the resource version to order it as
one should be treat the value as opaque.

Closes kubernetes-client/python#700
juliantaylor added a commit to juliantaylor/python-base that referenced this issue Jan 19, 2019
@juliantaylor
fix watching with a specified resource version
1e559d9 
The watch code reset the version to the last found in the
response.
When you first list existing objects and then start watching from that
resource version the existing versions are older than the version you
wanted and the watch starts from the wrong version after the first
restart.
This leads to for example already deleted objects ending in the stream
again.

Fix this by setting the minimum resource version to reset from to the
input resource version. As long as k8s returns all objects in order in
the watch this should work.
We cannot use the integer value of the resource version to order it as
one should be treat the value as opaque.

Closes kubernetes-client/python#700
juliantaylor added a commit to juliantaylor/python-base that referenced this issue Jan 22, 2019
@juliantaylor
fix watching with a specified resource version
9d521a1 
The watch code reset the version to the last found in the
response.
When you first list existing objects and then start watching from that
resource version the existing versions are older than the version you
wanted and the watch starts from the wrong version after the first
restart.
This leads to for example already deleted objects ending in the stream
again.

Fix this by setting the minimum resource version to reset from to the
input resource version. As long as k8s returns all objects in order in
the watch this should work.
We cannot use the integer value of the resource version to order it as
one should be treat the value as opaque.

Closes kubernetes-client/python#700
juliantaylor added a commit to juliantaylor/python-base that referenced this issue Jan 22, 2019
@juliantaylor
fix watching with a specified resource version
8a7bc69 
The watch code reset the version to the last found in the
response.
When you first list existing objects and then start watching from that
resource version the existing versions are older than the version you
wanted and the watch starts from the wrong version after the first
restart.
This leads to for example already deleted objects ending in the stream
again.

Fix this by setting the minimum resource version to reset from to the
input resource version. As long as k8s returns all objects in order in
the watch this should work.
We cannot use the integer value of the resource version to order it as
one should be treat the value as opaque.

Closes kubernetes-client/python#700
juliantaylor added a commit to juliantaylor/python-base that referenced this issue Jan 22, 2019
@juliantaylor
fix watching with a specified resource version
97174be 
The watch code reset the version to the last found in the
response.
When you first list existing objects and then start watching from that
resource version the existing versions are older than the version you
wanted and the watch starts from the wrong version after the first
restart.
This leads to for example already deleted objects ending in the stream
again.

Fix this by setting the minimum resource version to reset from to the
input resource version. As long as k8s returns all objects in order in
the watch this should work.
We cannot use the integer value of the resource version to order it as
one should be treat the value as opaque.

Closes kubernetes-client/python#700
juliantaylor added a commit to juliantaylor/python-base that referenced this issue Jan 23, 2019
@juliantaylor
fix watching with a specified resource version
82c710c 
The watch code reset the version to the last found in the
response.
When you first list existing objects and then start watching from that
resource version the existing versions are older than the version you
wanted and the watch starts from the wrong version after the first
restart.
This leads to for example already deleted objects ending in the stream
again.

Fix this by setting the minimum resource version to reset from to the
input resource version. As long as k8s returns all objects in order in
the watch this should work.
We cannot use the integer value of the resource version to order it as
one should be treat the value as opaque.

Closes kubernetes-client/python#700
juliantaylor added a commit to juliantaylor/python-base that referenced this issue Jan 23, 2019
@juliantaylor
fix watching with a specified resource version
3c30a30 
The watch code reset the version to the last found in the
response.
When you first list existing objects and then start watching from that
resource version the existing versions are older than the version you
wanted and the watch starts from the wrong version after the first
restart.
This leads to for example already deleted objects ending in the stream
again.

Fix this by setting the minimum resource version to reset from to the
input resource version. As long as k8s returns all objects in order in
the watch this should work.
We cannot use the integer value of the resource version to order it as
one should be treat the value as opaque.

Closes kubernetes-client/python#700
This was referenced Apr 25, 2019
Closed
Closed
dudleyhunt86 added a commit to dudleyhunt86/python-base-repository-build that referenced this issue Oct 7, 2022
@dudleyhunt86
fix watching with a specified resource version
56490d3 
The watch code reset the version to the last found in the
response.
When you first list existing objects and then start watching from that
resource version the existing versions are older than the version you
wanted and the watch starts from the wrong version after the first
restart.
This leads to for example already deleted objects ending in the stream
again.

Fix this by setting the minimum resource version to reset from to the
input resource version. As long as k8s returns all objects in order in
the watch this should work.
We cannot use the integer value of the resource version to order it as
one should be treat the value as opaque.

Closes kubernetes-client/python#700
bh717 pushed a commit to bh717/python-dapp that referenced this issue Apr 1, 2024
fix watching with a specified resource version
da7c6b2 
The watch code reset the version to the last found in the
response.
When you first list existing objects and then start watching from that
resource version the existing versions are older than the version you
wanted and the watch starts from the wrong version after the first
restart.
This leads to for example already deleted objects ending in the stream
again.

Fix this by setting the minimum resource version to reset from to the
input resource version. As long as k8s returns all objects in order in
the watch this should work.
We cannot use the integer value of the resource version to order it as
one should be treat the value as opaque.

Closes kubernetes-client/python#700
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@juliantaylor @max-rocket-internet