jiebi/CodeConvo huggingface dataset:
Code change:
{"release/v1.7.0", "https://dl.k8s.io/release", "v1.7.0", true}, {"release/latest-1.7", "https://dl.k8s.io/release", "latest-1.7", true}, // CI builds area, lookup actual builds at ci-cross/*.txt <ins> {"ci/latest", "https://dl.k8s.io/ci", "latest", true}, </ins> {"ci-cross/latest", "https://dl.k8s.io/ci-cross", "latest", true}, <del> {"ci/latest-1.7", "https://dl.k8s.io/ci-cross", "latest-1.7", true}, </del> <ins> {"ci/latest-1.7", "https://dl.k8s.io/ci", "latest-1.7", true}, {"ci-cross/latest-1.7", "https://dl.k8s.io/ci-cross", "latest-1.7", true}, </ins> // unknown label in default (release) area: splitVersion validate only areas. {"unknown-1", "https://dl.k8s.io/release", "unknown-1", true}, // unknown area, not valid input.

Related discussion:
text: https://k8s- /kind bug /sig cluster-lifecycle /milestone v1.10 /priority failing-test cc also cc should this even be in 1.10 blocking dashboard?
/priority critical-urgent (who owns this?)
(also https://k8s-)
Is this actually running now? /cc
It looks like it's failing to up the cluster, I don't remember what the previous status of this job was, I thought all kubeadm 1.10 jobs were running previously...
The reason this failed was the cross CI job was failing to push the images that are used by that job. /cc
/subscribe
the latest cross build for 1.9 is as following We seem to have only one job that does cross builds on master : https://k8s-*build&i=nope&files=&repos=test-infra So the job fails ( for example in )
/status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Code change:
############################ if kube::test::if_supports_resource "${pods}" ; then <del> record_command run_kubectl_all_namespace_tests </del> <ins> if kube::test::if_supports_resource "${nodes}" ; then record_command run_kubectl_all_namespace_tests fi </ins> fi ################

Related discussion:
text: This is wrong, cluster scoped resources should never have a NAMESPACE column. We need to fix and add a test to ensure this doesn't regress.
The presence of the flag is what triggers this.
I would help fix it.
I mean to add a test after modification, but found that current test framework could not support the case: To cover the scene, we need a real NewHumanReadablePrinter in test case, to ensure the output format, and modify the related funcs in FakeFactory to support pass in param withNamespace. I feel this not like behavior of unit test to some extent. The loss may outweighs the gain to have such a big impact on the whole. What's your opinion
[MILESTONENOTIFIER] Milestone Removed Important: This issue was missing the label for more than 7 days. <details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Code change:
} } <ins> // Create PVs for _, pvConfig := range test.pvs { pv := makePV(pvConfig.name, sharedClasses[pvConfig.scMode].Name, pvConfig.preboundPVC, config.ns, pvConfig.node) if _, err := config.client.CoreV1().PersistentVolumes().Create(pv); err != nil { t.Fatalf("Failed to create PersistentVolume %q: %v", pv.Name, err) } } </ins> // Create pod if _, err := config.client.CoreV1().Pods(config.ns).Create(test.pod); err != nil { t.Fatalf("Failed to create Pod %q: %v", test.pod.Name, err)

Related discussion:
text: Add test for "on PVC add", see Test for "on PVC update" is not needed, because it has already been tested in all volume scheduling tests.
/sig
docs:
Code change:
<g> <rect style="fill: #ffffff" x="165.958" y="389.5" width="115" height="54"/> <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="165.958" y="389.5" width="115" height="54"/> <del> <text font-size="12.7998" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="223.458" y="412.4"> </del> <ins> <text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="223.458" y="412.4"> </ins> <tspan x="223.458" y="412.4">authorization</tspan> <tspan x="223.458" y="428.4">authentication</tspan> </text>

Related discussion:
text: Architecture picture: says kubecfg is deprecated. The architecture picture should be updated to show kubectl instead of kubecfg.
ref /cc
Code change:
//   "-c",      - Index 1 //   "exec /usr/local/bin/kube-apiserver " - Index 2 execArgsIndex        = 2 <del> encryptionConfigFlag = "--experimental-encryption-provider-config" </del> <ins> encryptionConfigFlag = "--encryption-provider-config" </ins> ) testCases := []struct {

