jiebi/CodeConvo huggingface dataset:
Change:
// buildHandlerChain wraps the given handler with the standard filters. func buildHandlerChain(handler http.Handler, authn authenticator.Request, authz authorizer.Authorizer) http.Handler { requestInfoResolver := &apirequest.RequestInfoFactory{} <del> failedHandler := genericapifilters.Unauthorized(legacyscheme.Codecs) </del> <ins> failedHandler := genericapifilters.Unauthorized(scheme.Codecs) </ins> <del> handler = genericapifilters.WithAuthorization(handler, authz, legacyscheme.Codecs) </del> <ins> handler = genericapifilters.WithAuthorization(handler, authz, scheme.Codecs) </ins> handler = genericapifilters.WithAuthentication(handler, authn, failedHandler, nil) handler = genericapifilters.WithRequestInfo(handler, requestInfoResolver) handler = genericapifilters.WithCacheControl(handler)

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Kube-Scheduler exposes metrics in a secure manner (TLS and authentication required) on port by default. If one does not authenticate itself, the error message displayed is: What you expected to happen: Kube-Scheduler should emit a clear and understandable error message if authentication fails. Kube-Controller-Manager does that the following way: How to reproduce it (as minimally and precisely as possible): up a Kubernetes Cluster to access the exposed metrics endpoint (https://metrics-server:/metrics) without authentication Anything else we need to know?: xref: Environment: Kubernetes version (use ): 1.18.6 Cloud provider or hardware configuration: Bare metal OS (e.g: ): Debian GNU/Linux 10 (buster) Kernel (e.g. ): 4.19.0-9-amd64 Install tools: Kubeadm (Kube-Scheduler )
/sig scheduling instrumentation
If ok, I can try this fix /assign
/assign
Change:
ETCD_QUORUM_READ: $(yaml-quote ${ETCD_QUORUM_READ}) EOF fi <ins> if [ -n "${CLUSTER_SIGNING_DURATION:-}" ]; then cat >>$file <<EOF CLUSTER_SIGNING_DURATION: $(yaml-quote ${CLUSTER_SIGNING_DURATION}) EOF fi </ins> else # Node-only env vars.

Discussion:
/kind e2e-test-failure GCE serial and GCI GCE serial started failing last evening https://k8s- https://k8s-
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/testing: Issue will be escalated to these SIGs if needed. priority/critical-urgent: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
https://k8s- is still green, I would suspect something ~last Friday afternoon gets merged
Here is what I found, after a while, the node lost their authorization to connect to API server. I believe this has the same root cause as
I am going to revert offending pr () to see if it helps. EDIT: Looks like is in the process of reverting it:

ref Test is failing on GCE slow and GCI GCE slow: https://k8s- https://k8s- Example failure https://k8s-
The test nodes appear to lose their authorization for accessing resources about 26m into the test. One of many "Unauthorized" errors starting at
, does this ring any bells ?
The certificates are all expiring:
I believe this is the regression introduced cc/ Can you guys take a look?
[MILESTONENOTIFIER] Milestone Labels Incomplete Action required: This issue requires label changes. kind: Must specify exactly one of [, , ]. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
thanks. I'll open a PR to revert that.
Revert here
Change:
return nil } <del> func (w *watchCache) getResourceVersion() uint64 { </del> <ins> func (w *watchCache) getListResourceVersion() uint64 { </ins> w.RLock() defer w.RUnlock() <del> return w.resourceVersion </del> <ins> return w.listResourceVersion </ins> } func (w *watchCache) currentCapacity() int {

Discussion:
sig-release-master-blocking ci-kubernetes-unit 05/30/2024 19:25 IST Prow Logs: Triage: No response /sig
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig storage
/sig api-machinery
/cc This started last week, but it seems to be fairly rare, so might be a consequence of something a bit earlier. The value of "2" suggests that it's happening on the first event, and my brain goes towards: - will you be able to take a look at it?
sure, I will have a look. /assign
We chatted with about that offline and it seems like a real correctness issue. Regression indeed introduced by We have a race with setting RV in watchcache and incoming events. The current explanation is: initializeds with RV=N event comes with RV=N+1 [but wasn't yet dispatched] polling introduced in that PR catches RV=N+1 then the event (with RV=N+1) is received
So it is a release blocker, then? (Upcoming alpha 1 release cut scheduled for tomorrow)
I don't know what the release policy is but we might have a potential fix for this issue.
This is a real correctness bug introduced 2 weeks ago. I'm not sure what's our policy is for alpha releases, but it sounds like a potential blocker to me.
The fix for it is already approved.
Change:
func (c *cacheWatcher) add(event *watchCacheEvent, budget *timeBudget) { // Try to send the event immediately, without blocking. select { <del> case c.input <- event: </del> <ins> case c.input <- *event: </ins> return default: }

Discussion:
Our scalability tests started failing on Thu last week: https://k8s- [250 run passed, 251 failed and since then everything failed] I started looking into it and it seems that something happened to how we are handling watches (i.e. I'm seeing a huge number of watches failing with "err too old" errors (which I didn't see before).
As an example in run 258 of kubemark-scale, I'm seeing this log in the test (after 5 minutes of running test); This is extremely strange and unexpected. I looked into apiserver logs, and there is expected number of POST and PUT operations on pods (and no DELETE and PATCH operations until then). Until then, there were alltogethere ~60.000 operations on pods. However, in 5000-node cluster, the size of watchcache of pods is supposed to be 250.000, which means that at that moment we should have all the history from the beginning in watch cache. And still we are observing those errors. Something must have changed around that recently...
As an example, logs from apiserver from a given node: This means something is really wrong: the first watch started at 45, then after it finished, we tried starting watch from rv= and it failed with "rv too old" the list, returned rv= from which we started the next watch. If the watch cache size for pods would be 250.000 (50*cluster size), there there is no way that with current rv=, the rv= would be outside history window...
I had a hypothesis that it might be the problem of breaking watch to etcd. But in that case there should be a warning "Terminating all watchers" log in apiserver, and there is no such log. It also seems that the size of cache is being set correctly...
So I tried running large kubemark locally and it seems that the problem is that the size of cache is too small. I few more logs, and here is what I'm seeing: So it seems that we are correctly initializing cachesizes, but then watch cache capacity is 100 (which explains why we are seeing all those "rv too old" errors. I will try to debug why the capacity is so small.
OK - I found it. contains the fix.
Change:
return err } <del> klog.V(4).Infof("azureMount: mount options(%q) source:%q, target:%q, fstype:%q, begin to mount", </del> <ins> klog.V(4).Infof("mount options(%q) source:%q, target:%q, fstype:%q, begin to mount", </ins> options, source, target, fstype) <del> bindSource := "" </del> <ins> bindSource := source </ins> // tell it's going to mount azure disk or azure file according to options if bind, _, _ := isBind(options); bind {

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: azure file remount on Windows in same node would fail What you expected to happen: If user delete a pod with azure file mount in deployment and it would probably schedule a pod on same node, azure file mount will fail since command would fail if file share is already mounted on the node: It's related to bug: Error logs would be like following: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.9-v1.12, master Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /assign
/sig windows
/sig azure
/milestone v1.14 cc This may be good to backport to 1.12 or 1.13 too if customers are using those versions.
Change:
} } <del> return field.ErrorList{} </del> <ins> return allErrs </ins> } // Validate container resource name

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: In some validation functions, such as , , value returned may be wrong. When return some errors and , we may just return , that is not expected What you expected to happen: return correctly
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
/assign
Can you clarify "wrong"?
For example in will add and to field of ResourceQuotaSpec. Before , these two resources are not to standard resource sets, will return error since they are not fully-qualified neither. But will not return any error since the two resources are to standard quota resource name sets. The result above is not expected . Error happened in , we need to return it instead of returning when we ran
Change:
Example: versionExample, Run: func(cmd *cobra.Command, args []string) { cmdutil.CheckErr(o.Complete(f, cmd)) <del> cmdutil.CheckErr(o.Validate()) </del> <ins> cmdutil.CheckErr(o.Validate(args)) </ins> cmdutil.CheckErr(o.Run()) }, }

