jiebi/CodeConvo huggingface dataset:
Change:
<!-- 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: flag is not supported on Azure Stack, should switch to use original way to remove a disk from data disk list, refer to for more details What you expected to happen: How to reproduce it (as minimally and precisely as possible): 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 /assign /priority important-soon /sig cloud-provider /area provider/azure

Discussion:
(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> disks[i].ToBeDetached = to.BoolPtr(true) </del> <ins> if strings.EqualFold(as.cloud.Environment.Name, "AZURESTACKCLOUD") { disks = append(disks[:i], disks[i+1:]...) } else { disks[i].ToBeDetached = to.BoolPtr(true) } </ins> bFoundDisk = true break }

(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> disks[i].ToBeDetached = to.BoolPtr(true) </del> <ins> if strings.EqualFold(ss.cloud.Environment.Name, "AZURESTACKCLOUD") { disks = append(disks[:i], disks[i+1:]...) } else { disks[i].ToBeDetached = to.BoolPtr(true) } </ins> bFoundDisk = true break }
Change:
<!-- 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: ci-kubernetes-e2e-gci-gce Which test(s) are flaking: [sig-network] EndpointSlice should create Endpoints and EndpointSlices for Pods matching a Service Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated Flaking across jobs: <!-- Please see the deflaking doc () for more guidance! --/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
I 've seen this before , I could not investigate it too much, but if I undertood the test it seems that is creating 1 additional endoint, it is creating 3 instead of 2
I thought I already fixed a flake like this bug with , apparently not. It looks like the new error is that it's not necessarily more EndpointSlices, but duplicate endpoints. This could happen in the following scenario: 1 is created runs, creates 1 EndpointSlice with Pod 1 2 is created runs, does not find any existing EndpointSlices in cache, creates a new one with Pod 1 and 2 This would be resolved by a later sync, but of course there's nothing to trigger that in this test. Since I think we simply need to update the tests to accept them. I may not have time to get to this until Friday so if anyone else wants to take it on before then let me know. /assign
I 've sent a PR to fix it, PTAL
/remove-triage unresolved
Hi , any update on this?
Hey sorry for the delay on this! I'd done an initial review on initial fix but had missed following up. I've left a follow up now.

Discussion:
for _, endpointSlice := range esList.Items { actualNumEndpoints += len(endpointSlice.Endpoints) } <del> if actualNumEndpoints != numEndpoints { </del> <ins> // In some cases the EndpointSlice controller will create more // EndpointSlices than necessary resulting in some duplication. This is // valid and tests should only fail here if less EndpointSlices than // expected are added. if actualNumEndpoints < numEndpoints { </ins> framework.Logf("EndpointSlices for %s/%s Service have %d/%d endpoints", ns, svcName, actualNumEndpoints, numEndpoints) return esList.Items, false }
Change:
<!-- 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: bazel-test-master Which test(s) are flaking: - TestWatchBookmarksWithCorrectResourceVersion Testgrid link: Reason for failure: Anything else we need to know: links to appreciated Somehow nothing seen on triage - wonder why? links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --/sig testing
is still only reporting up to Sept 21 Other instances of non-deterministic result (NDR)
/sig api-machinery /sig storage Not 100% sure which SIG should triage the data race on which is producing non-deterministic results (NDRs) during CI can you both take a look and let me know? Many thanks, CI Signal Team Lead for 1.20 (release team)
The label(s) cannot be applied, because the repository doesn't have them <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
Looks like the bot didn't pick up the SIG tags - /sig api-machinery /sig storage
/sig scalability /remove-sig storage
I'm sending a fix
t.Fatal was getting called long after the test had exited, because the test was shutting down the framework before the goroutine had exited.

Discussion:
"reflect" goruntime "runtime" "strconv" <ins> "sync" </ins> "testing" "time"

defer watcher.Stop() done := make(chan struct{}) <del> defer close(done) </del> <ins> var wg sync.WaitGroup wg.Add(1) defer wg.Wait()   // We must wait for the waitgroup to exit before we terminate the cache or the server in prior defers defer close(done) // call close first, so the goroutine knows to exit </ins> go func() { <ins> defer wg.Done() </ins> for i := 0; i < 100; i++ { select { case <-done:
Change:
What happened: The function return when whitelist is empty. The function is implemented as follows: What you expected to happen: When the whitelist is empty, any key of labels can not in it. Should the function return when whitelist is empty?
/sig api-machinery
/assign /cc (we think you might have opinions on fixing this)
I only see one consumer. Rather than change the semantic, I would suggest moving it to the point of use and renaming it.
Yes, this function is wrong, I agree with David. P.S. we don't advertise interface stability for this library so this is OK. But even if we did, I think callers of this function are probably not expecting this behavior and should be examined.) P.P.S. The way it should work is via set difference, the labels should be a subset of the list. P.P.P.S. These are sets and not lists, and the names should be changed to reflect that. P.P.P.P.S. If you're making a change here anyway, please lose the word "whitelist".
Okay, I will submit a pr.

Discussion:
if err != nil { return err } <del> if !labels.AreLabelsInWhiteList(pod.Spec.NodeSelector, whitelist) { </del> <ins> if !isSubset(pod.Spec.NodeSelector, whitelist) { </ins> return errors.NewForbidden(resource, pod.Name, fmt.Errorf("pod node label selector labels conflict with its namespace whitelist")) }

} return selector, nil } <ins> func isSubset(subSet, superSet labels.Set) bool { if len(superSet) == 0 { return true } for k, v := range subSet { value, ok := superSet[k] if !ok { return false } if value != v { return false } } return true } </ins>

