jiebi/CodeConvo huggingface dataset:
Change:
ss.LoadBalancerSku = loadBalancerSkuStandard ss.ExcludeMasterFromStandardLB = to.BoolPtr(true) <del> expectedVMSS := buildTestVMSS([]string{testLBBackendpoolID0}) </del> <ins> expectedVMSS := buildTestVMSS(testVMSSName, []string{testLBBackendpoolID0}) </ins> mockVMSSClient := ss.cloud.VirtualMachineScaleSetsClient.(*mockvmssclient.MockInterface) mockVMSSClient.EXPECT().List(gomock.Any(), ss.ResourceGroup).Return([]compute.VirtualMachineScaleSet{expectedVMSS}, nil).AnyTimes() mockVMSSClient.EXPECT().Get(gomock.Any(), ss.ResourceGroup, testVMSSName).Return(expectedVMSS, nil).MaxTimes(1)

Discussion:
Which jobs are flaking: pull-kubernetes-bazel-test Which test(s) are flaking: TestEnsureBackendPoolDeletedConcurrently Testgrid link: Reason for failure: /sig cloud-provider
cc
/assign /area provider/azure
Change:
// Injectable for testing. Send the event down the outgoing channel. emit func(watch.Event) <ins> // HighWaterMarks for performance debugging. incomingHWM HighWaterMark outgoingHWM HighWaterMark </ins> cache etcdCache }

Discussion:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
This is pretty much the same failure, that are happening in "gce-enormous" suite and we currently debugging them with The main reason of those failures is that we are terminating all watchers for a particular resource type from time to time, and some of them are actually causing a snowball effect. After more looking into it, my hypothesis is that our machinery for aggregating watchers in apiserver sometimes is just to slow. In particular, I some log in my local branch and what I'm observing is that in etcd_watcher, we are: accumulating objects in incoming channel but also accumulating objects in outgoing channel, and the accumulation there is usually higher [I will send a PR to put those logs into master - they seem to be pretty useful for debugging such issues.] So my current hypothesis is that dispatching watch events to watchers is what is too slow. We will continue debugging.
The logs that I seem to confirm my hypothesis - outgoing channel is generally more full then the incoming channel in etcd_watcher: vs I'm working on the PR that should at least improve the situation.
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.

