Open p0lyn0mial opened 2 years ago
@p0lyn0mial: There are no sig labels on this issue. Please add an appropriate label by using one of the following commands:
/sig <group-name>
/wg <group-name>
/committee <group-name>
Please see the group list for a listing of the SIGs, working groups, and committees available.
@p0lyn0mial: 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.
/cc @neolit123 @aojea
@neolit123: Something went wrong or the destination repo kubernetes/khbeadm does not exist.
/transfer kubeadm
/kind feature /remove-kind bug
FWIW - I'm copying my comment from the original issue to give a context:
The feature was graduated to GA (non-experiment) in etcd 3.5 without any code changes so I think we're fine.
We already enabled that for all GCE tests long time ago: https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/config-test.sh#L578 https://github.com/kubernetes/kubernetes/blob/8415ae647d2c433c89910a0e677094e3a20ffb2b/cluster/gce/gci/configure-helper.sh#L1851
We're heavily relying on this setting for efficient watch resumption KEP: https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/1904-efficient-watch-resumption/README.md#proposal [which is already GA]
FWIW - we enabled that setting in GKE (together with etcd 3.4) quite some time ago
So I don't consider this an experimental feature. The problem is that there weren't any etcd release after 3.4 for ~2 years, and 3.5 that was released last year is still not fully production ready (not qualified enough).
So I personally think that we are now ready to just enable it in kind for everyone, but I'm not kind maintainer so it needs to be decided by kind maintainers.
Link the etcd issue for graduating this flag: https://github.com/etcd-io/etcd/issues/13779
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
This is in the plan of etcd v3.6. Move it to v1.29 then.
/sig etcd
IMO
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
What happened?
The
experimental-watch-progress-notify-interval
flag specifies an interval at which etcd sends data to the kube-api server.It is used by the
WatchBookmark
feature (kube-apiserver
) which is GA since 1.17. It will also be used by a newWatchList
feature (kube-apiserver's
) which is Alpha since 1.25Given the above, a default installation must pass the flag required by the
kube-apiserver
toetcd
. Otherwise, some features will not work.Note that the feature was graduated to GA (non-experiment) in etcd 3.5 without any code changes. Once kubernetes switches to etcd in 3.5 the flag name will have to be changed.
What did you expect to happen?
The
experimental-watch-progress-notify-interval
flag is specified on etcd binary.How can we reproduce it (as minimally and precisely as possible)?
atm the kubeadm does not specify the flag. So simply installing a cluster is enough to reproduce the issue.
Anything else we need to know?
No response
Kubernetes version
Cloud provider
OS version
Install tools
Container runtime (CRI) and version (if applicable)
Related plugins (CNI, CSI, ...) and versions (if applicable)
‐---------
edit neolit123
1.25
next