jiebi/CodeConvo huggingface dataset:
Code change:
if !ignoreChangesAndAdditions { // Add any remaining items found only in modified for ; modifiedIndex < len(modifiedSorted); modifiedIndex++ { <del> patch = append(patch, modified[modifiedIndex]) </del> <ins> patch = append(patch, modifiedSorted[modifiedIndex]) </ins> } }

Related discussion:
text: Can you provide yaml using standard public image along with the specific symptoms you are seeing?
did you create the deployment first with out the env vars, then add them via an apply?
Thanks for looking into it I managed to reproduce it with the yaml you posted. Here's what I did: the yaml you provided as '' the "SLACKENDPOINT" env var from that file and saved that as "" (no other changes) This creates the deployment with all env vars as expected This re-creates a new set of pods and they don't have the SLACKENDPOINT var, as expected. This does not re-create the pods, so the env var is not passed along. kubectl does not return errors.
cc cc
Thanks, I was able to reproduce the issue. It looks like the config with the ENV does get stored in the last-applied-configurations annotation: But does not get put into the pods:
After a few tries I found that if you add the env as the last one you'll be able to add it. Definitely a bug.
The generated three way merge patch wasn't correct (the annotation is good, but look at the spec part): "spec":{"template":{"spec":{"containers":[{"env":[{"name":"CASSANDRALOGGING_LEVEL","value":"ERROR"}],"name":"test-api"}]}}}}
It only recognizes the last env as diff
Opened a PR ptal.
Thanks everyone.
Code change:
} } } <ins> func TestGetWindowsPath(t *testing.T) { tests := []struct { path         string expectedPath string }{ { path:         `/var/lib/kubelet/pods/146f8428-83e7-11e7-8dd4-000d3a31dac4/volumes/kubernetes.io~disk`, expectedPath: `c:varlibkubeletpods146f8428-83e7-11e7-8dd4-000d3a31dac4volumeskubernetes.io~disk`, }, { path:         `var/lib/kubelet/pods/146f8428-83e7-11e7-8dd4-000d3a31dac4volumeskubernetes.io~disk`, expectedPath: `c:varlibkubeletpods146f8428-83e7-11e7-8dd4-000d3a31dac4volumeskubernetes.io~disk`, }, { path:         `/`, expectedPath: `c:`, }, { path:         ``, expectedPath: ``, }, } for _, test := range tests { result := GetWindowsPath(test.path) if result != test.expectedPath { t.Errorf("GetWindowsPath(%v) returned (%v), want (%v)", test.path, result, test.expectedPath) } } } </ins>