Discussion:
ran instead of and got no error and then though that was the right version kubectl should fail for unexpected extra arguments
/sig cli
/assign
/triage accepted
Change:
ErrNodeUnschedulable = NewPredicateFailureError("NodeUnschedulable", "node(s) were unschedulable") // ErrNodeUnknownCondition is used for NodeUnknownCondition predicate error. ErrNodeUnknownCondition = NewPredicateFailureError("NodeUnknownCondition", "node(s) had unknown conditions") <del> // ErrTopologySpreadConstraintsNotMatch is used for EvenPodsSpread predicate error. ErrTopologySpreadConstraintsNotMatch = NewPredicateFailureError("EvenPodsSpreadNotMatch", "node(s) didn't match pod topology spread constraints") </del> // ErrFakePredicate is used for test only. The fake predicates returning false also returns error // as ErrFakePredicate. ErrFakePredicate = NewPredicateFailureError("FakePredicateError", "Nodes failed the fake predicate")

Discussion:
Part of /priority important-soon See example /sig scheduling /kind cleanup
/help
/assign
/remove-help
Change:
RUN echo CACHEBUST>/dev/null && clean-install  iptables  <ins> e2fsprogs  </ins> ebtables  ethtool  ca-certificates 

Discussion:
/kind bug What happened: When a cluster is provisioned using a containerised kubelet using the following images: Pods with PVCs are not created because kubelet cannot mount the disks. If you look at events, you can see that it's missing some binaries: This executable is . This problem can be resolved by mounting paths from the host into the rkt container, specifically and . Is this expected? mentioned in , that mounting operations are moving out from the main process into containers. Is this part of that effort? This caught me quite unexpected, and I didn't find any docs or changelog entries which indicated additional host mounts were necessary. If it's deliberate, I can close this until we perhaps document the breaking change. Is there a good place where we can document this? If it's not, I'll leave this open as a tracking issue. What you expected to happen: The hyperkube image to work without lots of host mounts. How to reproduce it (as minimally and precisely as possible): Run kubelet with rkt in one of the above listed images (see CoreOS' ). Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OpenStack OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: tectonic-installer
/sig storage /sig node
Seems the base hyperkube image was changed: done in /cc
The pkg/util/mount/mount_linux source defaults to ext4 if a fstype is not selected. It makes sense to restore the e2fsprogs package within the hyperkube image.
cc cc cc This seems like something that should be in the 1.8 milestone. Can someone who owns the hyperkube image comment on that?
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node sig/storage: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
Containerization of mount is not going to happen until 1.9 at the earliest.

