jiebi/CodeConvo huggingface dataset:
Code change:
// CustomResourceDefinitionCondition contains details for the current condition of this pod. message CustomResourceDefinitionCondition { <del> // Type is the type of the condition. </del> <ins> // Type is the type of the condition. Types include Established, NamesAccepted and Terminating. </ins> optional string type = 1; // Status is the status of the condition.

Related discussion:
text: What would you like to be : A comment in that includes the possible values of . I got the possible values from . The should contain the further explanation available in the linked code that explains what each condition type means. Why is this needed: Currently the output of is incomplete: It is important to include the values of because that's the value used to . It is not user-friendly to require users to guess the possible string values for condition or require them to read the code to deduce what the possible values are.
/sig cli
Please let me do it~
oops, I just notice your message. I already submitted a PR for this.
It's ok~
Code change:
for _, rt := range tests { mounts := getHostPathVolumesForTheControlPlane(rt.cfg) <ins> // Avoid unit test errors when the flexvolume is mounted if _, ok := mounts.volumes[kubeadmconstants.KubeControllerManager][flexvolumeDirVolumeName]; ok { delete(mounts.volumes[kubeadmconstants.KubeControllerManager], flexvolumeDirVolumeName) } if _, ok := mounts.volumeMounts[kubeadmconstants.KubeControllerManager][flexvolumeDirVolumeName]; ok { delete(mounts.volumeMounts[kubeadmconstants.KubeControllerManager], flexvolumeDirVolumeName) } </ins> if !reflect.DeepEqual(mounts.volumes, rt.vol) { t.Errorf( "failed getHostPathVolumesForTheControlPlane:ntexpected: %vnt  actual: %v",

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: unit tests failed. What you expected to happen: How to reproduce it (as minimally and precisely as possible): It will get . I found this issue only happened when the is truely existent in the host, Anything else we need to know?: Environment: Kubernetes version (use kubectl version): head Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. uname -a): Install tools: Others: go version go1.9.2 linux/amd64
There are no sig labels on this issue. Please by: 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 and . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/area kubeadm
Code change:
// PatchStatus patches a status of a Node in the fake store. func (m *FakeNodeHandler) PatchStatus(nodeName string, data []byte) (*v1.Node, error) { m.RequestCount++ <del> return &v1.Node{}, nil </del> <ins> return m.Patch(nodeName, types.StrategicMergePatchType, data, "status") </ins> } // Watch watches Nodes in a fake store.

Related discussion:
text: <!-- 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?: /kind bug What happened: In , the controller add NodeNetworkUnavailable to the node conditions, and use to update it. But node status can not be updated by , it doesn't work because replace the node status with old status. To fix this bug, we should use to update node status. /sig cloud-provider /sig cluster-lifecycle /area cloudprovider 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I agree this is a bug. As a matter of interest though, how are you exercising this bug? It seems specific to cloud controller on gce. However that controller isn't actually enabled on gce. It would be good for me to understand your use case, to make sure we don't break it later.
I built my kubernetes cluster with external cloudprovider, but I found if I stop the route controller, pod will be scheduled on node even if the route is not for that node. I read the code and found that the node condition would not be add when using other cloudproviders. At first, I change "gce" in that line code to the name of my cloudprovider, but the problem also exists. Then I found that didn't take effect actually.
Code change:
t.Errorf("expected error to contain '%s', but got: %v", expectErrToContain, err) } } <del> // test with cost budget exceeded errs, _ = celValidator.Validate(ctx, field.NewPath("root"), &s, tt.obj, tt.oldObj, 0) var found bool for _, err := range errs { if err.Type == field.ErrorTypeInvalid && strings.Contains(err.Error(), "validation failed due to running out of cost budget, no further validation rules will be run") { found = true } } if !found { t.Errorf("expect cost limit exceed err but did not find") } if len(errs) > 1 { t.Errorf("expect to return cost budget exceed err once") } </del> }) } })

