jiebi/CodeConvo huggingface dataset:
Change:
}) } } <ins> if err := validateSelectedConfigs(configs); err != nil { return nil, err } </ins> return configs, nil } <ins> // validateSelectedConfigs validates the config weights to avoid the overflow. func validateSelectedConfigs(configs []algorithm.PriorityConfig) error { var totalPriority int for _, config := range configs { // Checks totalPriority against MaxTotalPriority to avoid overflow if config.Weight*schedulerapi.MaxPriority > schedulerapi.MaxTotalPriority-totalPriority { return fmt.Errorf("Total priority of priority functions has overflown") } totalPriority += config.Weight * schedulerapi.MaxPriority } return nil } </ins> var validName = regexp.MustCompile("^[a-zA-Z0-9]([-a-zA-Z0-9]*[a-zA-Z0-9])$") func validateAlgorithmNameOrDie(name string) {

Discussion:
Weight is an int (see ). Priority can take the range 1-10. Total priority for a node is sum of weight  priority for each priority function, and the sum is accumulated into an int (see ). So obviously the total priority can overflow if someone sets the weight(s) too high. The weights of all priority functions are compiled in (or specified in config file), so we can check to make sure maximum total priority can't overflow an int (take sum over all priority functions of 10  weight of that priority function, and make sure that's smaller than int(MaxUint 1) which according to StackOverflow is the way to find out what is max int (math package has max Int32, Int64, etc. but not max Int). Note that scheduler extender is OK because although the policy runs in a separate process, the weight is specified in scheduler config file (ExtenderConfig struct) and the priority is bounded 1-10 as usual.
We really should also make "score" be an abstract datatype rather than a raw int that is manipulated directly, so we can do things like make sure it is in the range 1-10 (or 0-10 if that's what we want); today the range is inconistent (we say 1-10, but sometimes use 0; probably we should change it to 0-9..).
I volunteer myself to do this.
I think we can check weight overflow in after we get all PriorityConfig. what do you think about this?
As for "score" I think we can use
Fixed by - closing.
Tim that PR was closed, not merged. I don't think this is fixed yet.
whoops, good catch, just removing milestone then. There was a shift that happened yesterday where a bunch of items suddenly came into the 1.6 query.
do we still want this fixed? I can re-pick this.
AFAIK it's still broken. cc/
Ok, I will open a PR tomorrow.
Change:
func (hcI *hcInstance) closeAll() error { errors := []error{} <del> for _, listener := range hcI.listeners { if err := listener.Close(); err != nil { klog.ErrorS(err, "Error closing listener for health check service", "service", hcI.nsn, "address", listener.Addr()) </del> <ins> for _, server := range hcI.httpServers { if err := server.Close(); err != nil { klog.ErrorS(err, "Error closing server for health check service", "service", hcI.nsn) </ins> errors = append(errors, err) } }

Discussion:
When a LoadBalancer Service with Local ExternalTrafficPolicy was deleted normally, an error log "use of closed network connection" was always generated in kube-proxy log, which confused people that there was something wrong: Do not generate error log when it's expected. a LoadBalancer Service with Local ExternalTrafficPolicy it No response <detailsv1.26.0 </details<details</details<details</details<details</details<details</details<details</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
/sig network
Change:
Expect(err).NotTo(HaveOccurred()) var pods *v1.PodList var err2 error <del> if err := wait.Poll(5*time.Second, 30*time.Second, func() (bool, error) { </del> <ins> // TODO: shorten the timeout when we make GC's periodic API rediscovery more efficient. // Tracked at https://github.com/kubernetes/kubernetes/issues/50046. if err := wait.Poll(5*time.Second, 90*time.Second, func() (bool, error) { </ins> pods, err2 = podClient.List(metav1.ListOptions{}) if err2 != nil { return false, fmt.Errorf("Failed to list pods: %v", err)

Discussion:
Perhaps it has the same root cause as
Case 1: Delete request sent at: Cycle removed at: Deletion of pods: The cycle was removed. And the pods were deleted properly. But it took 43s in total. API rediscovery in that period: Which took 16s.
Case 2: Delete request: Cycle removed at: Pods deleted at: Took 41 seconds. API re-discovery: Took 13s. Another thing I noticed is that the re-discovery always traverses the discovery endpoints back-to-back twice.
case 3: Deletion started at: GC first action at: Watch latency is around 5s. Cycle removed at GC deletes the Pods at: Took 30s. API re-discovery: Took 10s.
The cause is the same as . The periodic API rediscovery adds latency. Also, the watch latency is also quite high. I'll send a PR to increase the timeout
: Deletion started at: GC's first action at: GC deletes the last Pod at: Took 99s. Experienced 3 API re-discoveries: 37s in total
The test is much after we extended the timeout to 90s. We can further extend the timeout if needed.
Change:
List Kubernetes kubectl get pods <del> kubectl grt minions </del> <ins> kubectl get minions </ins> Kill all pods:

Discussion:
https://k8s- /kind bug /sig testing /milestone v1.10 /priority failing-test cc /assign I'll dig into it and see if I can find any clue
/priority critical-urgent
/status approved-for-milestone the tests were timing out, I'll bump the timeout a bit
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
(will watch the next runs)
(looks like 2h is not enough, I'll give it a bit more time, and I'll diff the test output)
https://k8s- green run now, took 10h, the previous cluster was somehow bad on beforesuite. I'll close this.
Change:
} if !helper.IsServiceIPSet(service) { <del> newEndpoints.Labels[v1.IsHeadlessService] = "" </del> <ins> newEndpoints.Labels = utillabels.CloneAndAddLabel(newEndpoints.Labels, v1.IsHeadlessService, "") </ins> } else { <del> delete(newEndpoints.Labels, v1.IsHeadlessService) </del> <ins> newEndpoints.Labels = utillabels.CloneAndRemoveLabel(newEndpoints.Labels, v1.IsHeadlessService) </ins> } klog.V(4).Infof("Update endpoints for %v/%v, ready: %d not ready: %d", service.Namespace, service.Name, totalReadyEps, totalNotReadyEps)

Discussion:
bug (): Originally posted by in cc /sig network /priority critical-urgent
fix in
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Change:
} if res, err := testutils.PodRunningReady(&pod); res && err == nil { nOk++ <del> if hasReplicationControllersForPod(rcList, pod) { replicaOk++ } </del> } else { if pod.Status.Phase != api.PodFailed { Logf("The status of Pod %s is %s (Ready = false), waiting for it to be either Running (with Ready = true) or Failed", pod.ObjectMeta.Name, pod.Status.Phase) badPods = append(badPods, pod) <del> } else if !hasReplicationControllersForPod(rcList, pod) { Logf("Pod %s is Failed, but it's not controlled by a ReplicationController", pod.ObjectMeta.Name) </del> <ins> } else if _, ok := pod.Annotations[api.CreatedByAnnotation]; !ok { Logf("Pod %s is Failed, but it's not controlled by a controller", pod.ObjectMeta.Name) </ins> badPods = append(badPods, pod) } <del> //ignore failed pods that are controlled by a replication controller </del> <ins> //ignore failed pods that are controlled by some controller </ins> } }

Discussion:
The logic to account for all pods being ready is incorrectly counting some pods as being controlled by a replication controller. This is causing the 1.3-1.5 upgrade tests to fail. See https://k8s- as an example. Since , the pre-flight checks fail and the rest of the tests never run. I think this was exposed by which changed some things from ReplicationControllers to Deployments. There's a pod being created by a deployment that also matches the selector of a replication controller, and is therefore being incorrectly counted by cc
Change:
// Test access to the volume from pods on different node TestConcurrentAccessToSingleVolume(l.config.Framework, l.cs, l.ns.Name, <del> l.config.ClientNodeSelection, resource.Pvc, numPods, false /* sameNode */) </del> <ins> l.config.ClientNodeSelection, resource.Pvc, numPods, false /* sameNode */, false /* readOnly */) </ins> }) }

Discussion:
What happened: Running two pods that use the same iSCSI volume, one of them fails with: What you expected to happen: Both pods should be running Anything else we need to know?: It's caused by iscsi volume plugin persiting iSCSI settings into the mount directory itself (e.g. ): volume plugin creates the global mount directory. volume plugin creates there. volume plugin mounts the volume there. This shadows the file, but it's fine, as long as no other pod uses the same volume on the same node. creates a second pod that uses the volume. volume plugin tries to create in the global volume directory. Since the volume is mounted, it will either writes the file to the volume (!) or fails, if the volume is read-only.
/sig storage /assign /priority impotant-soon
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig storage /assign /priority impotant-soon 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
/priority important-soon
Our e2e did not catch this, because they always create only one pod when testing read-only volumes.
Change:
all: push <del> TAG = 0.5 </del> <ins> TAG = 0.6 </ins> container: docker build -t gcr.io/google_containers/kubekins-test .

Discussion:
It seems like an issue similar to the problem with API server. I'll extend the timeout in the similar fashion. cc
Extending timeout didn't help. It's probably something else.
cc
I think the logs make it pretty clear what went wrong: or does one of you have time to fix this?
The Jenkins docker test image probably needs netcat to be installed. Should be an easy fix; I can take this.
Thanks!
Ugh... neverending story.
This seems like a different problem.
Oh, I see, this actually is the same, but harder: I think the most obvious thing to do is to let kubectl select the port and report back?
reports more occurances. Netcat somehow is no longer installed?
those two are older builds, using , which didn't have netcat yet.
ah thanks!
are you still working on this? Would you like me to take it?
I'm not right now, sorry, feel free to take it.
Change:
func(vs *api.VolumeSource, c fuzz.Continue) { // Exactly one of the fields should be set. //FIXME: the fuzz can still end up nil.  What if fuzz allowed me to say that? <del> fuzzOneOf(c, &vs.HostPath, &vs.EmptyDir, &vs.GCEPersistentDisk, &vs.GitRepo, &vs.Secret, &vs.NFS, &vs.ISCSI) </del> fuzzOneOf(c, &vs.HostPath, &vs.EmptyDir, &vs.GCEPersistentDisk, &vs.GitRepo, &vs.Secret, &vs.NFS, &vs.ISCSI, &vs.Glusterfs) }, func(d *api.DNSPolicy, c fuzz.Continue) {

Discussion:
This looks like a git merge problem (?): I don't see why glusterfs gets the special treatment... is it an error, or is there something funky about glusterfs?
No, you're right. Merge error. , Justin Santa Barbara < :
my bad, thanks!
Change:
} } <ins> func TestApplyPruneObjects(t *testing.T) { cmdtesting.InitTestErrorHandler(t) nameRC, currentRC := readAndAnnotateReplicationController(t, filenameRC) pathRC := "/namespaces/test/replicationcontrollers/" + nameRC for _, fn := range testingOpenAPISchemaFns { t.Run("test apply returns correct output", func(t *testing.T) { tf := cmdtesting.NewTestFactory().WithNamespace("test") defer tf.Cleanup() tf.UnstructuredClient = &fake.RESTClient{ NegotiatedSerializer: resource.UnstructuredPlusDefaultContentConfig().NegotiatedSerializer, Client: fake.CreateHTTPClient(func(req *http.Request) (*http.Response, error) { switch p, m := req.URL.Path, req.Method; { case p == pathRC && m == "GET": bodyRC := ioutil.NopCloser(bytes.NewReader(currentRC)) return &http.Response{StatusCode: http.StatusOK, Header: cmdtesting.DefaultHeader(), Body: bodyRC}, nil case p == pathRC && m == "PATCH": validatePatchApplication(t, req) bodyRC := ioutil.NopCloser(bytes.NewReader(currentRC)) return &http.Response{StatusCode: http.StatusOK, Header: cmdtesting.DefaultHeader(), Body: bodyRC}, nil default: t.Fatalf("unexpected request: %#vn%#v", req.URL, req) return nil, nil } }), } tf.OpenAPISchemaFunc = fn tf.ClientConfigVal = cmdtesting.DefaultClientConfig() ioStreams, _, buf, errBuf := genericclioptions.NewTestIOStreams() cmd := NewCmdApply("kubectl", tf, ioStreams) cmd.Flags().Set("filename", filenameRC) cmd.Flags().Set("prune", "true") cmd.Flags().Set("namespace", "test") cmd.Flags().Set("output", "yaml") cmd.Flags().Set("all", "true") cmd.Run(cmd, []string{}) if !strings.Contains(buf.String(), "test-rc") { t.Fatalf("unexpected output: %snexpected to contain: %s", buf.String(), "test-rc") } if errBuf.String() != "" { t.Fatalf("unexpected error output: %s", errBuf.String()) } }) } } </ins> func TestApplyObjectOutput(t *testing.T) { cmdtesting.InitTestErrorHandler(t) nameRC, currentRC := readAndAnnotateReplicationController(t, filenameRC)

Discussion:
What happened: While testing out the flag, I created a manifest with the following contents: I ran , and the resources appeared on my minikube cluster: Then, I removed the deployment from the manifest: And re-ran the same command, . To my surprise, however, the deployment wasn't removed; the only output from kubectl was . What you expected to happen: I expected the pruner to find the deployment with the matching label, , and prune it. How to reproduce it (as minimally and precisely as possible): I believe my example above is minimal and easily reproducible. Anything else we need to know?: This small change to the code for resolves the issue: Environment: Kubernetes version (use ): v1.16.3 Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig cli
/assign cc
Change:
return expectEdges[i].From().ID() < expectEdges[j].From().ID() }) startEdges := c.start.graph.Edges() <del> sort.Slice(expectEdges, func(i, j int) bool { </del> <ins> sort.Slice(startEdges, func(i, j int) bool { </ins> if startEdges[i].From().ID() == startEdges[j].From().ID() { return startEdges[i].To().ID() < startEdges[j].To().ID() }

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?: What happened: Pulled master and ran: $ make test I get test failure for TestDeleteEdges_locked in What you expected to happen: I expected all tests to run successfully How to reproduce it (as minimally and precisely as possible): Run $ make test, using the most recent version of master (head at commit ), observe that test fails. Anything else we need to know?: This is my first issue, so please let me know if I need to provide any other information! Environment: Kubernetes version (use ): upstream/master (head at commit ) OS (e.g. from /etc/os-release): macOs 10.13.3
/sig testing
/assign
/priority failing-test
This looks like a flaky test. I wonder if the ordering is no longer guaranteed stable in go1.10?
nope, typo in the sorting the test did. fix incoming
/assign
Change:
for _, test := range tests { t.Run(test.name, func(t *testing.T) { <del> preBindPlugin.failPreBind = test.preBindFail </del> <ins> // Create a plugin registry for testing. Register a prebind and a postbind plugin. preBindPlugin := &PreBindPlugin{ failPreBind: test.preBindFail, } postBindPlugin := &PostBindPlugin{ name:                  postBindPluginName, pluginInvokeEventChan: make(chan pluginInvokeEvent, 1), } registry := frameworkruntime.Registry{ preBindPluginName:  newPlugin(preBindPlugin), postBindPluginName: newPlugin(postBindPlugin), } // Setup initial prebind and postbind plugin for testing. prof := schedulerconfig.KubeSchedulerProfile{ SchedulerName: v1.DefaultSchedulerName, Plugins: &schedulerconfig.Plugins{ PreBind: &schedulerconfig.PluginSet{ Enabled: []schedulerconfig.Plugin{ { Name: preBindPluginName, }, }, }, PostBind: &schedulerconfig.PluginSet{ Enabled: []schedulerconfig.Plugin{ { Name: postBindPluginName, }, }, }, }, } // Create the master and the scheduler with the test plugin set. testCtx := initTestSchedulerForFrameworkTest(t, testutils.InitTestMaster(t, "postbind-plugin", nil), 2, scheduler.WithProfiles(prof), scheduler.WithFrameworkOutOfTreeRegistry(registry)) defer testutils.CleanupTest(t, testCtx) </ins> // Create a best effort pod. pod, err := createPausePod(testCtx.ClientSet, initPausePod(&pausePodConfig{Name: "test-pod", Namespace: testCtx.NS.Name}))

Discussion:
Which jobs are flaking: ci-kubernetes-integration-master pull-kubernetes-integration Which test(s) are flaking: TestPostBindPlugin Testgrid link: Reason for failure: Anything else we need to know: links to appreciated: links to specific failures in spyglass appreciated /sig scheduling
It flaked two times recently:
Change:
"A kube-proxy process is already running, don't know what to do" } Log-Output "Creating kube-proxy service" <del> & sc.exe create kube-proxy binPath= "${env:NODE_DIR}kube-proxy.exe ${kubeproxy_args}" start= demand </del> <ins> & sc.exe create kube-proxy binPath= "${env:NODE_DIR}kube-log-runner.exe -log-file=${env:LOGS_DIR}kube-proxy.log ${env:NODE_DIR}kube-proxy.exe ${kubeproxy_args}" start= demand </ins> & sc.exe failure kube-proxy reset= 0 actions= restart/10000 Log-Output "Starting kube-proxy service" & sc.exe start kube-proxy

Discussion:
/kind feature Hey, in K8s 1.23 we are planning to deprecate multiple klog flags. Deprecated flags: , , , , , , , , , , , One of the alpha milestones is requires us to remove usage of deprecated flags within K8s repo. Examples found for windows [ ] [ ] /sig windows /wg structured-logging
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 I've started looking into this. Part of the problem is that go-runner is not part of kubernetes-node-windows- I suspect that is where the scripts get and kube- from.
Change:
return nil } <del> // Makes sure the security group exists </del> <ins> // Makes sure the security group exists. // For multi-cluster isolation, name must be globally unique, for example derived from the service UUID. </ins> // Returns the security group id or error func (s *AWSCloud) ensureSecurityGroup(name string, description string, vpcID string) (string, error) { groupID := ""

Discussion:
If there are two security groups on an instance, we currently make an arbitrary choice. We should choose based on tags, as we normally do. For back-compat, we need to cope if there is one security group and it is not tagged. We should make sure kube-up tags our security groups, though it isn't really required for kube-up, but it is just good behaviour. cf
Change:
// Create loadbalancer service with source range from node[0] and podAccept svc := jig.CreateTCPServiceOrFail(namespace, func(svc *v1.Service) { svc.Spec.Type = v1.ServiceTypeLoadBalancer <del> svc.Spec.LoadBalancerSourceRanges = []string{accpetPod.Status.PodIP + "/32"} </del> <ins> svc.Spec.LoadBalancerSourceRanges = []string{acceptPod.Status.PodIP + "/32"} </ins> }) // Clean up loadbalancer service

Discussion:
Sub-issue for For AWS ELB, when an ELB is first created, is made it is very normal that it takes 2 minutes to be created, but the DNS name is reported fairly quickly.
Change:
produceConfigMapEvents(f, stopc, 5*time.Millisecond) }() <ins> listWatcher := &cachetools.ListWatch{ WatchFunc: func(listOptions metav1.ListOptions) (watch.Interface, error) { return c.CoreV1().ConfigMaps(ns).Watch(context.TODO(), listOptions) }, } </ins> ginkgo.By("creating watches starting from each resource version of the events produced and verifying they all receive resource versions in the same order") wcs := []watch.Interface{} <del> resourceVersion := "0" </del> for i := 0; i < iterations; i++ { <del> wc, err := c.CoreV1().ConfigMaps(ns).Watch(context.TODO(), metav1.ListOptions{ResourceVersion: resourceVersion}) </del> <ins> wc, err := watchtools.NewRetryWatcher(resourceVersion, listWatcher) </ins> framework.ExpectNoError(err, "Failed to watch configmaps in the namespace %s", ns) wcs = append(wcs, wc) resourceVersion = waitForNextConfigMapEvent(wcs[0]).ResourceVersion

Discussion:
By inspection, the "should receive events on concurrent watches in same order" conformance test does two things that are not stable: Starts watches from resourceVersion=0 Relies on watch connections without handling timeouts/restarts This test can fail on clusters that have configmaps autocreated in namespaces already because ordering of watch events for resourceVersion=0 watches is undefined (see ) Watch connections used by conformance tests should use well-defined ordering (starting from resourceVersions other than 0) and handle interruptions properly. 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:
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
Change:
ginkgo.By("Trying to schedule Pod with nonempty NodeSelector.") podName := "restricted-pod" <del> framework.WaitForStableCluster(cs, masterNodes) </del> <ins> WaitForStableCluster(cs, masterNodes) </ins> conf := pausePodConfig{ Name:   podName,

Discussion:
What would you like to be : is used at the beginning of some e2e scheduler tests to wait until the cluster is in a stable state. It currently waits until all existing pods are scheduled, but it should also wait until pods from previous tests are actually deleted. We can do this by assuming that pods should exist only in the kube-system namespace, and so WaitForStableCluster should wait until there are no pods in any other namespace. Why is this needed: /help /sig testing /sig scheduling
/milestone v1.17 /priority critical-urgent
/cc
I'll take this one, can't figure out how to get ci bot to assign to me...
/assign
/remove-help