return true } <del> // AreLabelsInWhiteList verifies if the provided label list // is in the provided whitelist and returns true, otherwise false. func AreLabelsInWhiteList(labels, whitelist Set) bool { if len(whitelist) == 0 { return true } for k, v := range labels { value, ok := whitelist[k] if !ok { return false } if value != v { return false } } return true } </del> // ConvertSelectorToLabelsMap converts selector string to labels map // and validates keys and values func ConvertSelectorToLabelsMap(selector string) (Set, error) {
Change:
<!-- 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: prometheus cadvisor machine metrics from kubelet are missing What you expected to happen: How to reproduce it (as minimally and precisely as possible): install k8s 1.19, compare behavior to k8s <1.19 Anything else we need to know?: Looks like missing call to in , machine metrics collection was split out in cadvisor 0.37 Environment: Kubernetes version (use ):
/sig node (hope that's the correct sig :)
Suggest from as an alternative (declared as "stable").
Related PR Their output format changed too:
Multiple queries is invalide now. Is there any workaroud for this? Please help. Thanks.
if you run see for an alternative metric.
+1 on the issue. This issue has caused the node metric collection for Azure Monitor for Containers to be broken which also impacts alerting.
Exposed metrics are a kind of an API and should not be removed without warning.
any news, when this will be fixed? Thanks in advance!
It is not possible to have a metric available without exposing it. To provide stability information on metrics, similar to APIs, you might want to read up on the . There currently are no metrics in Kubernetes itself that are considered stable, but SIG Instrumentation hopes to be selecting some for the 1.21 release. This particular issue seems like an unintended bug as opposed to an intentional deprecation. Suspect this issue got lost in SIG Node's backlog. I'll put it on the agenda for the next SIG Instrumentation meeting. /sig instrumentation
Backports in and

Discussion:
if err != nil { return nil, err } <ins> // Avoid collector collects it as a timestamped metric // See PR #95210 and #97006 for more details. machineInfo.Timestamp = time.Time{} </ins> klet.setCachedMachineInfo(machineInfo) imageBackOff := flowcontrol.NewBackOff(backOffPeriod, MaxContainerBackOff)

Recursive: true, } r.RawMustRegister(metrics.NewPrometheusCollector(prometheusHostAdapter{s.host}, containerPrometheusLabelsFunc(s.host), includedMetrics, clock.RealClock{}, cadvisorOpts)) <ins> r.RawMustRegister(metrics.NewPrometheusMachineCollector(prometheusHostAdapter{s.host}, includedMetrics)) </ins> s.restfulCont.Handle(cadvisorMetricsPath, compbasemetrics.HandlerFor(r, compbasemetrics.HandlerOpts{ErrorHandling: compbasemetrics.ContinueOnError}), )
Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: ci-kubernetes-e2e-gce-scale-correctness Which test(s) are failing: [sig-network] Services should only allow access from service loadbalancer source ranges [Slow] Since when has it been failing: Constant failure from 2020-09-23 Testgrid link: Reason for failure: From Similar logs found in previous runs Anything else we need to know: There is open bug () for flakes, however this is not a flake, but a constant failure. /sig networking
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : Which jobs are failing: ci-kubernetes-e2e-gce-scale-correctness [sig-network] Services should only allow access from service loadbalancer source ranges [Slow] Constant failure from 2020-09-23 From Similar logs found in previous runs There is open bug () for flakes, however this is not a flake, but a constant failure. 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
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
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/priority critical
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /priority critical 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 critical-urgent
ok, I think I got it,
so, it seems the 500 error is generated because it is using GenerateName, but ti has the pod.Name hardcoded
So do we know if this is related to any single proxy mode or applies for all? Trying to figure out how it relates to & since those were only pertaining to IPVS.
This is a new problem that affected the same test in all modes, it was not a network problem at the end The ipvs one was flaky before this, I'll reopen it