Related discussion:
text: <!-- 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?: /kind bug What happened: I have tried FlexVolume on a Windows node, it does not work. I am now working on this feature now. Below is the FlexVolume initialization error 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 ): v1.7.7 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig windows /assign
Detailed steps about how to use flexvolume on Windows with this PR:
cc:
Code change:
c = f.ClientSet ns = f.Namespace.Name systemPods, err := e2epod.GetPodsInNamespace(c, ns, map[string]string{}) <del> framework.ExpectEqual(err, nil) </del> <ins> framework.ExpectNoError(err) </ins> systemPodsNo = int32(len(systemPods)) if strings.Index(framework.TestContext.CloudConfig.NodeInstanceGroup, ",") >= 0 { framework.Failf("Test dose not support cluster setup with more than one MIG: %s", framework.TestContext.CloudConfig.NodeInstanceGroup)

Related discussion:
text: <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: kubernetes/node-problem-detector/node-problem-detector-ci: ci-npd-e2e-node See the Which test(s) are failing: [] NodeProblemDetector [NodeFeature:NodeProblemDetector] [] SystemLogMonitor should generate node condition and events for corresponding errors Since when has it been failing: Dec 03. was at 19:50 PST, was at 21:51 PST. Testgrid link: https://k8s- Reason for failure: Apparently is the culprit. Anything else we need to know: This is likely caused by some library upgrade. Nothing big.
/sig node
/assign
Seems like the failure is caused by . /cc /cc /cc /cc
/priority critical-urgent
The particular bug I care about has been fixed in . I'm gonna still work on submitting , as the same error should also be affecting a few other tests.
Code change:
podResources, err := getNodeDevices() var resourcesForOurPod *kubeletpodresourcesv1alpha1.PodResources framework.Logf("pod resources %v", podResources) <del> gomega.Expect(err).To(gomega.BeNil()) </del> <ins> framework.ExpectNoError(err) </ins> framework.ExpectEqual(len(podResources.PodResources), 2) for _, res := range podResources.GetPodResources() { if res.Name == pod1.Name {

Related discussion:
text: <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: kubernetes/node-problem-detector/node-problem-detector-ci: ci-npd-e2e-node See the Which test(s) are failing: [] NodeProblemDetector [NodeFeature:NodeProblemDetector] [] SystemLogMonitor should generate node condition and events for corresponding errors Since when has it been failing: Dec 03. was at 19:50 PST, was at 21:51 PST. Testgrid link: https://k8s- Reason for failure: Apparently is the culprit. Anything else we need to know: This is likely caused by some library upgrade. Nothing big.
/sig node
/assign
Seems like the failure is caused by . /cc /cc /cc /cc
/priority critical-urgent
The particular bug I care about has been fixed in . I'm gonna still work on submitting , as the same error should also be affecting a few other tests.
Code change:
return nil, scoreStatus.AsError() } <ins> if klog.V(10).Enabled() { for plugin, nodeScoreList := range scoresMap { for _, nodeScore := range nodeScoreList { klog.InfoS("Plugin scored node for pod", "pod", klog.KObj(pod), "plugin", plugin, "node", nodeScore.Name, "score", nodeScore.Score) } } } </ins> // Summarize all scores. result := make(framework.NodeScoreList, 0, len(nodes)) for i := range nodes { result = append(result, framework.NodeScore{Name: nodes[i].Name, Score: 0}) for j := range scoresMap {

Related discussion:
text: Scheduler throughput drops significantly in http://perf- ! After , seems to be the curlspirit.
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
/priority critical-urgent /sig scheduling /sig scalability
Code change:
kl.statusManager.SetPodStatus(pod, v1.PodStatus{ Phase:   v1.PodFailed, Reason:  reason, <del> Message: "Pod " + message}) </del> <ins> Message: "Pod was rejected: " + message}) </ins> } // canAdmitPod determines if a pod can be admitted, and gives a reason if it

Related discussion:
text: When a Pod admission fails due to node-pressure condition then the Pod's looks like this: "Pod The node had condition: [DiskPressure]." The "Pod The node..." reads awkward. A message like: "The node had condition: [DiskPressure].". a job with a pod on a single node cluster, when the node is under disk pressure (then it is tainted with ). The Pod gets stuck in the phase. the node by kubectl command line: Pod is scheduled but admission by Kubelet fails as the taint is re- shortly after its manual removal. Then, the status of the Pod contains the awkward message. No response <details</details<detailsReproducible on kind </details<details</details<details</details<details</details<details</details
/sig node /triage accepted /priority backlog
The first part () is returned here: . I wonder where the is being appended to the beginning. It's my first try to contribute, so I am a little bit lost.
I think this is a candidate place which might be responsible for the prefix (but haven't checked): I would suggest you to try to reproduce the issue locally first then experiment with modifying the code.
/assign
thanks, I've managed to reproduce and used Delve to make sure who's responsible. I opened the changing the message. If it's accepted it will change to .
Code change:
} apiResource := unversioned.APIResource{Name: gvr.Resource, Namespaced: true} <del> err := dynamicClient.Resource(&apiResource, namespace).DeleteCollection(nil, &v1.ListOptions{}) </del> <ins> // namespace controller does not want the garbage collector to insert the orphan finalizer since it calls // resource deletions generically.  it will ensure all resources in the namespace are purged prior to releasing // namespace itself. orphanDependents := false err := dynamicClient.Resource(&apiResource, namespace).DeleteCollection(&v1.DeleteOptions{OrphanDependents: &orphanDependents}, &v1.ListOptions{}) </ins> if err == nil { return true, nil

