jiebi/CodeConvo huggingface dataset:
Change:
# apply --prune on bar.yaml that has bar/test kubectl apply --prune -l pruneGroup=true -f hack/testdata/CRD/bar.yaml "${kube_flags[@]}" --prune-whitelist=company.com/v1/Foo --prune-whitelist=company.com/v1/Bar # check right crds exist <del> kube::test::get_object_assert foos "{{range.items}}{{$id_field}}:{{end}}" '' </del> <ins> kube::test::wait_object_assert foos "{{range.items}}{{$id_field}}:{{end}}" '' </ins> kube::test::get_object_assert bars "{{range.items}}{{$id_field}}:{{end}}" 'test:' # Delete the resource

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: pull-kubernetes-integration Which test(s) are flaking: runcrdtests Testgrid link: Reason for failure: I am unfamiliar with this test, but the log suggests that the test did not properly wait for required resources to be available.
/sig cli api-machinery
/assign
the foo CR "test" with a Foreground delete, and it to be gone. However in those the foo CR "test" was still visible. I think this is caused by test running fast, and the garbage collector hasn't removed the object from REST API yet. I will send a fix to let the test to retry
Created . For the record the test failed 13 times since 2/14:
/reopen I will verify the test results in the next few days.
Reopened this issue. <detailsIn response to : /reopen 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
The test is green. /close
Closing this issue. <detailsIn response to : The test is green. 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:
return nil } <del> // ServiceAntiAffinity contains information to calculate service anti-affinity priority. type ServiceAntiAffinity struct { podLister     schedulerlisters.PodLister serviceLister corelisters.ServiceLister labels        []string } // NewServiceAntiAffinityPriority creates a ServiceAntiAffinity. func NewServiceAntiAffinityPriority(podLister schedulerlisters.PodLister, serviceLister corelisters.ServiceLister, labels []string) (PriorityMapFunction, PriorityReduceFunction) { antiAffinity := &ServiceAntiAffinity{ podLister:     podLister, serviceLister: serviceLister, labels:        labels, } return antiAffinity.CalculateAntiAffinityPriorityMap, antiAffinity.CalculateAntiAffinityPriorityReduce } </del> // countMatchingPods counts pods based on namespace and matching all selectors func countMatchingPods(namespace string, selector labels.Selector, nodeInfo *schedulernodeinfo.NodeInfo) int { if nodeInfo.Pods() == nil || len(nodeInfo.Pods()) == 0 || selector.Empty() {

Discussion:
/sig scheduling /priority important-soon See as an example. /assign
/unassign /help
/assign
/remove-help
Change:
}, numErrs: 1, }, <ins> { name: "LoadBalancer type cannot have None ClusterIP", tweakSvc: func(s *api.Service) { s.Spec.ClusterIP = "None" s.Spec.Type = api.ServiceTypeLoadBalancer }, numErrs: 1, }, </ins> } for _, tc := range testCases {

Discussion:
Create the following svc: It should fail.
I will try to take a shot at it.
Awesome! Make sure to handle updates in all directions. Historically it is the thing we forget. , Maciej Kwiek wrote:
do you have any examples of this behaviour breaking something? It would help with justifying my PR in code review process :). I know it makes sense to fix this issue, but an example would be nice.
I had a user report thatthey didn't know what was happening - the API should have rejected it with a message that you can't have headless services with load balancers. , Maciej Kwiek wrote:
please what are really use cases where we can use k8s headless service, DB, Proxies .. ?
Change:
import ( "context" <ins> "sync" </ins> "testing" "time" )

Discussion:
a test that is flaking at a ~3% failure rate with : Originally posted by in /sig api-machinery /assign /cc /kind failing-test
/assign

all the failures I've seen weren't failures, but rather timeouts. I wasn't able to reproduce it either by running the test itself, but I know what the potential failure is here: the and goroutines are somehow finishing the last one that is called is 1+ of goroutine is starting after that In this case the last will never finish. The fix is in
not sure if it's related, but TestGetCurrentResourceVersionFromStorage in the same package started flaking at the same time: looks like the fix in won't address that one
that's a different thing for sure. - can you please take a look at it - it's a newly test from yesterday
Spinned of for the other issue mentioned by Jordan.
Change:
if err != nil { t.Fatalf("Should succeed when a valid config is provided: %s", err) } <del> klog.Flush() klog.InitFlags(nil) </del> flag.Set("logtostderr", "false") flag.Set("alsologtostderr", "false") flag.Set("v", "9")