Related discussion:
text: Ref Ref ref /sig auth /kind feature /milestone v1.11 /priority important-longterm /status approved-for-milestone cc
What's need to be done here? I can think only about renaming to and updating the docs. What else?
What's required to promote encryption at rest with static configs to beta?
an example of promoting flags is here: If there's a feature gate, we're going to want to enable it by default too.
/assign
submitted PRs for that: and
[MILESTONENOTIFIER] Milestone Removed From Issue Important: Code freeze is in effect and only issues with may remain in the v1.11 milestone. <details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Will this make it to Beta in 1.12? From sig-auth on 7/11, it sounded like this was missing a release shepherd. Is anyone owning pushing this forward?
I'll do my best to push this. edit: I did not realize that 1.12 feature freeze is today (or so I heard), I don't think I'll be able to make it :slightlyfrowningface:
Ack - that's what I was wondering (with the feature freeze). Thanks
- Is this making it to the 1.12 ?
The current plan is 1.13
Code change:
m := make(api.PodInfo) for k, v := range r.Status.Info { v.Ready = true <del> v.PodIP = "1.2.3.4" </del> m[k] = v } r.Status.Info = m

Related discussion:
text: Kubelet now only reports ContainerStatus. PodStatus / PodCondition is observed at master side based on a set of ContainerStatus. There is no other way to get PodIP except net container for master side. This is very confusion to the end user, , , ... Now we are finalizing on v1beta3 API, including PodStatus & ContainerStatus. We can make net container completely invisible to the end users by finishing the following steps: 1) Expose network related errors at API level 2) Generate PodStaus directly from Kubelet
3) once PodStatus generated by kubelet, PodIP can be removed from ContainerStatus.
I think reporting PodStatus rather than just container status is most important. How hard is that?
Used to be hard since there are many dependencies when I first report Status back. Now it is totally feasible. I already started to write PRs for this. :-)
One more PR required to close this one.
Code change:
// InstanceType returns the type of the specified instance. func (m *metadata) InstanceType(name types.NodeName) (string, error) { instanceType, err := m.get(metadataTypeInstanceType) <del> if err == nil { </del> <ins> if err != nil { </ins> return "", fmt.Errorf("could not get instance type: %v", err) }

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?: What happened: kubelet throws the exception when --cloud-provider=cloudstack is included: What you expected to happen: There shouldn't be an exception. How to reproduce it (as minimally and precisely as possible): Add the following line to /etc/systemd/system/kubelet.service.d/10- Environment="KUBELETEXTRAARGS=--cloud-provider=cloudstack --cloud-" and also configure the file. Anything else we need to know?: The condition check in the InstanceType() function in is wrong. It currently reads: but the correct code is (condition negated): Environment: Kubernetes version (use ): 1.8 Cloud provider or hardware configuration: cloudstack OS (e.g. from /etc/os-release): Ubuntu 16.04.3 LTS (Xenial Xerus) Kernel (e.g. ): 4.4.0-98-generic Install tools: kubeadm Others: /sig cloudstack
I will have a look
/sig cluster-lifecycle /area cloudprovider
Code change:
ginkgo.By("checking if the expected cpuset was assigned") cpuListString = "1-2" <del> if isHTEnabled() { </del> <ins> if isMultiNUMA() { cpuList = cpuset.MustParse(getCoreSiblingList(0)).ToSlice() if !isHTEnabled() { cset = cpuset.MustParse(fmt.Sprintf("%d,%d", cpuList[1], cpuList[2])) } else { cset = cpuset.MustParse(getCPUSiblingList(int64(cpuList[1]))) } cpuListString = fmt.Sprintf("%s", cset) } else if isHTEnabled() { </ins> cpuListString = "2-3" cpuList = cpuset.MustParse(getCPUSiblingList(0)).ToSlice() if cpuList[1] != 1 {

Related discussion:
text: Which jobs are failing: N/A - AFAICT CI jobs works fine Which test(s) are failing: Since when has it been failing: no historical record on CI Testgrid link: N/A Reason for failure: I believe the tests make too many assumptions around the hardware, and the code is actually OK. to be confirmed. Anything else we need to know:
/sig node /sig testing
also affects the recently topology manager e2e tests. My PR uses a different approach to check resource alignment so is not affected. /cc
I'll work on a PR to fix this issue ASAP
Thanks for opening this issue. We knew about this, just had not opened an issue to track it, so thanks for doing that! Deepthi has been looing at CPU Manager tests, not sure if she has some PR in progress or not. I'll make sure to forward this to her (can find her user id here ....) in case she has something in progress
Code change:
"command": [ "/bin/sh", "-c", <del> "/usr/local/bin/kube-controller-manager {{params}} 1>>/var/log/kube-controller-manager.log 2>&1" </del> <ins> "exec /usr/local/bin/kube-controller-manager {{params}} 1>>/var/log/kube-controller-manager.log 2>&1" </ins> ], {{container_env}} "livenessProbe": {

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When kube-apiserver's livenessProbe suggests that pod is unhealthy, kubelet tries to kill its container with 30 seconds grace period. The container is killed ungracefully with SIGKILL when grace period passes. This happens each time. What you expected to happen: I expected that SIGTERM will be passed to kube-apiserver which will try to gracefully stop before 30 seconds pass (at least in some cases). How to reproduce it (as minimally and precisely as possible): Inject kube-apiserver failure (e.g. ) Watch kubelet logs for container's death You will see that container is killed after 30 seconds each time Anything else we need to know?: I believe the problem is that in kube-apiserver.manifest uses '/bin/sh -c CMD' as a PID1 process which doesn't pass SIGTERM signals to child process. See Environment: Kubernetes version (use ): v1.7.11
/sig node
Looks like without the pipe command will have to be removed which will make the logs hard to track. There is indeed some which makes kube-apiserver run in background and trapping SIGTERM then send a SIGTERM to apiserver's PID.
I think this is the case for all our components, not just kube-apiserver. - FYI
How about using 'exec'-based solution suggested here: In our case it means prepending 'exec': I did changed this in my cluster and the process seems to meet requirements: fd/1 and fd/2 are redirected to /var/log/kube- container is killed instantaneously If everyone is fine with such a solution, I can prepare PR adding 'exec ' in front of all kubernetes/cluster/saltbase/salt/kube-apiserver/*.manifest using '/bin/sh -c CMD' pattern.
Not sure if understand what you mean. Before there was no logs, so /bin/sh -c wasn't needed. -based solution seems to have all required properties. What is your concern about using it?
Umm. just ignore my previous comment. I just tried prepending and it works fine for me.
Code change:
"command": [ "/bin/sh", "-c", <del> "/usr/local/bin/kube-controller-manager {{params}} 1>>/var/log/kube-controller-manager.log 2>&1" </del> <ins> "exec /usr/local/bin/kube-controller-manager {{params}} 1>>/var/log/kube-controller-manager.log 2>&1" </ins> ], {{container_env}} "livenessProbe": {

Related discussion:
text: <!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--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.): 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 ): 3 Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: All of the salt scripts bundled in kubernetes (for example, ) start up the component in a broken way. They use which means the shell will intercept all signals. So these daemons are not gracefully shutdown when the pod is stopped. This causes serious problems since when apiserver is killed abruptly it doesn't seem to close watches correctly. This was observed in for example. What you expected to happen: Running is incorrect. It should run the binary directly. Otherwise, it needs to perform an so the binary correctly replaces the shell script process. How to reproduce it (as minimally and precisely as possible): Run kube-apiserver inside a container with and try to stop it. You can't - eventually docker will force kill it. Anything else we need to know:
It looks like we changed from running the binaries directly to using in (from a few years ago to enable us to capture logs. or may recall why we had to use a shell since they reviewed that PR.
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.
Code change:
"command": [ "/bin/sh", "-c", <del> "/usr/local/bin/kube-controller-manager {{params}} 1>>/var/log/kube-controller-manager.log 2>&1" </del> <ins> "exec /usr/local/bin/kube-controller-manager {{params}} 1>>/var/log/kube-controller-manager.log 2>&1" </ins> ], {{container_env}} "livenessProbe": {

Related discussion:
text: 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
Code change:
pod, err = f.Client.Pods(f.Namespace.Name).Create(pod) Expect(err).To(HaveOccurred()) <ins> By("Ensuring a pod cannot update its resource requirements") // a pod cannot dynamically update its resource requirements. requests = api.ResourceList{} requests[api.ResourceCPU] = resource.MustParse("100m") requests[api.ResourceMemory] = resource.MustParse("100Mi") podToUpdate.Spec.Containers[0].Resources.Requests = requests _, err = f.Client.Pods(f.Namespace.Name).Update(podToUpdate) Expect(err).To(HaveOccurred()) By("Ensuring attempts to update pod resource requirements did not change quota usage") err = waitForResourceQuota(f.Client, f.Namespace.Name, quotaName, usedResources) Expect(err).NotTo(HaveOccurred()) </ins> By("Deleting the pod") err = f.Client.Pods(f.Namespace.Name).Delete(podName, api.NewDeleteOptions(0)) Expect(err).NotTo(HaveOccurred())

Related discussion:
text: The scenario that presented a problem was the following: a) create pods in a namespace that do not make a memory claim b) add a quota that tracks memory c) update one of the pods previously created by reducing its active deadline. Expected result: Since a pod cannot change its resources via update, we should have been allowed to update the pod spec. Actual Result: error since the pod did not make a memory claim, quota rejects the pod.
cc
Code change:
<ins> /* Copyright 2019 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package plugins import ( "fmt" "reflect" "testing" ) func TestIsManagedDisk(t *testing.T) { tests := []struct { options  string expected bool }{ { options:  "testurl/subscriptions/12/resourceGroups/23/providers/Microsoft.Compute/disks/name", expected: true, }, { options:  "test.com", expected: true, }, { options:  "HTTP://test.com", expected: false, }, { options:  "http://test.com/vhds/name", expected: false, }, } for _, test := range tests { result := isManagedDisk(test.options) if !reflect.DeepEqual(result, test.expected) { t.Errorf("input: %q, isManagedDisk result: %t, expected: %t", test.options, result, test.expected) } } } func TestGetDiskName(t *testing.T) { mDiskPathRE := managedDiskPathRE uDiskPathRE := unmanagedDiskPathRE tests := []struct { options   string expected1 string expected2 error }{ { options:   "testurl/subscriptions/12/resourceGroups/23/providers/Microsoft.Compute/disks/name", expected1: "name", expected2: nil, }, { options:   "testurl/subscriptions/23/providers/Microsoft.Compute/disks/name", expected1: "", expected2: fmt.Errorf("could not get disk name from testurl/subscriptions/23/providers/Microsoft.Compute/disks/name, correct format: %s", mDiskPathRE), }, { options:   "http://test.com/vhds/name", expected1: "name", expected2: nil, }, { options:   "http://test.io/name", expected1: "", expected2: fmt.Errorf("could not get disk name from http://test.io/name, correct format: %s", uDiskPathRE), }, } for _, test := range tests { result1, result2 := getDiskName(test.options) if !reflect.DeepEqual(result1, test.expected1) || !reflect.DeepEqual(result2, test.expected2) { t.Errorf("input: %q, getDiskName result1: %q, expected1: %q, result2: %q, expected2: %q", test.options, result1, test.expected1, result2, test.expected2) } } } </ins>

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : Azure is not listed as "migratable" in could refer to Why is this needed:
/sig azure /assign
Code change:
v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/strategicpatch" </ins> "k8s.io/apimachinery/pkg/util/wait" "k8s.io/client-go/informers" coreinformers "k8s.io/client-go/informers/core/v1"

Related discussion:
text: <!-- 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: Which test(s) are flaking: Testgrid link: Reason for failure: Unknown yet. Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated /sig scheduling /help
Can I give it a try?
Sure, feel free to take it. /assign ahmad-diaa /remove-help
I keep trying to get it fail locally by running the following command: but it never does, am I doing something wrong? Is there something else that I should be doing and would be more helpful?
Sometimes the flake is hard to reproduce in local env. You may have to read the error log of the flakes thoroughly to get some clues. BTW: you can also run the test multiple times using the directive:
After looking through the logs I came up with some information that might be useful As far as I understand, the reason for the flake is the of the medium priority pod not being cleared That is because the update request for removing returns the following error: So my current guess is that might be outdated in some cases As I am not really familiar with the logic, I would like to know whether or not those are valid points so that I could dig deeper. What do you think?
If that's the case, you can set here: You can raise a PR and manually try for ~20 times to see you can reproduce the flake.
found another issue tracking this too. it seems it has been flaky for a while.
Sorry, didn't mean to take this one for you. I worked the duplicate issue and submitted a PR. Feel free to review that PR, or submit your own if you have a different solution.
This sometimes happens. But we usually take the first PR unless it's clearly worked by someone. In terms of which style to resolve the Conflict error, I'm asking here:
Sorry, didn't mean to take this one for you. I worked the duplicate issue and submitted a PR. Feel free to review that PR, or submit your own if you have a different solution. No worries, I haven't started implementing yet and your PR seems to be following the correct approach as well according to this:
Code change:
v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/strategicpatch" </ins> "k8s.io/apimachinery/pkg/util/wait" "k8s.io/client-go/informers" coreinformers "k8s.io/client-go/informers/core/v1"

Related discussion:
text: <!-- 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: pull-kubernetes-integration Which test(s) are flaking: TestNominatedNodeCleanUp Testgrid link: Reason for failure: [TODO] Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated
/sig node These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
Code change:
v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/strategicpatch" </ins> "k8s.io/apimachinery/pkg/util/wait" "k8s.io/client-go/informers" coreinformers "k8s.io/client-go/informers/core/v1"

Related discussion:
text: Which jobs are flaking: pull-kubernetes-integration Which test(s) are flaking: TestNominatedNodeCleanUp Testgrid link: Reason for failure: /sig scheduling
/assign
any progress on this one?
I was working on it and tried to find the root cause. I will give my solution within this week
Another one
Still happening cc
/assign
/close dupe
Closing this issue. <detailsIn response to : /close dupe 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