Related discussion:
text: Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): "LRUExpireCache" Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT What happened: requires write lock since needs to manipulate its list to track recently used item. Currently it uses read lock so it may introduce race condition. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else do we need to know:
This was fixed in
Code change:
"fmt" "os" "path" <ins> "strings" </ins> "github.com/golang/glog" "k8s.io/kubernetes/pkg/api/resource"

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.5", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-10-29T01:38:40Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.5", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-10-29T01:32:42Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: vSphere OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: None Others: None What happened: When I create a deployment with vSphere cloud provider dynamic provisioning, it creates a volume spec with volume path - [datastore] kubevols/volume which contains a white space in it. In this case the cloud provider queries the getDeviceNameFromMount() to return the path of the volume mounted. Since getDeviceNameFromMount() queries the filesystem to get the mount references, it returns a volume path "[datastore]040kubevols/volume". Later the kubelet searches for this volume path in both the actual and desired states. Th actual and desired states contains volume with path "[datastore] kubevols/volume". So, it couldn't find such volume path and therefore kubernetes stalls unable to make any progress further similar to one described in .
Code change:
"fmt" "os" "path" <ins> "strings" </ins> "github.com/golang/glog" "k8s.io/kubernetes/pkg/api/resource"

Related discussion:
text: Also similar issue described in What you expected to happen: All the pods in the recreated deployment comes up. How to reproduce it (as minimally and precisely as possible): See above. Anything else do we need to know: None
cc
Code change:
"fmt" "os" "path" <ins> "strings" </ins> "github.com/golang/glog" "k8s.io/kubernetes/pkg/api/resource"

Related discussion:
text: I tried to create a kubernetes deployment with vSphere volume with volume path "[datastore] kubevols/redis-master". In this case the cloud provider queries the getDeviceNameFromMount() to return the path of the volume mounted. Since getDeviceNameFromMount() queries the filesystem to get the mount references, it returns a volume path "[datastore]040kubevols/redis-master". Later the kubelet searches for this volume path in both the actual and desired states. Th actual and desired states contains volume with path "[datastore] kubevols/redis-master". So, it couldn't find such volume path and therefore kubernetes stalls unable to make any progress further similar to one described in . However, when I create a kubernetes deployment with volume path - "[datastore]kubevols/redis-master" which doesn't contain any spaces, it works perfectly fine. So, the basic problem is to format and return the correct volume path from getDeviceNameFromMount() function. Alternatively, we can format it properly in the cloud provider code but this has to be done individually in all the cloud provider code base. Inorder to prevent it, it would be better to fix the getDeviceNameFromMount() function to return the correct formatted volume path.
CC Kubernetes should handle volumes with spaces (looks like vsphere is the first such volume) gracefully. Non a blocker issue for 1.5.
you should make sure that the 1.5 release notes capture that "vsphere volumes w/spaces have problems". Known issue accumulator in
getDeviceNameFromMount is function which queries /proc/mount to get mount points. 040 - is an escape sequence. 040 is the ascii code, in octal(base 8) number system, of the space. The mount command interprets 040 as literal space in the mount point. : Can't we provide a fix for this in 1.5 release itself? There a 2 options: can provide a fix in getDeviceNameFromMount. can provide a fix to vSphere cloud provider to fix it after the call to getDeviceNameFromMount. For option 1, we have to make sure it works for all cloud providers where as for option 2 its not needed. Let me know which option you think is feasible. I am ok with anything.
Code change:
"fmt" "os" "path" <ins> "strings" </ins> "github.com/golang/glog" "k8s.io/kubernetes/pkg/api/resource"