Related discussion:
text: /kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
The flake started after was merged. /cc I run it locally and it costs about 190s~220s.
/sig api-machinery testing
should fix. Needs approval.
/triage accepted
Code change:
if err = waitForPodUnschedulable(cs, pod); err != nil { t.Errorf("test #%v: Didn't expected the pod to be scheduled. error: %v", i, err) } <del> if unresPlugin.numUnreserveCalled == 0 || unresPlugin.numUnreserveCalled != pbdPlugin.numPrebindCalled { </del> <ins> if unresPlugin.numUnreserveCalled == 0 { </ins> t.Errorf("test #%v: Expected the unreserve plugin to be called %d times, was called %d times.", i, pbdPlugin.numPrebindCalled, unresPlugin.numUnreserveCalled) } } else {

Related discussion:
text: <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: pull-kubernetes-integration Which test(s) are failing: TestUnreservePlugin Since when has it been failing: It happens frequently this week Testgrid link: Reason for failure: I0619 11:55:31. ] PUT /api/v1/namespaces/default/endpoints/kubernetes: (2.062872ms) 200 [ (linux/amd64) kubernetes/$Format 127.0.0.1:] test : Expected the unreserve plugin to be called 2 times, was called 1 times. Anything else we need to know:
This seems to be a issue in scheduler integration tests /sig scheduling
I was analyzing that failure based on the logs from given link. Based on my analysis the problem lies in here We wait for the pod to being unschedulable, and then we compare the counts of pre-bind and unreserve called. But this is done asynchronously so it can happen that between and us reading the counts the pod has already been scheduled and pre-bind was called while unreserve was not yet called. A simple solution would be to assert instead of I'll try to submit PR with that fix to see what people think about that :)
FYI: /assign /kind flake
cc/
/close
Code change:
import ( "fmt" <del> "strings" </del> "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema"

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: MarshalToYamlForCodecs adds an indent to the yaml output. This code can be combined with PrintBytesWithLinePrefix 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/assign rpothier
/sig cluster-lifecycle
/priority important-soon
Code change:
nodeRef := &v1.ObjectReference{Kind: "Node", Name: "test", UID: types.UID("test"), Namespace: ""} manager, _ := NewManager(fakeRecorder, nodeRef, activePodsFunc, killPodsFunc, syncNodeStatus, shutdownGracePeriodRequested, shutdownGracePeriodCriticalPods) err := manager.Start() <ins> lock.Unlock() </ins> if err != nil { t.Errorf("unexpected error: %v", err) }

Related discussion:
text: /kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
/sig node
I find the reason for it, but I don't know the solution is suitable, correct me if not.
/triage accepted /assign
Code change:
# Note that this does not guarantee admission on the nodes (#40573). annotations: scheduler.alpha.kubernetes.io/critical-pod: '' <ins> scheduler.alpha.kubernetes.io/tolerations: '[{"key": "node.alpha.kubernetes.io/ismaster", "effect": "NoSchedule"}]' </ins> spec: containers: - name: fluentd-gcp

Related discussion:
text: Problem showed, that despite e2e tests for container's logs, we still can encounter regressions for system logs. We need to establish an e2e test for ingesting system components's logs: kubelet docker CC
broke ingesting logs from master and we didn't notice it at once Test should check that logs are present from all nodes, including master (when possible)
Moving to 1.7 as late to happen in 1.6. Feel free to switch back if this is incorrect.
/sig instrumentation do you want this in v1.7? (since you're listed as sig-instrumentation leads at and I can't find a team to ping)
No, thanks for noticing!
Fixed by
Code change:
# Extra docker options for nodes. EXTRA_DOCKER_OPTS="${EXTRA_DOCKER_OPTS:-}" <ins> # Enable the docker debug mode. EXTRA_DOCKER_OPTS="${EXTRA_DOCKER_OPTS} --debug" </ins> SERVICE_CLUSTER_IP_RANGE="10.0.0.0/16"  # formerly PORTAL_NET # When set to true, Docker Cache is enabled by default as part of the cluster bring up.

Related discussion:
text: We seemed to have curbed the kubelet memory issues in , but the runtime issues remain. https://k8s- has a lot of these. This can likely be de-duped to an auto-filed issue when the soak tests are to the munger.
I created a cluster and ran a scrip to repeatedly create/delete pods overnight, but couldn't reproduce this issue. Uploaded PR to enable the debug mode in docker, so that one can run pprof to get more useful information from the soak cluster.
I redeployed the GCE soak tests yesterday to pick up to help you debug faster. I verified that docker is running with this flag on the nodes. So as soon as it re-occurs on https://k8s- , you should be able to debug it. Just out of curiosity, what sort of debugging does that flag enable?
I know it at least enables the /debug/pprof endpoint. EDIT: and thanks for deploying a new cluster.
The new cluster started failing again: Some information I gathered: The goroutines: Will check later(?) to see if the memory uasge keeps increasing
The heap profile shows that is slowly accumulating more memory. This can be reproduced by repeatedly creating and deleting containers for thousands of times using docker v1.11 (without kubernetes involved at all). A potentially related issue is found on I didn't try it on docker v1.12 and am not sure if it suffers from the same symptom. I was able to also reproduce this through unit tests in the package. On such unit test is I modified the test to use UUIDs as keys and change the order to always insert a key and then delete right away. After running the test for 10 million iterations, the test always fails with an increase of memory usage on the heap. I filed an issue to see if the unit test failure is related, or just a red herring:
Is this p0 flake a symptom of this issue?
In , both kubelet and runtime exceed the memory limit. This issue is for the "runtime" memory issue, but not for kubelet. The kubelet memory issue seems to be relatively new. I'll look into that as well.
Update: There is a fix posted in W can't patch docker 1.11 anyway, so the soak test will continue failing.
Code change:
# Extra docker options for nodes. EXTRA_DOCKER_OPTS="${EXTRA_DOCKER_OPTS:-}" <ins> # Enable the docker debug mode. EXTRA_DOCKER_OPTS="${EXTRA_DOCKER_OPTS} --debug" </ins> SERVICE_CLUSTER_IP_RANGE="10.0.0.0/16"  # formerly PORTAL_NET # When set to true, Docker Cache is enabled by default as part of the cluster bring up.

Related discussion:
text: this is the docker memory leak I mentioned yesterday.
I though this was a slow leak that only shows up in soak but apparently integration tests are hitting it too: , or is that something else, or just a confusing error message?
fwiw the logs from this failure are https://k8s-, I haven't trawled through them yet.
Looks to me like the go runtime was out of memory when building/running testmain Not sure how this is related to docker
[FLAKE-PING] This flaky-test issue would love to have more attention...
[FLAKE-PING] This flaky-test issue would love to have more attention...
This is still an issue, and would like to get this passing in the kubernetes-soak-continuous-e2e-gce-1.4 test suite for the release. I know we talked about patching docker at least for the GCE images. Is that still an option? If not, could you sync up with about how to proceed? Thanks.
Patching docker for today's GCE images is not an option. I am considering patching docker in GCI image though. cc/
It's already patched in GCI.
given that patching docker in the containervm image is not an option, the only way to pass this test is to disable checking the docker memory usage completely in the test. I'll let determine what's the best course for the release.
Here are the plan I wrote in bot auto-filed flake issue: , : was merged to stop the bleeding. I will leave this open for rest work.
These tests are now also failing in case of kubernetes-e2e-gce-gci-serial-release-1.4.
thanks for checking the last failure. Yes, this is known issue, and shouldn't block 1.4 release since GCI default on node is decoupled from the releases.
If it's not a release blocker, do you suggest that we disable the test in the 1.4 branch? cc
Filed to disable the tests for 1.4.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
To help clean up the list of flakes for 1.6, I am closing this issue as it does not appear to flake anymore with the increased limits.
Code change:
return allErrs } <ins> // ValidateEnv validates env vars </ins> func ValidateEnv(vars []api.EnvVar, fldPath *field.Path) field.ErrorList { allErrs := field.ErrorList{}

