jiebi/CodeConvo huggingface dataset:
Change:
pp.allowPermit = false } <del> // NewPermitPlugin is the factory for permit plugin. func NewPermitPlugin(_ *runtime.Unknown, fh framework.FrameworkHandle) (framework.Plugin, error) { perPlugin.fh = fh return perPlugin, nil </del> <ins> // NewPermitPlugin returns a factory for permit plugin with specified PermitPlugin. func NewPermitPlugin(permitPlugin *PermitPlugin) framework.PluginFactory { return func(_ *runtime.Unknown, fh framework.FrameworkHandle) (framework.Plugin, error) { permitPlugin.fh = fh return permitPlugin, nil } </ins> } // TestPrefilterPlugin tests invocation of prefilter plugins.

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: pull-kubernetes-integration Which test(s) are failing: TestPreemptWithPermitPlugin Since when has it been failing: 13:30 PST, Sep 9, 2019 Testgrid link: Reason for failure: Need investigations. Anything else we need to know: /sig scheduling
Another flaky It happens at 2019-08-06 05:43:47 +0000 UTC
The above repeated for 30 seconds.
I checked the code and log again. I think the reason is as following: When scheduler preempted , it failed to delete the pod(same as the case for , there might be something wrong with etcd), so it could not schedule because had not been deleted successfully.
/assign Find the root cause now, will send a PR soon.
Thanks for your work! Not sure whether you are still investigating it, the flaky test is impacting many PRs now, so I send a PR for it now, sorry for it.
Change:
} glog.V(3).Infof("Removing %s/%s from '%s' with CNI '%s' plugin and runtime: %+v", namespace, name, config.Network.Name, config.Network.Type, rt) <del> if err := plugin.cniConfig.DelNetwork(config, rt); err != nil { </del> <ins> err = plugin.cniConfig.DelNetwork(config, rt) // The pod may not get deleted successfully at the first time. // Ignore "no such file or directory" error in case the network has already been deleted in previous attempts. if err != nil && !strings.Contains(err.Error(), "no such file or directory") { </ins> return fmt.Errorf("Error removing container from network: %v", err) } return nil

Discussion:
/kind bug What happened: During pod teardown, we sometimes see the following error-level kubelet logs: What you expected to happen: Clean pod shutdown, no error-level logs. How to reproduce it (as minimally and precisely as possible): We've got two kube crons that run every minute, across 12 regions in production -- so related pods daily -- and we see this about 3-12 times per day. Anything else we need to know?: Relevant kubelet log context of a cron pod that manifested this error: Controller manager for the pod: Scheduler for the pod: Cron yaml: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Bare metal OS (e.g. from /etc/os-release): 16.04.1 LTS (Xenial Xerus) Kernel (e.g. ): 4.4.0-89-generic -Ubuntu Install tools: N/A Others: N/A
/sig network
Same problem here. Every time I try to of my deploy, the old pod cannot be terminated successfully. below is output of
Have you checked the ns net files of those failed-to-deleted pods? /cc Could we just ignore these errors?
Sorry, yeah, that seems like a fair point to note -- the directories are in fact being deleted. Seems like it's either functionally succeeding yet generating error-level logs, or perhaps generating error-level logs and then succeeding on internal retry.
I prefer the later one. Perhaps kubelet does not kill the pod completely at the first time. Such error may occur during a retry.
So this is just an overly scary log message?
Yes, I think so. In the first attempt to delete the pod, the ns network file has already been deleted. But the pod does not get deleted successfully. Then "no such file or directory" will be raised in the second attempt.
Change:
(disk.ManagedDisk != nil && diskURI != "" && strings.EqualFold(*disk.ManagedDisk.ID, diskURI)) { // found the disk klog.V(2).Infof("azureDisk - detach disk: name %q uri %q", diskName, diskURI) <del> if strings.EqualFold(as.cloud.Environment.Name, "AZURESTACKCLOUD") { </del> <ins> if strings.EqualFold(as.cloud.Environment.Name, AzureStackCloudName) { </ins> disks = append(disks[:i], disks[i+1:]...) } else { disks[i].ToBeDetached = to.BoolPtr(true)

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : PR() already proves that old api-version on Azure stack works on global Azure too, we could support azure stack in azure cloud provider lib, and then make sure following components works in Azure stack: CSI drivers: azure disk, azure file CCM Since it's mainly api-version change, we could also add e2e tests against global Azure too. Why is this needed: /assign /priority important-soon /sig cloud-provider /area provider/azure
there is blocking issue here(also need azure stack supports latest data model struct): just making the change in interfaces and not go-sdk but facing this error, since we don't have a switch inside go-sdk, we only do switch in azure cloud provider lib,
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Change:
# This file creates a standard build environment for building cross # platform go binary for the architecture kubernetes cares about. <del> FROM golang:1.11.2 </del> <ins> FROM golang:1.11.3 </ins> ENV GOARM 7 ENV KUBE_DYNAMIC_CROSSPLATFORMS 

Discussion:
The go team has released 1.11.3 with three security fixes. From their e-mail announcement: We should kick off upgrades of both the kubernetes build system, and our CI, as soon as possible. Do you have an ETA for the rules_go bump that will contain 1.11.3 toolchain support? cc:
I'm preparing releases that use Go 1.11.3 by default. Those will be on the rules_go 0.14, 0.15, and 0.16 branches. I expect to tag them tonight as soon as they get through CI.
Fantastic! Thank you
rules_go 0.14.7, 0.15.9, and 0.16.4 are now tagged and ready to go.
related commits and issue:
Reopening to track other branches, as well as the CI bump
go1.11.3 and go1.10.6 introduced a regression, and so go1.11.4 and go1.10.7 were released Friday afternoon with a fix. We'll need to bump everything again on master, and should hold off on cherry-picks for now.
This looks fixed by Is there anything else that needs to be done as well?
Still need to merge for k8s 1.13.
Closing as all branches are now up to date.
Change:
if transformer == nil { value.RecordCacheMiss() <ins> requestInfo := getRequestInfoFromContext(ctx) </ins> uid := string(uuid.NewUUID()) <del> klog.V(6).InfoS("Decrypting content using envelope service", "uid", uid, "key", string(dataCtx.AuthenticatedData())) </del> <ins> klog.V(6).InfoS("decrypting content using envelope service", "uid", uid, "key", string(dataCtx.AuthenticatedData()), "group", requestInfo.APIGroup, "version", requestInfo.APIVersion, "resource", requestInfo.Resource, "subresource", requestInfo.Subresource, "verb", requestInfo.Verb, "namespace", requestInfo.Namespace, "name", requestInfo.Name) </ins> key, err := t.envelopeService.Decrypt(ctx, uid, &kmsservice.DecryptRequest{ Ciphertext:  encryptedObject.EncryptedDEK, KeyID:       encryptedObject.KeyID,

Discussion:
Add additional logging at level that associates UID with the metadata from the request. xref: /sig auth
/triage accepted
/milestone v1.26
Mind if I take a look at this? /assign
Hello I am wondering how's this coming along. Is there anything I can help with?
Sorry. I got a bit occupied with a different project.. Will have a PR opened for this for review tomorrow.. I am trying to find a way to inject the Verbs into log. But haven't found the right way to include that into the context.. Any suggestion on what can be done?
any suggestion on what is the best way to get the additional metadata for verbs into this log? Move that info across using ?
Hello , bug triage team here, just wanted to touch base with you for updates on this ticket. Thanks!
Thanks! This is being worked on and is still on track for .
There is a Pull request opened on this already as well. But Waiting on some clarification to see if that needs additional changes.
/reopen /assign /unassign
Reopened this issue. <detailsIn response to : /reopen /assign /unassign 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
/milestone v1.27
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Hi Bug Triage Team for v1.27 here o/ Just wanted to touch base with you for updates on this ticket. Thanks!
I am not working on this anymore Carlos. This was re-assigned
This is tracked for . I've linked the PR.
Change:
gvr("storage.k8s.io", "v1alpha1", "csistoragecapacities"): { Stub:             `{"metadata": {"name": "csc-12345-1"}, "storageClassName": "sc1"}`, ExpectedEtcdPath: "/registry/csistoragecapacities/" + namespace + "/csc-12345-1", <del> ExpectedGVK:      gvkP("storage.k8s.io", "v1beta1", "CSIStorageCapacity"), </del> <ins> ExpectedGVK:      gvkP("storage.k8s.io", "v1", "CSIStorageCapacity"), </ins> }, // --

Discussion:
The override in can be removed in Kubernetes v1.25 because then the oldest supported kube-apiserver for downgrades will be v1.24 which will understand the v1 format. Also need to adapt See and Code cleanup...
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
/assign
/sig storage
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale /lifecycle frozen
Change:
} wantModules := sets.NewString() loadModules := sets.NewString() <ins> linuxKernelHandler := NewLinuxKernelHandler() _, ipvsModules, _ := utilipvs.GetKernelVersionAndIPVSMods(linuxKernelHandler.executor) </ins> wantModules.Insert(ipvsModules...) loadModules.Insert(mods...) modules := wantModules.Difference(loadModules).UnsortedList()

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!--kube-proxy cannot use ipvs mode on Linux 4.19 due to a check for the module, which was changed to (). uses to check for : It should instead accept on Linux 4.19 or above. What happened: kube-proxy fell back from ipvs mode to iptables mode. What you expected to happen: kube-proxy using ipvs. How to reproduce it (as minimally and precisely as possible): Launch a cluster on an image using Linux 4.19 or above with kube-proxy using ipvs mode (see ). Environment: Kubernetes version (use ): All Kernel (e.g. ): 4.19 <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig network
/area ipvs /assign /cc
Okay, so should check {nfconntrackipv4 | nf_conntrack} and expect load at least one module?
I think so
Please just go ahead :)
Change:
// volumeConfigName is the configmap passed to bootstrapper and provisioner volumeConfigName = "local-volume-config" // provisioner image used for e2e tests <del> provisionerImageName = "quay.io/external_storage/local-volume-provisioner:v2.0.0" </del> <ins> provisionerImageName = "quay.io/external_storage/local-volume-provisioner:v2.1.0" </ins> // provisioner daemonSetName name daemonSetName = "local-volume-provisioner" // provisioner default mount point folder

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: We need to update local volume provisioner used in local PV e2e tests for k8s 1.10, by leveraging a new provisioner image (v2.1.0). Environment: Kubernetes version: v1.10
/sig storage /assign
should this block the 1.10 release in your opinion?
No not a blocker
Change:
// Config contains the configuration for a given Cache. type Config struct { // Maximum size of the history cached in memory. <del> // // DEPRECATED: Cache capacity is dynamic and this field is no longer used. </del> CacheCapacity int // An underlying storage.Interface.

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /cc /priority critical-urgent /milestone v1.19
/sig api-machinery
Suspect it has to do with cc /assign (for CI signal ownership)
Seems unlikely since multiple kind e2e tests passed on the PR itself
I was thinking that as well, but I don't see any other relevant changes
Actually, I take that back. Looks like the same failure was encountered as a flake on some of the PR runs. Looking at the test, it appears to assume the resource version of the kubernetes service will always be in the watch window, which is a bad assumption. I'd expect us to fix that assumption in the test, but also make sure we didn't unintentionally shrink the watch window for resources.
/assign
Note: this also appears to be breaking
Failure seems to be timeout related as well shows the runtime ~tripled after merged
revert open in can investigate test failure and timeouts and bring the change back in
I take it back, the test tolerates an expired error explicitly.
showed 17 of the 22 runs since merged took ~1 hour. The first run after the revert at returned to less than 30 minutes for the run. Will keep an eye on that to see if subsequent runs match.
- thanks a lot for looking into it. I don't think my PR changed anything that anyone should rely on. I will take a deeper look into it and try to fix that (hopefully later this week).
contains the explanation and describes the bug (in fact this bug still exists in the codebase, that PR was only increasing the probability of this particular test hitting it)
Change:
for i in "$@"; do # fsid=0: needed for NFSv4 echo "$i *(rw,fsid=0,insecure,no_root_squash)" >> /etc/exports <ins> # move index.html to here /bin/cp /tmp/index.html $i/ chmod 644 $i/index.html </ins> echo "Serving $i" done <ins> # start rpcbind if it is not started yet /usr/sbin/rpcinfo 127.0.0.1 > /dev/null; s=$? if [ $s -ne 0 ]; then echo "Starting rpcbind" /usr/sbin/rpcbind -w fi </ins> mount -t nfsd nfds /proc/fs/nfsd <del> # -N 2 -N 3: disable NFSv2+3 # -V 4.x: enable NFSv4 /usr/sbin/rpc.mountd -N 2 -N 3 -V 4 -V 4.1 </del> <ins> # -N 4.x: disable NFSv4 # -V 3: enable NFSv3 /usr/sbin/rpc.mountd -N 2 -V 3 -N 4 -N 4.1 </ins> /usr/sbin/exportfs -r # -G 10 to reduce grace time to 10 seconds (the lowest allowed) <del> /usr/sbin/rpc.nfsd -G 10 -N 2 -N 3 -V 4 -V 4.1 2 </del> <ins> /usr/sbin/rpc.nfsd -G 10 -N 2 -V 3 -N 4 -N 4.1 2 /usr/sbin/rpc.statd --no-notify </ins> echo "NFS started" }

Discussion:
GCE minion VM OS version is The nfs server image and hits with the following dump stack
Image version now exists!
thanks!
Change:
}, Spec: api.ReplicationControllerSpec{ Replicas: 3, <del> Selector: podLabels, </del> <ins> Selector: rcPodLabels, </ins> Template: &api.PodTemplateSpec{ ObjectMeta: api.ObjectMeta{ <del> Labels: podLabels, </del> <ins> Labels: rcPodLabels, </ins> }, Spec: api.PodSpec{ Containers: []api.Container{

Discussion:
cc
Thanks for flagging it! Its not flaky, it is broken as we did not enable deployments for that test suite. Sent to fix that.
Change:
// Defaults to 7080 if not set. ReadOnlyPort int // The port on PublicAddress where a read-write server will be installed. <del> // Defaults to 443 if not set. </del> <ins> // Defaults to 6443 if not set. </ins> ReadWritePort int // If nil, the first result from net.InterfaceAddrs will be used.

Discussion:
Trying to hit the read-write kubernetes service from inside a cluster does not work. tailing the kube-proxy logs shows: And sure enough, kube-apiserver is not listening on the NIC on that port. 8080 is only for the localhost HTTP communications between master components (and nginx redirect after HTTPS termination). The "kubernetes" master service needs to get created with Port set to 443.
+1
This needs to be port 6443 the auth_port On Feb 6, 2015 10:14 AM, "Paulo Pires" wrote:
The code says 8443, but then a flag changes to 6443. Will fix. , Eric Tune wrote:
Holy macaroni this is a mess. , Tim Hockin wrote:
Change:
pluralize("type", "types", len(badTypes)), joinQuote(badTypes.List()), )) <del> if setUser { badData = append(badData, "user may not be set") } if setRole { badData = append(badData, "role may not be set") } </del> <ins> } if setUser { badData = append(badData, "user may not be set") } if setRole { badData = append(badData, "role may not be set") </ins> } return CheckResult{

Discussion:
If I configure the namespace to enforce PSS checks, the return message ends abruptly for : The resource manifest that can be used to reproduce:
/transfer kubernetes
/sig auth /cc
Thanks for the report, fix in
Thanks for the quick fix !
Change:
} }) <del> ginkgo.It("should prevent Ingress creation if more than 1 IngressClass marked as default", func() { </del> <ins> ginkgo.It("should prevent Ingress creation if more than 1 IngressClass marked as default [Serial]", func() { </ins> ingressClass1, err := createIngressClass(cs, "ingressclass1", true, f.UniqueName) framework.ExpectNoError(err) defer deleteIngressClass(cs, ingressClass1.Name)

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: gce-master-scale-correctness Which test(s) are flaking: [sig-network] Ingress API should support creating Ingress API operations [Conformance] Testgrid link: https://k8s- Reason for failure: Anything else we need to know: /kind flake /sig scalability /sig network /cc
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
this is caused by the issue described in a different test is creating a default ingressclass, which breaks creation of ingress objects if there was already a default ingressclass set up in the cluster /assign
this should resolve the issue:
I take it back, looks like the conformance test is also creating default ingressclass objects... it should not fix in
Change:
expectedLB:          expectedSLb5, expectedError:       nil, }, <ins> { desc:            "reconcileLoadBalancer shall reconcile UDP services", loadBalancerSku: "basic", service:         service6, existingLB:      lb6, wantLb:          true, expectedLB:      expectedLB6, expectedError:   nil, }, { desc:            "reconcileLoadBalancer shall reconcile probes for local traffic policy UDP services", loadBalancerSku: "basic", service:         service7, existingLB:      lb7, wantLb:          true, expectedLB:      expectedLB7, expectedError:   nil, }, </ins> } for i, test := range testCases {

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: Refer , health probes are not associated for UDP services on Azure, hence source IPs are not preserved for UDP services on Azure. What you expected to happen: When is set to for UDP services, source IPs should be preserved and the health probe should be associated with UDP load balancer rule. Per the , the health probe only supports TCP, HTTP and HTTPS. UDP is not supported as the probing protocol, hence we can’t enable the health probes for UDP services. However, when the externalTrafficPolicy is Local, Kubernetes would open an HTTP endpoint for UDP services, hence it’s actually supported on Azure. So, should associate the probes on externalTrafficPolicy=Local cases. How to reproduce it (as minimally and precisely as possible): Create a UDP service with : Then check the source IPs. Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /sig cloud-provider /area provider/azure
Change:
// 	useHyperKubeImage: false // 	clusterName: "example-cluster" // 	--- <del> // 	apiVersion: kubelet.config.k8s.io/v1beta2 </del> <ins> // 	apiVersion: kubelet.config.k8s.io/v1beta1 </ins> // 	kind: KubeletConfiguration // 	# kubelet specific options here // 	---

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: references and a broken link to this (because it doesn't exist!) I'm guessing this was a bad find and replace when copying kubeadm's own v1beta1 to v1beta2 What you expected to happen: accurate documentation How to reproduce it (as minimally and precisely as possible): read the docs Anything else we need to know?: this template has a lot of fields :^) Environment: anything Kubernetes version (use ): n/a Cloud provider or hardware configuration: n/a OS (e.g: ): n/a Kernel (e.g. ): n/a Install tools: kubeadm Network plugin and version (if this is a network-related bug): n/a Others: n/a /assign /sig cluster-lifecycle
Change:
continue } <ins> nodeAffinityValid := true </ins> if node != nil { // Scheduler path, check that the PV NodeAffinity // is satisfied by the node err := volumeutil.CheckNodeAffinity(volume, node.Labels) if err != nil { <del> continue </del> <ins> nodeAffinityValid = false </ins> } }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /assign What happened: Volume got bound to PV on node "kubernetes-minion-group-82c8" When the pod went back through scheduling, the predicate returned success for other nodes even though we should have updated the PV cache to point to the PVC: I think in , instead of continuing if the node affinity doesn't match, it should fail if the PV is prebound.
This causes two issues: On the second pass, the scheduler may choose a different node. Then in Assume/Bind volumes, we'll also prebind a second set of PVs. If the scheduler chose a different node on the second pass, and the PVCs became fully bound in between the predicates and assume volumes, then assume volumes will return success and the pod will get scheduled to the wrong node.