Related discussion:
text: 1 is the right answer. But we're very close to 1.5.0 release (<1 week). I'd also like whoever addresses this to ensure the entire system works end-to-end for volumes with spaces, not just patch one little corner. I'm afraid it would be a large change and we're not going to have enough time to validate it in 1.5. You can certainly start working on it. If you get a PR in time, we can consider it for 1.5.0. Otherwise it'll have to go in a patch release.
Code change:
import ( dockertypes "github.com/docker/engine-api/types" <ins> dockercontainer "github.com/docker/engine-api/types/container" </ins> "k8s.io/kubernetes/pkg/api/v1" ) <ins> // These two functions are OS specific (for now at least) func updateHostConfig(config *dockercontainer.HostConfig) { // no-op, there is a windows implementation that is different. } func DefaultMemorySwap() int64 { return -1 } </ins> func getContainerIP(container *dockertypes.ContainerJSON) string { result := "" if container.NetworkSettings != nil {

Related discussion:
text: What happened: Latest kubelet + Windows Docker version 1.14.0-dev refused to start any containers, error output: "invalid option: Windows does not support MemorySwap" How to reproduce it (as minimally and precisely as possible): It's always reproducible with Windows Docker 1.14.0-dev + latest kubelet code base. Anything else do we need to know: It didn't happen for Windows Docker 1.12.2-cs2-ws-beta. The reason behind the issue was because new code was for Windows Docker to check Resources parameters, it doesn't accept a non-zero value for MemorySwap: But kubelet was default to set an unlimited (-1) value. The issue was gone in my setup after applied a private fix to disable MemorySwap by set it to zero for Windows.
Code change:
"strconv" "time" <ins> apierrors "k8s.io/apimachinery/pkg/api/errors" </ins> "k8s.io/apimachinery/pkg/fields" "github.com/onsi/ginkgo"

Related discussion:
text: Flaked a couple of times on serial lane with the same error. Test is relatively new. This run only has the single test flake: /sig node /kind flake /cc
/assign
New recent failures: /triage accepted
Code change:
- --container=heapster - --poll-period=300000 - --estimator=exponential <del> - image: gcr.io/google_containers/addon-resizer:1.5 </del> <ins> - image: gcr.io/google_containers/addon-resizer:1.6 </ins> name: eventer-nanny resources: limits:

Related discussion:
text: HPA tests are currently failing in gke-large cluster suite: I did some debugging and the problem seems to be related to pod-nanny. Looking into logs from the last run: was first scheduled on the large node dedicated to it pod-nany updated heapster deployment then heapster was scheduled on the normal node (when it actually shouldn't fit) that point it was never updated by the pod nanny. that point, heapster started crashlooping (OOMing) [which in fact was expected in too small machine] So it's pretty clear that that pod-nanny changed the amount of resources to something smaller, which in fact it shouldn't.
Code change:
return err } <del> count := 0 err = r.Visit(func(info *resource.Info, err error) error { </del> <ins> singular := false infos, err := r.IntoSingular(&singular).Infos() if err != nil { return err } if len(infos) == 0 { return fmt.Errorf("no objects passed to convert") } objects, err := resource.AsVersionedObject(infos, !singular, o.outputVersion, o.encoder) if err != nil { return err } if meta.IsListType(objects) { _, items, err := cmdutil.FilterResourceList(objects, nil, nil) </ins> if err != nil { return err } <del> infos := []*resource.Info{info} objects, err := resource.AsVersionedObject(infos, false, o.outputVersion, o.encoder) </del> <ins> filteredObj, err := cmdutil.ObjectListToVersionedObject(items, o.outputVersion) </ins> if err != nil { return err } <del> count++ return o.printer.PrintObj(objects, o.out) }) if err != nil { return err </del> <ins> return o.printer.PrintObj(filteredObj, o.out) </ins> } <del> if count == 0 { return fmt.Errorf("no objects passed to convert") } return nil </del> <ins> return o.printer.PrintObj(objects, o.out) </ins> }