Related discussion:
text: Scenario: Expected results: pod would not be created as [0] is invalid Actual results: pod is created. Turns out we are not doing any validation of envFrom in container spec today.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
I don't know that we can tighten without failing pods.
The validation code exists, but there was no wiring done from validateContainers.
Pods fail on kubelet already. So those pods were not doing much already. We had a BZ on this.
Fail how - fail to even start, or fail to get the input?
Code change:
} func (dc *DisruptionController) removeDb(obj interface{}) { <del> pdb := obj.(*policy.PodDisruptionBudget) </del> <ins> pdb, ok := obj.(*policy.PodDisruptionBudget) if !ok { tombstone, ok := obj.(cache.DeletedFinalStateUnknown) if !ok { klog.Errorf("Couldn't get object from tombstone %+v", obj) return } pdb, ok = tombstone.Obj.(*policy.PodDisruptionBudget) if !ok { klog.Errorf("Tombstone contained object that is not a pdb %+v", obj) return } } </ins> klog.V(4).Infof("remove DB %q", pdb.Name) dc.enqueuePdb(pdb) }

Related discussion:
text: From integration tests:
/assign
Nope - you need something like that:
I was looking at the GetPodFromDeleteAction when I noticed PR opened for this issue. Hence I didn't update my snippet.
Code change:
} // Handle name collisions between different history <del> // TODO: Is it okay to get from dsLister? </del> <ins> // Get the latest DaemonSet from the API server to make sure collision count is only increased when necessary </ins> currDS, getErr := dsc.kubeClient.ExtensionsV1beta1().DaemonSets(ds.Namespace).Get(ds.Name, metav1.GetOptions{}) if getErr != nil { return nil, getErr } <ins> // If the collision count used to compute hash was in fact stale, there's no need to bump collision count; retry again if !reflect.DeepEqual(currDS.Status.CollisionCount, ds.Status.CollisionCount) { return nil, fmt.Errorf("found a stale collision count (%d, expected %d) of DaemonSet %q while processing; will retry until it is updated", ds.Status.CollisionCount, currDS.Status.CollisionCount, ds.Name) } </ins> if currDS.Status.CollisionCount == nil { currDS.Status.CollisionCount = new(int32) }