https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
Please apply the label to this issue if it does not need to be fixed before we launch 1.4. Otherwise please advise on how to proceed with respect to 1.4.
This was a regression - I fixed it by reverting an offending PR: This seems to be fixed now.
I have 33 pods in my container (1 is substantive, the other 32 just run on log files). I get this all the time now. I'm running 1.5.4.
- to be honest, I don't undertsand what your wrote. what is "container" in "33 pods in my container"? Also, if you believe there is a bug somewhere, please open a new issue instead of adding comment to more than half-year-old one.
Change:
if err != nil { return err } <del> c.HealthzChecks = append(c.HealthzChecks, kmsPluginHealthzChecks...) </del> <ins> c.AddHealthChecks(kmsPluginHealthzChecks...) </ins> } return nil

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: The and urls do not provide as much information about the cluster as much as does. It's expected to see and (if kms is enabled) but does not. What you expected to happen: and url to include and How to reproduce it (as minimally and precisely as possible): any 1.16 pre-release cluster the server url for , and Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: IBM OS (e.g: ):Kernel (e.g. ):Install tools: Network plugin and version (if this is a network-related bug): Others: Logs: healthz readyz livez /sig api-machinery
/sig api-machinery
/assign
Change:
open_mode: True auto_accept: True ``` ## Salt minion configuration Each minion in the salt cluster has an associated configuration that instructs the salt-master how to provision the required resources on the machine.

Discussion:
We need to document all the configuration derived by Salt. Ideally this would be a markdown doc that we kept as live documentation within the project. The main reasons to bother: It's hard right now for anyone approaching the directory to get a big picture view of what's is going on, especially across providers. If we ever want to do something disciplined w.r.t. upgrade between (non-dev) versions, we're probably going to need a place to look for the state of the world. Decreasing the velocity with which people can add to Salt configuration will encourage people to delete more Salt configuration. cc
Change:
import ( "fmt" <ins> "path" </ins> "time" <ins> authenticationv1 "k8s.io/api/authentication/v1" </ins> "k8s.io/api/core/v1" apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/apimachinery/pkg/util/wait" "k8s.io/kubernetes/plugin/pkg/admission/serviceaccount"

Discussion:
https://k8s- /sig auth /kind failing-test
Adding a priority to this: /priority important-soon Please raise the priority if you consider this a release blocker. Given the test job, it normally wouldn't be.
It's a test issue. I'm hoping to fix this before 1.13 but I don't consider it a release blocker.
Change:
FROM BASEIMAGE <ins> RUN clean-install bash </ins> ADD kube-addons.sh /opt/ ADD namespace.yaml /opt/ ADD kubectl /usr/local/bin/

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature Alpine fixed a RCE vulnerability in apk in 3.8.1 () Update the base image used for addon-manager () to pick it up. Note: I'd send a PR if it depended directly on alpine image, not bashell/alpine.
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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
/assing
Ping
Change:
} func TestStatusEquality(t *testing.T) { <del> pod := v1.Pod{ Spec: v1.PodSpec{}, } containerStatus := []v1.ContainerStatus{} for i := 0; i < 10; i++ { s := v1.ContainerStatus{ Name: fmt.Sprintf("container%d", i), </del> <ins> getContainersAndStatuses := func() ([]v1.Container, []v1.ContainerStatus) { var containers []v1.Container var containerStatuses []v1.ContainerStatus for i := 0; i < 10; i++ { containerName := fmt.Sprintf("container%d", i) containers = append(containers, v1.Container{Name: containerName}) containerStatuses = append(containerStatuses, v1.ContainerStatus{Name: containerName}) </ins> } <del> containerStatus = append(containerStatus, s) </del> <ins> return containers, containerStatuses } containers, containerStatuses := getContainersAndStatuses() pod := v1.Pod{ Spec: v1.PodSpec{ InitContainers: containers, }, </ins> } podStatus := v1.PodStatus{ <del> ContainerStatuses: containerStatus, </del> <ins> ContainerStatuses:          containerStatuses, InitContainerStatuses:      containerStatuses, EphemeralContainerStatuses: containerStatuses, </ins> } for i := 0; i < 10; i++ { oldPodStatus := v1.PodStatus{ <del> ContainerStatuses: shuffle(podStatus.ContainerStatuses), </del> <ins> ContainerStatuses:          shuffle(podStatus.ContainerStatuses), InitContainerStatuses:      shuffle(podStatus.InitContainerStatuses), EphemeralContainerStatuses: shuffle(podStatus.EphemeralContainerStatuses), </ins> } normalizeStatus(&pod, &oldPodStatus) normalizeStatus(&pod, &podStatus)

Discussion:
is not normalized in in the status manager: This does not seem to cause any user facing problem because is sorted before passed to the status manager and timestamps are normalized at marshaling to create a patch: However, an unexpected behavior is caused internally because timestamps are not normalized. If the log verbosity is 3 or larger, the following messages are logged periodically in kubelet when an ephemeral container exists: This message is emitted here: After returns , is called. This does not look so harmful because gets eventually: API is called once unnecessarily in , though: It might be better to normalize ephemeral container statuses, at least timestamps, in the status manager to avoid this unexpected behavior. Set the log verbosity of kubelet to 3 or larger. Then, create an ephemeral container like . No response <details</details<detailsNone </details<details</details<details</details<details</details<details</details
/sig node
This is a bug. Can you submit a PR to fix it? If not, I'd be happy to work on it
If you are interested, please feel free to assign yourself.
thx
/assign
/triage accepted /priority important-longterm
Change:
<ins> apiVersion: v1 kind: Pod metadata: name: etcd-empty-dir-cleanup namespace: kube-system labels: k8s-app: etcd-empty-dir-cleanup spec: hostNetwork: true dnsPolicy: Default containers: - name: etcd-empty-dir-cleanup image: gcr.io/google_containers/etcd-empty-dir-cleanup:0.0.1 </ins>

Discussion:
I came upon a cluster that had had the namespace code thoroughly exercised. No namespaces currently existed, but many had been created and deleted in the past. Its etcd had lots of empty directories under each resource that had held items when those namespaces were alive (secrets, serviceaccounts, pods...). Do we need to be doing something to clean these empty directories up? It seems like this etcd was consuming a lot of memory.
or might know the answer to this question.
Right. We should delete them. It might get tricky for concurrent cases like A checks if dir is empty, B creates, then A deletes it. What does it look like currently in creating and deleting namespace?
How much memory does a directory entry take? Does it really sound possible to run out of memory while snapshotting on account of too many empty directories?
-- have you guys encountered this? I think you run with more namespaces than we do. But maybe yours are mostly populated?
Yes, we've seen it. c.f.
Approximate memory use we saw from empty dirs:
cc
The patch we debated carrying is here: Our hope was to just wait to etcd v3 where this would not be a problem.
can you link to your clean-up script here?
I needed another PR to run the pod automatically on master.
Change:
#   (otherwise it skips rotation if 'maxsize' is reached multiple times in a #   day). # * keep only 5 old (rotated) logs, and will discard older logs. <del> local logrotate_files=( "kube-scheduler" "kube-proxy" "kube-apiserver" "kube-controller-manager" "kube-addons" ) for file in "${logrotate_files[@]}" ; do cat > /etc/logrotate.d/${file} <<EOF /var/log/${file}.log { </del> <ins> cat > /etc/logrotate.d/allvarlogs <<EOF /var/log/*.log { </ins> rotate 5 copytruncate missingok

Discussion:
GCI log rotation configuration missed "" file. We should just configure log rotation to rotate all "*.log" files in /var/log.
I cherrypicked your change last night. Please do what you need to do to confirm this is resolved.
Thank you, will do.
Verified. Closing issue.
Change:
// createTargetedProbeCommand returns a command line that performs a DNS lookup for a specific record type func createTargetedProbeCommand(nameToResolve string, lookup string, fileNamePrefix string) (string, string) { fileName := fmt.Sprintf("%s_udp@%s", fileNamePrefix, nameToResolve) <del> probeCmd := fmt.Sprintf("dig +short +tries=12 %s %s > /results/%s", nameToResolve, lookup, fileName) </del> <ins> probeCmd := fmt.Sprintf("for i in `seq 1 30`; do dig +short %s %s > /results/%s; sleep 1; done", nameToResolve, lookup, fileName) </ins> return probeCmd, fileName }

Discussion:
There aren't any tests that cover ExternalPort services from Windows pods today. Here's an example manual case that can best explain what needs to be automated. a Windows pod on a Windows node this yaml This shows that DNS is working for the ExternalName service entry. The actual HTTP request fails (by design) because curl is putting the service name in the header which is rejected by the http server itself. /sig windows /good-first-issue
Can explain why you think http server is rejecting service name in header?
curl was using the URL given to set the hostname in the HTTP request. To illustrate what this does - here's another way to get the same result. Ask to give you the page for It can't serve that content so it returns a 404. Therefore, if I had run that would have succeeded.
/milestone v1.14
We could use the test ` for this. This test does: creates an initial ExternalName to and validates the DNS resolution. renames the ExternalName to and validates the new DNS resolution. changes the Service Type to ClusterIP and validates the new DNS resolution.
Is anyone working on this? I'd like to jump on it
sure, go for it. /assign
GitHub didn't allow me to assign the following users: keremgocen. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : sure, go for it. /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
What kind of modifications are required to run e2e in [Windows]. TestName: I'm in process to promote DNS based e2e from into Conformance suite.
HI I am also looking into that test, as it is a bit flaky on Windows. My recommendation would be to increase the retry period / number of retries for the dig command.
Thanks for pointing its Flaky behavior on Windows. I'm in process to setup k8s cluster in Windows env and then troubleshoot.
Ok, looks like the right things are happening. is approved. Once merges it should show up in testgrid for Windows too.