Related discussion:
text: BUG REPORT When using with multiple files (like when referencing a directory in ), the json or yaml output is not a valid list format, and when fed to just the first file gets created. Kubernetes version (use ): latest master What happened: only the first file in directory gets created. What you expected to happen: all files in directory must be created. How to reproduce it (as minimally and precisely as possible):
Code change:
parameters[k] = v.(string) } } <ins> if snapshotProvider, ok := snapshotClass.Object["driver"]; ok { snapshotter = snapshotProvider.(string) } </ins> case d.SnapshotClass.FromFile != "": snapshotClass, err := loadSnapshotClass(d.SnapshotClass.FromFile) framework.ExpectNoError(err, "load snapshot class from %s", d.SnapshotClass.FromFile)

Related discussion:
text: <!-- 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: On running kubetest with external storage driver option with driver name "", encountered error of flag redefinition. The issue happens because: As part of this patch , a flag is defined for number of inline volumes. The driver name is used to construct the flag name. Thus, when running tests on an externally provided driver (in this instance the Persistent Disk CSI driver) with driver name "", a redefinition error happens since the ephemeral test suite code path is executed once for and once for External PD CSI driver. [example run command: kubetest --test --check-version-skew=false --testargs="-- --storage.testdriver=/path/to/gcp-compute-persistent-disk-csi-driver/test/k8s-integration/config/test-" Test config looks something like this: { StorageClass: FromFile: ... SnapshotClass: FromFile: ... DriverInfo: Name: ... } ] What you expected to happen: Test should run and succeed. How to reproduce it (as minimally and precisely as possible): Use an test-, with driver name as "", and run kubetest with focus as "External.Storage" kubetest --test --check-version-skew=false --testargs="-- --storage.testdriver=/path/to/gcp-compute-persistent-disk-csi-driver/test/k8s-integration/config/test-" Anything else we need to know?: Possible fixes options: , (), when using a FromFile or FromExistingClassName option to pass in SnapshotClass information, pickup the provisioner name from the class definition's "driver" field. the flag which has a dependency on driver names. (need to understand the impact of removing the command line flag) Environment: Kubernetes version (use ): latest master 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:
/sig storage
/assign Do you know why this parameter is set as a flag and not a part of the ?
To me, is something that defines what the driver can do. This flag is about what the test does and not related to driver capabilities.
Code change:
parameters[k] = v.(string) } } <ins> if snapshotProvider, ok := snapshotClass.Object["driver"]; ok { snapshotter = snapshotProvider.(string) } </ins> case d.SnapshotClass.FromFile != "": snapshotClass, err := loadSnapshotClass(d.SnapshotClass.FromFile) framework.ExpectNoError(err, "load snapshot class from %s", d.SnapshotClass.FromFile)

Related discussion:
text: Making it depend on the driver name was probably unnecessary. A single flag for all incarnations of that test probably would have been sufficient and thus better ("keep it simple, stupid!" - the stupid being me here...). It also shouldn't have used the global flag set. In other words:
/reopen I don't really want to get into the habit of defining per test case flags in There are thousands of test cases and it would be unwieldy to discover all the flags available and understand how to use them. What factors would influence how many volumes you want the test to create? Can we just hardcode a value in the test case?
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The defaults must be usable so that users do not need to understand them. The flags can be discovered with - not ideal, but at least they show up. That's effectively what the default value for the flag does. This is a way to to run a custom stress test: the default is so low, it just tests that the feature works. By increasing it as high as the underlying CSI driver and storage system supports, one can run this (and potentially other tests) as part of stress testing. Not sure whether it's worth supporting this. It seemed worthwhile at the time, and better than hard-coding just one value.
The bigger issue is: how do users of the test suite actually learn what tests they run and what those tests do? I suspect the answer to that is simply "read the source", in which case they'll also find the knobs that can be used to tweak testing.
Since increasing the parameter depends on the csi driver/storage system, then I would recommending splitting this up into 2 test cases: 1) test basic functionality 2) test stress scenario, and add the parameter to the driver test config similarly to other stress tests:
At least for the storage tests, because we are intending that they be run externally, having all the tunables in one place I think makes it easier to discover.
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.