Related discussion:
text: https://k8s- /sig apps /priority critical-urgent /assign PR that the test: /cc
GitHub didn't allow me to assign the following users: mortent. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : https://k8s- /priority critical-urgent /assign /cc 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
/kind flake
I'm looking into this.
The test is still flaky, but with different symptom: An example flake: https://k8s- It's likely because the collision count was updated in a previous sync loop, but the in the cache store hasn't been updated and we used a stale collision count while calculating the new hash: /assign
Code change:
t.Fatalf("unexpected error: %v", err) } if !reflect.DeepEqual(testCase.Limiter, client.rateLimiter) { <del> t.Fatalf("unexpected rate limiter: %#v", client.rateLimiter) </del> <ins> t.Fatalf("unexpected rate limiter: %#v, expected %#v at %s", client.rateLimiter, testCase.Limiter, testCase.Name) </ins> } }) }

Related discussion:
text: Reading TestRESTClientLimiter in I noticed a few things. test case struct is defined to have a name field, and its value is used in naming the subtests, but the actual test cases leave the name blank. error statements do not identify which case is failing (do not identify the expected value). Should be clear from the above. Read the code. No response_ <detailsbranch </details<detailsN/A </details<detailsN/A </details<details</details<details</details<details</details
/sig api-machinery
/assign
/triage accepted
Code change:
set -o nounset set -o pipefail <del> KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. source "${KUBE_ROOT}/hack/lib/init.sh" </del> <ins> KUBE_HACK_ROOT=$(dirname "${BASH_SOURCE}") </ins> <del> kube::golang::setup_env </del> <ins> echo "WARNING: hack/generate-docs.sh is an alias for hack/update-generated-docs.sh" echo "and will be removed in a future version." </ins> <del> BINS=( cmd/gendocs cmd/genkubedocs cmd/genman cmd/genyaml ) make -C "${KUBE_ROOT}" WHAT="${BINS[*]}" kube::util::ensure-temp-dir kube::util::gen-docs "${KUBE_TEMP}" # remove all of the old docs kube::util::remove-gen-docs # copy fresh docs into the repo. # the shopt is so that we get docs/.generated_docs from the glob. shopt -s dotglob cp -af "${KUBE_TEMP}"/* "${KUBE_ROOT}" shopt -u dotglob </del> <ins> "${KUBE_HACK_ROOT}"/update-generated-docs.sh </ins>