If doesn't make it, this can move to 1.15. I did manual testing (see steps above) and it's ok. Since there's a common test case that should work, we should rely on that instead of adding a Windows-only test. /remove-good-first-issue
/remove-help-wanted
/remove help-wanted
Change:
mockCadvisor. On("ContainerInfoV2", "/", options).Return(infos, nil) fakeRuntimeService.SetFakeSandboxes([]*critest.FakePodSandbox{ <del> sandbox0, sandbox1, sandbox2, sandbox3, sandbox4, sandbox5, </del> <ins> sandbox0, sandbox1, sandbox2, sandbox3, sandbox4, sandbox5, sandbox6, </ins> }) fakeRuntimeService.SetFakeContainers([]*critest.FakeContainer{ <del> container0, container1, container2, container3, container4, container5, container6, container7, container8, </del> <ins> container0, container1, container2, container3, container4, container5, container6, container7, container8, container9, </ins> }) fakeRuntimeService.SetFakeContainerStats([]*runtimeapi.ContainerStats{ <del> containerStats0, containerStats1, containerStats2, containerStats3, containerStats4, containerStats5, containerStats6, containerStats7, containerStats8, </del> <ins> containerStats0, containerStats1, containerStats2, containerStats3, containerStats4, containerStats5, containerStats6, containerStats7, containerStats8, containerStats9, </ins> }) ephemeralVolumes := makeFakeVolumeStats([]string{"ephVolume1, ephVolumes2"})

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: CPU.Time is set to cs.StartTime but ps.Memory.Time is set to timestamp when collecting the memoryusage. What you expected to happen: CPU.Time is set to cs.CPU.Time How to reproduce it (as minimally and precisely as possible): Check the code Anything else we need to know?: Environment: Kubernetes version (use ): master branch when creating this issue. 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:
/assign
/sig kubelet
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig kubelet 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
/sig node
I am happy to take over this. /assign
Change:
return nil, err } if len(addrs) > 0 { <del> // This interface should suffice. break </del> <ins> for _, addr := range addrs { if addrIP, _, err := net.ParseCIDR(addr.String()); err == nil { if addrIP.To4() != nil { ip = addrIP.To4() break } } } if ip != nil { // This interface should suffice. break } </ins> } } } <del> if i == len(intfs) { return nil, err </del> <ins> if ip == nil { return nil, fmt.Errorf("no acceptable interface from host") </ins> } glog.V(4).Infof("Choosing interface %s for from-host portals", intfs[i].Name) <del> addrs, err := intfs[i].Addrs() if err != nil { return nil, err } glog.V(4).Infof("Interface %s = %s", intfs[i].Name, addrs[0].String()) ip, _, err := net.ParseCIDR(addrs[0].String()) if err != nil { return nil, err } </del> return ip, nil }

Discussion:
The master sets its endpoints into the 'kubernetes' service, but endpoints can only be IPv4 today. So ChooseHostInterface() should either not return an IPv6 address, or we should allow endpoints to be IPv6.
I think that this is likely the cause of .
I thought that function explicitly checked for v4. got any bandwidth for review? On May 4, 2015 11:24 AM, "Robert Bailey" wrote:
It doesn't - and on my mac, it fails to find this address when I add that logic. Not sure if that's FlagPointToPoint or something: ----- Original Message -----
PEBKAC for the issue I mentioned above, is opened to fix the choice.
Yeah, I can take a look at later this afternoon, just as soon as I've unbroken ELB's :-) smarterclayton@ let me know if is more urgent than that.
was smaller than I thought, so committed priority inversion I reviewed it :-)
Change:
func (r *Request) transformResponse(resp *http.Response, req *http.Request) Result { var body []byte if resp.Body != nil { <del> if data, err := ioutil.ReadAll(resp.Body); err == nil { </del> <ins> data, err := ioutil.ReadAll(resp.Body) switch err.(type) { case nil: </ins> body = data <ins> case http2.StreamError: // This is trying to catch the scenario that the server may close the connection when sending the // response body. This can be caused by server timeout due to a slow network connection. // TODO: Add test for this. Steps may be: // 1. client-go (or kubectl) sends a GET request. // 2. Apiserver sends back the headers and then part of the body // 3. Apiserver closes connection. // 4. client-go should catch this and return an error. glog.V(2).Infof("Stream error %#v when reading response body, may be caused by closed connection.", err) streamErr := fmt.Errorf("Stream error %#v when reading response body, may be caused by closed connection. Please retry.", err) return Result{ err: streamErr, } default: glog.Errorf("Unexpected error when reading response body: %#v", err) unexpectedErr := fmt.Errorf("Unexpected error %#v when reading response body. Please retry.", err) return Result{ err: unexpectedErr, } </ins> } }

Discussion:
While this issue happens without this complicated reproduction, here is a sure-fire way to get it. a long-running kubectl get. In this example, I have a cluster with about 2,000 configmaps each around 100KiB. Once you see these lines Press , then type , and then you'll see... What's happening is that the apiserver is hitting , and then it . As the code says, this should make it obvious to the client (kubectl) that it didn't get the entire body, because no 0-length EOF chunk gets sent. I can confirm from using tcpdump that no such chunk gets sent. However, kubectl doesn't notice this, and instead tries to decode a 0-length Response body, giving the cryptic message. What I expected to happen the very least, a less cryptic error message like "connected closed". , this gets detected by the code and we can internally retry, just as if we got, e.g.,
cc Possibly seen here, too: openshift/origin
/assign mengqiy
Created a PR to detect it. Further improvement may be retrying when detect connection closure
closing this since you filed a PR for it
Change:
return "", errors.Wrap(err, "invalid format to parse for proxy") } if len(proxyIP) == 0 { <del> break </del> <ins> continue </ins> } pStanza := map[string]interface{}{}

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: The following unit test case is flakey What you expected to happen: Testcase should pass. How to reproduce it (as minimally and precisely as possible): Run the testcase for 20 times, you will see failures couple of times. Test failure history: https://k8s-
/sig cluster-lifecycle
/assign
This is happening because in when there is empty proxyIP we are not continuing the pool instead we are breaking which will exit from the loop and ignore the next element in the dictionary of stubDomainData dictionary where there is not guaranty of execution. To fix this issue should be replaced with continue
Change:
oldJobSchedule: "30 * * * *", newJobSchedule: "*/1 * * * *", }, <del> deltaTimeForQueue:    1*time.Second + nextScheduleDelta, roundOffTimeDuration: 750 * time.Millisecond, </del> <ins> deltaTimeForQueue: 1*time.Second + nextScheduleDelta, </ins> }, // TODO: Add more test cases for updating scheduling. }

Discussion:
pull-kubernetes-unit TestController2updateCronJob/spec.schedulechanged TestController2_updateCronJob /sig apps /assign
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
This is important to resolve before promotion to v1
looks like the cause was
This function should be related.
Another one:
When the flake happen, there are messages like When the system is overloaded, it would happen. is trying to replace the current queue in tests with a mock.
Yeah, I spoke with to make sure we use a mock of the queue so we only get the most important bit of information ignoring the remaining parts