Discussion:
// newExecPodSpec returns the pod spec of exec pod func newExecPodSpec(ns, generateName string) *v1.Pod { <del> pod := NewAgnhostPod(ns, "agnhost-pod", nil, nil, nil) </del> <ins> // GenerateName is an optional prefix, used by the server, // to generate a unique name ONLY IF the Name field has not been provided pod := NewAgnhostPod(ns, "", nil, nil, nil) </ins> pod.ObjectMeta.GenerateName = generateName return pod }
Change:
What happened: We print out massive go structs during the granular network checks What you expected to happen: not print 7K log messages :) How to reproduce it (as minimally and precisely as possible): run sonobuoy with and you'll get this in the logs :) ! Anything else we need to know?: easy fix, will print out the pod json which is much more concise.
/triage accepted
/assign
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍

Discussion:
// we confirm unreachability. framework.Logf("Failed to execute %q: %v, stdout: %q, stderr: %q", cmd, err, stdout, stderr) } else { <del> framework.Logf("Tries: %d, in try: %d, stdout: %v, stderr: %v, command run in: %#v", tries, i, stdout, stderr, config.TestContainerPod) </del> <ins> podInfo := fmt.Sprintf("name: %v, namespace: %v, hostIp: %v, podIp: %v, conditions: %v", config.TestContainerPod.Name, config.TestContainerPod.Namespace, config.TestContainerPod.Status.HostIP, config.TestContainerPod.Status.PodIP, config.TestContainerPod.Status.Conditions) framework.Logf("Tries: %d, in try: %d, stdout: %v, stderr: %v, command run in Pod { %#v }", tries, i, stdout, stderr, podInfo) </ins> var output NetexecDialResponse if err := json.Unmarshal([]byte(stdout), &output); err != nil { framework.Logf("WARNING: Failed to unmarshal curl response. Cmd %v run in %v, output: %s, err: %v",
Change:
only check that the output includes the correct keys - they don't confirm that it has appropriate values. Doing full validation on the version data, or at least enough to catch null-string values, would guard against failures like the bad functionality seen in OpenSUSE's binaries, which have been shipping with many of the fields left completely blank (as I discovered ).
/sig testing
/remove-sig testing /sig cli Edit: testing owns the framework, binaries, infrastructure etc. for testing. SIG CLI is nominally responsible for their test cases.
If SIGs are responsible for their own testcases, then this touches test cases for api-machinery as well (I'm not sure what the non-CLI version of this is, but there's definitely a schema adherence test that should fail at the API level). /sig api-machinery
/triage accepted /assign
GitHub didn't allow me to assign the following users: SaiHarshaK. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /triage accepted /assign 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
/assign