Discussion:
/kind failing-test /kind flake /sig cloud-provider /area provider/vmware Flaked on Is this the same issue as ?
/assign There seems to be a data-race here.
There's a finalizer that trips up the test case. TestSecretUpdated set flag and read from so when the logout read and the test is write the ,they lead to I came up with a mutex where the klog library reads Or a lock on the kubernetes vsphere logout function. Any better suggestions? /cc
the use of a runtime finalizer is suspect... that's the only use in our codebase and makes unit testing really hard. also, the use of the global logger in TestSecretUpdated is suspect... the code under test should be structured to allow testing the results without plumbing through the global logger
/cc
/assign
/triage accepted
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]:
Since the test is still failed, pick up at /cc
Change:
}, &api.Pod{}, 0, <del> controllerFramework.ResourceEventHandlerFuncs{ </del> <ins> controllerframework.ResourceEventHandlerFuncs{ </ins> AddFunc: func(obj interface{}) { p, ok := obj.(*api.Pod) Expect(ok).To(Equal(true))

Discussion:
Forked from pointed out that all package names should be lower case, no under_scores or mixedCaps. The same rule applies to renaming imported packages. () generated a list of mixedCaps package names in our codebase: I will upload a PR later to rename kubeletTypes to kubetypes, and the rest is up for grabs.
sorry i have not saw this issue as i open a similar one(), do you mind i participate in this issue? i would happy to do some work for this. best regards.
of course, fixes are welcome. Thanks for picking up on this! We'll try to expedite the review and merge process of such PRs to avoid a lot of churns, but chances are that some rebases are needed :)
ok, i will send some fix sonner, and tag you for review. thanks again.
Not done:
Change:
} for _, tc := range tests { <del> fn := func(rule string) *apiextensions.CustomResourceDefinition { </del> <ins> fn := func(rule, messageExpression string) *apiextensions.CustomResourceDefinition { </ins> validationRules := []apiextensions.ValidationRule{ { <del> Rule: rule, </del> <ins> Rule:              rule, MessageExpression: messageExpression, </ins> }, } return &apiextensions.CustomResourceDefinition{

Discussion:
Noticed a copy & paste issue when reading through the CEL code. Basically here: This should be instead of: The impact of this issue should be that messageExpressions are always evaluated with the CEL environment of the compatibility version. But stored (i.e. pre-existing) messageExpressions should be evaluated with a CEL environment with the "max" version instead. For users of Kubernetes this means that messageExpressions deployed with one minor version of Kubernetes might not work anymore if they rollback e.g. by one minor version. messageExpressions should be treated the same way as rules in that regard. Deploy Kubernetes 1.30 Deploy CRD that uses messageExpression that is using Sets (which became available with Kubernetes 1.30 that is using compatibilty version 1.29) Rollback to Kubernetes 1.29 Update something in the CRD =CRD update will fail because messageExpression is evaluated with the wrong CEL environment (it should still work) No response <detailsAt least on Kubernetes main, but I would assume this isuse is there since CEL was implemented </details<details</details
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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
cc Will open a PR in a bit
Change:
return antiAffinity.CalculateAntiAffinityPriority } <ins> // Classifies nodes into ones with labels and without labels. func (s *ServiceAntiAffinity) getNodeClassificationByLabels(nodes []*v1.Node) (map[string]string, []string) { labeledNodes := map[string]string{} nonLabeledNodes := []string{} for _, node := range nodes { if labels.Set(node.Labels).Has(s.label) { label := labels.Set(node.Labels).Get(s.label) labeledNodes[node.Name] = label } else { nonLabeledNodes = append(nonLabeledNodes, node.Name) } } return labeledNodes, nonLabeledNodes } </ins> // CalculateAntiAffinityPriority spreads pods by minimizing the number of pods belonging to the same service // on machines with the same value for a particular label. // The label to be considered is provided to the struct (ServiceAntiAffinity).

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Kubernetes version (use ): master What happened: The functionality is hidden in a large function, and not explicit, testable. What you expected to happen: The logic of should read more clearly, with tests for individual filters.
has a PR for this .
Few more things include removing limits in entries like
yeah, im not sure why the thing is there, after all they are just appending to the slice and the limit wont have an effect , from what i can tell, will it? probably good idea to remove unless im missing something.
Its part of part of PR too.
Change:
return &Options{ config:      new(kubeproxyconfig.KubeProxyConfiguration), healthzPort: ports.ProxyHealthzPort, <ins> metricsPort: ports.ProxyStatusPort, </ins> scheme:      scheme.Scheme, codecs:      scheme.Codecs, CleanupIPVS: true,

Discussion:
What happened: From We used to allow using or in and . Now the validation on kubeproxyconfig disallow that (it only allows ): This seems to break backward compatibility for those two flags. Please comment if I'm missing something. cc How to reproduce it (as minimally and precisely as possible): Try with kube-proxy. Environment: Kubernetes version (use ):
/sig network /kind bug
Tried , the error is: and , the error is: So maybe we need to loosen and revert ?
Loosen the validation sounds good. was meant for loosen the validation as well (allowing not just ip, but also ip:port), but for some reason it doesn't work as intended. Would be great to fix that instead of revert :)
find the root cause of not working as expected. introduced the regression: I send a PR to fix the two issues we mentioned in this thread.
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
/remove-lifecycle stale
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with .

/close 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
I believe this hasn't been fixed yet. /remove-lifecycle rotten /reopen
Reopened this issue. <detailsIn response to : I believe this hasn't been fixed yet. /remove-lifecycle rotten /reopen 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
I agree There's also the issue of IPv6-only: Results in:
Thanks for your report. Do you mind opening a new issue regarding IPv6 since the original issue was fixed? Thanks.
Sure. Thanks
Please see:
Change:
spec = specHandler.DefaultSpec() } <del> // Pass all parameters as volume labels for Portworx server-side processing. spec.VolumeLabels = p.options.Parameters </del> <ins> // Pass all parameters as volume labels for Portworx server-side processing if len(p.options.Parameters) > 0 { spec.VolumeLabels = p.options.Parameters } else { spec.VolumeLabels = make(map[string]string, 0) } </ins> // Update the requested size in the spec spec.Size = uint64(requestGiB * volutil.GIB)

Discussion:
BUG REPORT: Portworx volume plugin when a PVC is created using a StorageClass with empty parameters /kind bug What happened: Create a StorageClass using empty parameters and then create a PVC using that storage class. The PVC will remain in pending state. On inspecting the logs of the controller manager, we find that the portworx volume plugin is panicing. What you expected to happen: PVC should have been created successfully. How to reproduce it (as minimally and precisely as possible): Create following storage class and PVC Anything else we need to know?: Environment: N/A Kubernetes version (use ): 1.9.7, 1.10.1, 1.8.8 Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A
/sig storage
Change:
ginkgo.It(t.name, func(ctx context.Context) { m.init(ctx, testParameters{ registerDriver: true, <del> podInfo:        test.oldPodInfoOnMount}) </del> <ins> podInfo:        &test.oldPodInfoOnMount}) </ins> ginkgo.DeferCleanup(m.cleanup) <del> waitUntilPodInfoInLog(ctx, m, test.oldPodInfoOnMount != nil && *test.oldPodInfoOnMount, false, 1) m.update(utils.PatchCSIOptions{PodInfo: test.newPodInfoOnMount}) waitUntilPodInfoInLog(ctx, m, test.newPodInfoOnMount != nil && *test.newPodInfoOnMount, false, 2) </del> <ins> waitUntilPodInfoInLog(ctx, m, test.oldPodInfoOnMount, false) m.update(utils.PatchCSIOptions{PodInfo: &test.newPodInfoOnMount}) waitUntilPodInfoInLog(ctx, m, test.newPodInfoOnMount, false) </ins> }) } }) }) <del> func waitUntilPodInfoInLog(ctx context.Context, m *mockDriverSetup, expectPodInfo, expectEphemeral bool, expectedNumNodePublish int) { </del> <ins> func waitUntilPodInfoInLog(ctx context.Context, m *mockDriverSetup, expectPodInfo, expectEphemeral bool) { </ins> var err error utils.WaitUntil(framework.Poll, framework.PodStartTimeout, func() bool {

Discussion:
1 ci-kubernetes-e2e-gci-gce 1 ci-cos-containerd-e2e-cos-gce in the master blocking test grid 1 ci-kubernetes-e2e-gci-gce-network-proxy-grpc 1 ci-kubernetes-e2e-gci-gce-proto Kubernetes e2e suite.[It] [sig-storage] CSI Mock workload info CSI PodInfoOnMount Update should be passed when update from false to true 12/14 code thaw after 1.29.0 release was merged at the time and is related to PodInfoOnMount. /cc /sig storage
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
testCase: podInfoOnMount should be passed when update from false to true kubelet log: csi-mockplugin-0-mock log: the function in the test case is not working as expected. expect log at Line 2, but actual log is at Line 3.
is called twice for the same volume sometime even though the volume is already published successfully. Not only this issue, but also other issues like I wonder if it is a potential bug or a normal behavior. cc what do you think?
good catch. I think that any test that depends on exact index of NodePublish call will be flaky, sometimes Kubelet has to retry NodePublish. It would be better to check for NodePublish parameter changes. For example, test should check there were 1 or more NodePublish calls with no pod info and then 1 or more NodePublish calls with pod info afterwards.
Change:
} // Flush and remove all of our chains. Flushing all chains before removing them also removes all links between chains first. <del> for _, ch := range iptablesChains { </del> <ins> for _, ch := range iptablesCleanupChains { </ins> if err := ipt.FlushChain(ch.table, ch.chain); err != nil { if !utiliptables.IsNotFoundError(err) { klog.Errorf("Error removing iptables rules in ipvs proxier: %v", err)

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /sig network What happened: Kube-proxy () deployed as daemonset with ipvs mode produce during startup following error: With verbosity -v5 the logs looks like this: Looks like proxier is trying to perform cleanup part: but failed. Such error is generated only once during startup. What you expected to happen: Error should not exist :) Environment: Kubernetes version (use ): 1.11.1 Cloud provider or hardware configuration: none OS (e.g. from /etc/os-release): Ubuntu 16.04 LTS Kernel (e.g. ): Install tools: custom script based on docker Others:
I've build kube-proxy with additional information: and the logs looks like this:
same issue
Looks like also fixed this one.
I'm on 1.12.0 and the issue is still there I suppose is included in 1.12?
Updated my kube to 1.12.3 and I got same
I'm still seeing this on v1.12.4 as well
same here on v1.13.2, throws this error when kube-proxy initializes. Running on CoreOS in ipvs mode:
Hello, I also encountered this problem in Kubernetes 1.13.3. The operating system is CentOS 7.6. The kernel version is: Linux linux-node4 3.10.0-957.el7.x86_64
Why is this closed? It looks like an unresolved issue. I have the same errors with 1.12.1.
same as me
same as me,1.12.3
same problem OS: Ubuntu 18 kernel: 4.15.0-46-generic Kubernetes: 1.13.4
same problem OS: CentOS 7.6 kernel: 3.10.0-957.el7.x86_64 Kubernetes: 1.13.4
I met this issue on Centos 7.6 with NetworkManager installed, it seems related to the network.
Same problem OS: CentOS 7.4 Kubernetes: 1.12.5 NetworkManager not installed.

Some of the nodes does not have this issue while others do
I am getting in 1.14.0 as well in some worker nodes.
same problem,how to solve it
same problem 1.13.2 ,how fix it?
i update kube-proxy 1.14.2, the error message is disappear
same problem OS: Debian 8 Kubernetes: v1.15.0 iptables v1.4.21 kube-proxy mode ipvs I write some test code like kube-proxy --cleanup and found line 7 is , and run , the error is The problem is we should flush KUBE-LOAD-BALANCER and KUBE-NODE-PORT before delete KUBE-MARK-MASQ , I can try fix it.
Change:
- baseImportPath: "./vendor/k8s.io/kms/" allowedImports: <del> - k8s.io/apimachinery - k8s.io/klog </del> - k8s.io/kms - baseImportPath: "./vendor/k8s.io/endpointslice/"

Discussion:
Drop the and dependencies from to keep the import lighter. /sig auth /triage accepted
/assign Hi, , I created a PR to fix this. I am not sure If I am correct due to the repo seems generated. Would you like to provides some hints for me?
This will likely require a new go module in to move the client-go dep and then mark it as internal, ex: . is the only API machinery dep so we can probably come up with some way to re-implement the wait logic locally? Then we drop these lines so that these imports do not come back again:
Whoa, yeah, I'd take a for loop and a time.Sleep in a test to drop those deps
What is kms using client-go for? Tests only?
These were all needed by the KMS repo back when we had a much more complicated reference implementation which required a key hierarchy. Now they are just used in some tests and mock implementations, so we should be able to simplify things.
I found a place for rate limit. #liggitt
that package just delegates to "", switch that mock provider to use that directly?