Related discussion:
text: Instead, have a presubmit test that verifies that the docs can be generated. This will reduce the number of conflicts & rebases, therefore increase speed through the queue. Confirmed with that nothing depends on these docs at the moment. fyi, some manual process might have to change once this is in.
Yes, we want to generate the docs into , anyway. cc
Excellent. One closer step to YAML generation, I hope. :)
was interested in working on this.
Want to get started on this?
is this still a goal of ours?
I've seen a thread this week-end about that. I think docs have moved but we still need to generate them there.
can this issue be closed then?
related to ?
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. Prevent issues from auto-closing with an comment. 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 /lifecycle frozen There's still cruft in the docs directory.
/remove-help I don't think this meets . Please add back via if I'm incorrect
/sig docs /sig release /remove-area test-infra /area build-release /area kubeadm /area kubectl All of the following dirs/files have the following content. Do we need them? This file is autogenerated, but we've stopped checking such files into the repository to reduce the need for rebases. Please run hack/generate- to populate this file. docs/admin: .md files for kube components and kubeadm commands man/man1: .1 files for same user-guide/kubectl: .md files for kubectl commands yaml/kubectl: .yaml files for kubectl commands
/help Now that we have /good-first-issue, I think this does meet the criteria for help wanted. Probably need to talk to someone from sig-docs and figure out if/how these are used.
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command.
Code change:
set -o nounset set -o pipefail <del> KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. source "${KUBE_ROOT}/hack/lib/init.sh" </del> <ins> KUBE_HACK_ROOT=$(dirname "${BASH_SOURCE}") </ins> <del> kube::golang::setup_env </del> <ins> echo "WARNING: hack/generate-docs.sh is an alias for hack/update-generated-docs.sh" echo "and will be removed in a future version." </ins> <del> BINS=( cmd/gendocs cmd/genkubedocs cmd/genman cmd/genyaml ) make -C "${KUBE_ROOT}" WHAT="${BINS[*]}" kube::util::ensure-temp-dir kube::util::gen-docs "${KUBE_TEMP}" # remove all of the old docs kube::util::remove-gen-docs # copy fresh docs into the repo. # the shopt is so that we get docs/.generated_docs from the glob. shopt -s dotglob cp -af "${KUBE_TEMP}"/* "${KUBE_ROOT}" shopt -u dotglob </del> <ins> "${KUBE_HACK_ROOT}"/update-generated-docs.sh </ins>

Related discussion:
text: <detailsIn response to : /help Now that we have /good-first-issue, I think this does meet the criteria for help wanted. Probably need to talk to someone from sig-docs and figure out if/how these are used. 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
/remove-priority important-soon /priority important-longterm This hasn't been committed to for any release cycle in a while. I hope someone does commit to it, but I personally cannot, so I'm bumping down to the "hopefully next time" priority. /kind cleanup in addition to docs This impacts merge velocity of any kubectl/kubeadm changes because the docs/OWNERS file is small. We're going to work around by adding OWNERS files for the relevant sigs to the relevant dirs. But if these files don't have to exist in the first place, that'd be even better.
as discovered today this would not work as OWNERS in sub-folders do not solve the problem with the /docs/.generated_docs file which is in the parent folder. i've been looking into a solution to remove the placeholders completely and make verify-docs only consist of kube::util::gen-docs. this will: ensure that godoc errors and such still block presubmits the contributors are not blocked having to commit placeholder files
/lifecycle active
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 /lifecycle active as PR is still in flight.