Discussion:
Description: The command 'kubectl version' MUST return the major, minor versions,  GitCommit, etc of the Client and the Server that the kubectl is configured to connect to. */ framework.ConformanceIt("should check is all data is printed ", func() { <del> version := framework.RunKubectlOrDie(ns, "version") requiredItems := []string{"Client Version:", "Server Version:", "Major:", "Minor:", "GitCommit:"} </del> <ins> versionString := framework.RunKubectlOrDie(ns, "version") // we expect following values for: Major -> digit, Minor -> numeric followed by an optional '+',  GitCommit -> alphanumeric requiredItems := []string{"Client Version: ", "Server Version: "} </ins> for _, item := range requiredItems { <del> if !strings.Contains(version, item) { framework.Failf("Required item %s not found in %s", item, version) </del> <ins> if matched, _ := regexp.MatchString(item+`version.Info{Major:"d", Minor:"d++?", GitVersion:"vd.d+.[dw-.+]+", GitCommit:"[0-9a-f]+"`, versionString); !matched { framework.Failf("Item %s value is not valid in %sn", item, versionString) </ins> } } })
Change:
What happened: In CAPA clusters, NodePorts are disabled for UDP but not for TCP, so when testing, we see a small hole in coverage that was luckily caught by the tests.... So, I noticed that we thus don't have a targetted ginkgo test for UDP + nodeports, but we do seem to have the Contract one, which I guess tests two things at once: UDP NodePort service works Conntrack can persist the service We do have but this test is obviously testing many other things as well. So, would like to have a test.... What you expected to happen: running the sig-network test suite, while skipping with UDP not working would result in a test failure specific to UDP and NodePorts. How to reproduce it (as minimally and precisely as possible): Run the test suite, skip , with a UDP firewall up - you'll see no relevant failures. Anything else we need to know?: Environment: Kubernetes version (use ): master
/sig network
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
There is already one testing NodePort UDP in
However, the more tests the better :+1:
Hiya Antonio. I think the one your talking about in granular checks is also tagged as "Slow"..... Is there a FAST one? If so I'll close this issue don't want to make a redundant test . :)
I honestly don't know the history of the Slow tag and I don't see it consistently applied, but if you think that you can improve the Granular check and have an additional faster test, then just go for it :muscle:
ok cool

Discussion:
config.createTestPods() epCount := len(config.EndpointPods) <ins> // Note that this is not O(n^2) in practice, because epCount SHOULD be < 10.  In cases that epCount is > 10, this would be prohibitively large. // Check maxNetProxyPodsCount for details. </ins> config.MaxTries = epCount*epCount + testTries framework.Logf("Setting MaxTries for pod polling to %v for networking test based on endpoint count %v", config.MaxTries, epCount) }

} }) <ins> // quick validation of udp, next test confirms that this services update as well after endpoints are removed, but is slower. ginkgo.It("should support basic nodePort: udp functionality", func() { config := e2enetwork.NewNetworkingTestConfig(f, true, false) ginkgo.By(fmt.Sprintf("dialing(udp) %v (node) --> %v:%v (nodeIP) and getting ALL host endpoints", config.NodeIP, config.NodeIP, config.NodeUDPPort)) err := config.DialFromNode("udp", config.NodeIP, config.NodeUDPPort, config.MaxTries, 0, config.EndpointHostnames()) if err != nil { framework.Failf("Failure validating that nodePort service WAS forwarding properly: %v", err) } }) </ins> // Slow because we confirm that the nodePort doesn't serve traffic, which requires a period of polling. ginkgo.It("should update nodePort: udp [Slow]", func() { config := e2enetwork.NewNetworkingTestConfig(f, true, false)
Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: While trying to run the node conformance tests with CRIO, the test I noticed failures like on the logs of the test containers. This happens because CRIO doesn't ship with capability enabled by default. Since only this test in requires it, we should add this capability only in this test and not runtime wide. Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: CRIO doesn't ship with by default. Anything else we need to know:
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 node

Discussion:
"strings" "time" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" kubeletstatsv1alpha1 "k8s.io/kubelet/pkg/apis/stats/v1alpha1"

RestartPolicy: v1.RestartPolicyAlways, Containers: []v1.Container{ { <del> Name:    "busybox-container", Image:   busyboxImage, </del> <ins> Name:  "busybox-container", Image: busyboxImage, SecurityContext: &v1.SecurityContext{ Capabilities: &v1.Capabilities{ Add: []v1.Capability{"CAP_NET_RAW"}, }, }, </ins> Command: getRestartingContainerCommand("/test-empty-dir-mnt", 0, numRestarts, "echo 'some bytes' >/outside_the_volume.txt; ping -c 1 google.com; echo 'hello world' >> /test-empty-dir-mnt/file;"), Resources: v1.ResourceRequirements{ Limits: v1.ResourceList{
Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: NodeConformance is too rigid, and that makes it fail on certain platforms. It even For e.g the test right now assumes that it will always enter in the the condition here, but never accounts for the scenrio where the code might enter in , which is also a valid execution scenario. Which test(s) are failing: Summary API Tests - Since when has it been failing: Testgrid link: https://k8s- Reason for failure: Anything else we need to know:
/sig node
Sample output of on CRIO running on Fedora CoreOS,
/assign /triage accepted /priority important-longterm /cc
Coming back to this.. should merge soonish. As soon as that happens then we can see if the test mentioned here improves.
In my test setup I noticed that end up being 0, and that causes the test to fail. Just to verify, I hard coded a value greater than 1000 there (because what the test case is expecting) and the test started passing. I will investigate more on why the values coming from cadvisor for filesytem usage is 0 sometimes.

Discussion:
ginkgo.By("Validating /stats/summary") // Give pods a minute to actually start up. <del> gomega.Eventually(getNodeSummary, 1*time.Minute, 15*time.Second).Should(matchExpectations) </del> <ins> gomega.Eventually(getNodeSummary, 90*time.Second, 15*time.Second).Should(matchExpectations) </ins> // Then the summary should match the expectations a few more times. gomega.Consistently(getNodeSummary, 30*time.Second, 15*time.Second).Should(matchExpectations) })