So if hyperkube is broken, it should be fixed before ship.
"modprobe" also went missing in 1.8 hyperkube images... Both kubelet and kube-proxy need it.
Are you noticing any buggy behaviour on those components without it? Would you mind creating an issue and/or PR to restore that dep
Done: And done: :)
Change:
}, }, { <del> name: "existing pods with mis-matched namespace doesn't count", </del> <ins> name: "existing pods in a different namespace do not count", </ins> pod: st.MakePod().Name("p").Label("foo", "").SpreadConstraint( 1, "zone", hardSpread, st.MakeLabelSelector().Exists("foo").Obj(), ).Obj(),

Discussion:
How to reproduce it (as minimally and precisely as possible): pre-requisites: a multi-az cluster, a deployment with 1 pod in each az. a with and . the node(s) in 1 az. the deployment's pod(s) from the cordoned az. What happened: A new pod was created and scheduled in a form that What you expected to happen: I expected that a new pod will be created and be "stuck" in status as it shouldn't have nowhere be scheduled. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g: ):Kernel (e.g. ): 4.19.84-coreos Others: I created a with how I reproduce the bug
/sig scheduling
cc/
Thanks for raising this issue. I feel like it's a general timing issue - when you delete a Pod, that Pod may still exist for a very short time (in graceful deletion period), and at the same time, the controller backfills a Pod for it. So when scheduling tries to schedule the backfill Pod, it may read the cluster as: [1, 1, 1(deleting)]. To confirm this, can you try deleting the Pod using , and see if the problem goes away?
Yes sure I will try that. It sounds reasonable, thats why in the first demonstration I deleted all the pods and waited for all of them to completely disappear. Nevertheless, this is still something that I believe needs to be fixed. The pod's evaluation should take in consideration pods that are in status and don't count them as pods.
I do believe we exclude the Pods. (if not, it should be a serious regression). What concerns me is that at that moment, scheduler may treats that (deleting) Pod as running in its cache. I will try to debug into this.
Yep, this time the new pod was in status until I uncordoned the relevant nodes.
Change:
UnavailableReplicas: 0, }, <del> msg:  "Waiting for rollout to finish: 0 out of 1 new replicas have been updated...n", </del> <ins> msg:  "Waiting for deployment "foo" rollout to finish: 0 out of 1 new replicas have been updated...n", </ins> done: false, }, {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: In our CI, we run multiple times in parallel when we update multiple deployments. This lets us see the status of all deployments as they run. When a deployment succeeds, the final message tells us the name of the deployment. However, the intermediate "Waiting for rollout to finish" messages do not say the name of the deployment. This means that in order to look at multiple rollouts in parallel, we need to manually pipe through another command to prefix it with the rollout name. What you expected to happen: Each line to mention the rollout name. How to reproduce it (as minimally and precisely as possible): Update any deployment, run , note that intermediate status names don't contain the deployment name. Anything else we need to know?: Arguably another fix would be to allow you to pass multiple rollouts to and have kubectl handle polling multiple deployments in parallel. Environment: This is still true on master by code inspection.
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
} func prepareSnapshotDataSourceForProvisioning( <del> node e2epod.NodeSelection, </del> <ins> f *framework.Framework, config volume.TestConfig, </ins> client clientset.Interface, dynamicClient dynamic.Interface, initClaim *v1.PersistentVolumeClaim, class *storagev1.StorageClass, snapshotClass *unstructured.Unstructured, <ins> mode v1.PersistentVolumeMode, injectContent string, </ins> ) (*v1.TypedLocalObjectReference, func()) { var err error if class != nil {

Discussion:
What happened: https://k8s- These tests failed consistently: Anything else we need to know?: Volume snapshot tests need to be reworked to use / helper functions that support block volume mode. In addition, csi-driver-host-path fails when restoring block volume snapshots. /assign /sig storage
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: https://k8s- Anything else we need to know?: Volume snapshot tests need to be reworked to use / helper functions that support block volume mode. In addition, csi-driver-host-path fails when restoring block volume snapshots. /sig stroage Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
hostpath driver fix:
E2e test fix: (needs hostpath driver release first).
Change:
"crypto/x509" "encoding/json" "fmt" <del> "io" </del> "io/ioutil" "net" "net/http" "net/http/httptest" "net/http/httptrace" <del> "os" </del> "reflect" "strings" "sync"

Discussion:
/sig api-machinery /kind bug /priority important-soon
It seems something is racing writhing the logs ? cc:
/cc /triage accepted
Failed with this: pull-kubernetes-unit
this looks like a test-only race where the test overwriting the global os.Stderr in order to capture error output races with an async attempt to log to it from another test in the same package
which still needs to be fixed
It seems to me that this bug can not be fixed with as it is, namely used without a logger object or even a . The smallest tweak that occurs to me would be to add an option to to add an output destination, and later remove that addition. Thus, a test could add logging to its own buffer for the duration of running the code under test.
This may be similar to . How can I reproduce this issue?
Change:
force := false timeout := time.Duration(0) <ins> wait := false </ins> filenames := []string{} recursive := false

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig CLI What happened: Running leads to nil pointer dereference: What you expected to happen: is expected to run delete with wait in that case How to reproduce it (as minimally and precisely as possible): (with any valid resource yaml) Anything else we need to know?: Discovered in when accidentally enabled wait for deletion from other commands than and saw failing integration tests in https://k8s- Environment: Kubernetes version (use ): latest master Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
This bug was introduced in : is set in that requires to be non-nil flag is being set in is normally being set in method which is not invoked in . a result, the invocation of resource finder leads to nil pointer dereference (see stack trace in the description).
/cc
Change:
func init() { api.Scheme.AddDefaultingFuncs( <ins> func(obj *ReplicationController) { var labels map[string]string if obj.Spec.Template != nil { labels = obj.Spec.Template.Labels } // TODO: support templates defined elsewhere when we support them in the API if labels != nil { if len(obj.Spec.Selector) == 0 { obj.Spec.Selector = labels } if len(obj.Labels) == 0 { obj.Labels = labels } } }, </ins> func(obj *Volume) { if util.AllPtrFieldsNil(&obj.VolumeSource) { obj.VolumeSource = VolumeSource{

Discussion:
It doesn't make sense to define pod template with a set of labels that is strict subset of replicaSelector (or at least I can't find an use-case). For that reason I think that the labels in pod template part of replication controller should be optional and user should care about them only if he wants to define a superset of what replicaSelector already defines.
I've heard the same comments from a client. I think that it'd be more intuitive if we always specify pod labels in the template (so that we can copy&paste pod definition), and replicaSelector is optional (by default pod labels).
It would be reasonable for the selector to be a subset. I'm fine with intelligent defaulting but we need to be careful not to conflate the 2 concepts, which I think would increase the amount of confusion.
Setting RC selector from pod template labels SGTM. Any concerns It wouldn't have to work with separate templates, though it would be desirable if it did. It would be nice if we could add preconditions based on other objects (resource version of pod template in this case) to etcd transactions.
I think we agreed in another issue that defaulting the selector from the pod template labels is reasonable. No argument from me. One problem with pod templates is that we lose the strict relationship between selector and template, so if you change the template the RC needs to behave intelligently (I refuse to create more pods because the template selector doesn't match mine, etc)
We should do this, and we should default replicas to 1. We could also consider defaulting replication controller labels from pod template labels. That way, essentially the only thing that would need to be specified for a singleton RC would be the pod template.
I don't think we can default replicas to 1, since we can't tell the difference between an explicit zero and a default zero, and I think there are lots of reasonable cases where you want to set replicas == 0 on create. (esp. in the context of socket activation)
Responded on the PR: We can distinguish default from 0 if we make it a pointer.