jiebi/CodeConvo huggingface dataset:
Change:
func GetHostname(hostnameOverride string) string { hostname := []byte(hostnameOverride) if string(hostname) == "" { <del> // Note: We use exec here instead of os.Hostname() because we // want the FQDN, and this is the easiest way to get it. fqdn, err := exec.Command("hostname", "-f").Output() </del> <ins> fqdn, err := exec.Command("uname", "-n").Output() </ins> if err != nil { glog.Fatalf("Couldn't determine hostname: %v", err) }

Discussion:
Actually appending fqdn suffix already causes issue for non-resolvable node names based on today: Today when NodeController "registers" nodes in SyncCloud by getting bare instance names () from GCE, and recreating the fqdn and append it to instance names().
Change:
assert.Equal(t, svc.Name, slices[0].Labels[discovery.LabelServiceName]) assert.EqualValues(t, []discovery.EndpointPort{}, slices[0].Ports) assert.EqualValues(t, []discovery.Endpoint{}, slices[0].Endpoints) <ins> expectTrackedResourceVersion(t, r.endpointSliceTracker, &slices[0], "100") </ins> expectMetrics(t, expectedMetrics{desiredSlices: 1, actualSlices: 1, desiredEndpoints: 0, addedPerSync: 0, removedPerSync: 0, numCreated: 1, numUpdated: 0, numDeleted: 0}) }

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: With EndpointSlice feature enabled, after EndpointSliceController creates or updates an EndpointSlice when reconciling a Service, the Service would always be processed one extra time, which is triggered by the EndpointSlice /updated event made by itself during the first processing. What you expected to happen: EndpointSliceController shouldn't reprocess a Service due to the EndpointSlice update made by itself. How to reproduce it (as minimally and precisely as possible): EndpointSlice feature, improve kube-controller-manager log to 5. a nginx deployment a Service backed by the above deployment. kube-controller-manager log: the service will be processed twice in succession. Anything else we need to know?: It's because EndpointSliceController tracks stale resource version after creating/updating an EndpointSlice. Environment: Kubernetes version (use ): v1.18.0-alpha.3 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 network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
fi export IFS=$'n' <ins> # NOTE: when "go list -e ./..." is run within GOPATH, it turns the k8s.io/kubernetes # as the prefix, however if we run it outside it returns the full path of the file # with a leading underscore. We'll need to support both scenarios for all_packages. </ins> all_packages=( <del> $(go list -e ./... | egrep -v "/(third_party|vendor|staging|generated|clientset_generated)" | sed 's/k8s.io/kubernetes///g') </del> <ins> $(go list -e ./... | egrep -v "/(third_party|vendor|staging|generated|clientset_generated)" | sed -e 's|^k8s.io/kubernetes/||' -e "s|^_${KUBE_ROOT}/?||") </ins> ) linted_packages=( $(cat $linted_file)

Discussion:
Looks like it is chopping off the correct Kube prefix, maybe because of bash 4.0isms.
please let me know if the PR works for you!
Change:
labels: k8s-app: kube-dns annotations: <del> seccomp.security.alpha.kubernetes.io/pod: 'docker/default' </del> <ins> seccomp.security.alpha.kubernetes.io/pod: 'runtime/default' </ins> prometheus.io/port: "10054" prometheus.io/scrape: "true" spec:

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Apply security best practices for both kube-dns and core-dns. Low hanging fruit: [x] Run as non-root & disallow privilege escalation [x] Run with the default seccomp profile (i.e. ) [x] ReadOnlyRootFilesystem [x] Avoid unnecessary HostPath volumes [x] (n/a) More advanced: [ ] Reduce dependencies in the base image () [ ] Custom seccomp profile [ ] Custom AppArmor profile [x] Drop unneeded capabilities[x] Run as non-root & disallow privilege escalation [x] Run with the default seccomp profile (i.e. ) [x] ReadOnlyRootFilesystem [x] Avoid unnecessary HostPath volumes [x] (n/a) More advanced: [ ] Reduce dependencies in the base image () [ ] Custom seccomp profile [ ] Custom AppArmor profile [x] Drop unneeded capabilities This is based on the long term issue and implemented by PR . Why is this needed: Our system pods should run using security best practices, both to enhance cluster security and serve as examples of best practices to users.
/sig auth /area security
Change:
"github.com/onsi/ginkgo" "google.golang.org/grpc/codes" <del> appsv1 "k8s.io/api/apps/v1" </del> v1 "k8s.io/api/core/v1" rbacv1 "k8s.io/api/rbac/v1" storagev1 "k8s.io/api/storage/v1"

Discussion:
newer hostpath deployments but removed the csi-external-health-monitor-agent because it seemed to cause overhead without being needed for the tests. We should re-enable it and check whether that really causes tests to fail because of the extra load.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig storage /area test
Change:
// in extensions. These addons are: // - MaxUnavailable during rolling update set to 25% (1 in extensions) // - MaxSurge value during rolling update set to 25% (1 in extensions) <del> // - RevisionHistoryLimit set to 2 (not set in extensions) </del> <ins> // - RevisionHistoryLimit set to 10 (not set in extensions) </ins> // - ProgressDeadlineSeconds set to 600s (not set in extensions) func SetDefaults_Deployment(obj *appsv1beta2.Deployment) { // Default labels and selector to labels from pod template spec.

Discussion:
All controllers that use the field have a default value of 10 for the field, except for , which has a default of 2. We should increase it to 10 for consistency on its default value across controllers. /sig apps
Change:
"context" "fmt" "os" <del> "os/exec" "path" </del> "regexp" "strings" "time" <ins> "github.com/onsi/ginkgo" "github.com/onsi/gomega" appsv1 "k8s.io/api/apps/v1" </ins> v1 "k8s.io/api/core/v1" rbacv1 "k8s.io/api/rbac/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/uuid" clientset "k8s.io/client-go/kubernetes" "k8s.io/kubernetes/test/e2e/framework" <ins> e2epod "k8s.io/kubernetes/test/e2e/framework/pod" </ins> e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper" imageutils "k8s.io/kubernetes/test/utils/image" <del> "github.com/onsi/ginkgo" "github.com/onsi/gomega" </del> ) const (

Discussion:
Cluster api provides a framework to run the e2e tests which uses the conformance image: The gmsa tests use bash to install the webhook: The test will fail when run in the conformance image because of the bash: we should install the component another way run this e2e conformance image with /sig windows fyi <details</details<details</details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Conformance image:
Hi does the "work e2e" test case pass? Deploying GMSA webhook is the same for both "work e2e" and this test case.
no, they both fail due to bash not being present in the conformance image. The gmsa tests themselves pass if I run locally
/sig testing
Change:
// Names should come from the REST response, NOT the files expectRC := "replicationcontroller/" + nameRC + "n" expectSVC := "service/" + nameSVC + "n" <del> expect := expectRC + expectSVC if buf.String() != expect { t.Fatalf("unexpected output: %snexpected: %s", buf.String(), expect) </del> <ins> // Test both possible orders since output is non-deterministic. expectOne := expectRC + expectSVC expectTwo := expectSVC + expectRC if buf.String() != expectOne && buf.String() != expectTwo { t.Fatalf("unexpected output: %snexpected: %s OR %s", buf.String(), expectOne, expectTwo) </ins> } }

Discussion:
kubectl create, delete, etc. can already take a List object. kubectl apply can take the list object when it does creation, but it gives an (ugly) error when it's configuring the objects. Then... expected: Actual:
what's you ?
0-alpha.5
Sounds like a bug. Are you interested in taking a look
sure I will take a look during this weekend.
I think the root cause is , the actually is , in the origin , is not , but after the , this object is nil. Would you like to double check this?
I'll take a look.
if you have make sure about this, please let me know. Thanks :)
Is there any ways we could get this into 1.2? It's actually making our config generation quite painful to have to make a separate file for every object. It looks like got pretty far? would you like to make a PR that we can review?
I don't see how. It could have made 1.2 if a PR had been sent within a few days of the issue being filed.
I unassigned all issues assigned to you. Please only assign issues that are actively being worked on, so that others can know which issues are available to be picked up.
My apologies. If I'm not mistaken, this issue was filed after the code freeze for 1.2. I didn't realize that it was time critical or that it could make the release at that time. However, I should have asked. Sorry for the inconvenience. Thank you. I still plan to address those issues for the next release, as discussed, but will assign each one to myself as I work on it.
I created which fixes this. I'm really hoping we can get this into 1.2 since it's a pretty small, isolated fix but a pretty big bug that is complicating our config generation system. Let me know what else I can do to help.
Thanks for the PR. We're short on reviewer bandwidth at the moment. I assigned it to Clayton for review or delegation.
Change:
return testexec.InitFakeCmd(&c, cmd, args...) } } <ins> func TestNotMountedBehaviorOfUnmount(t *testing.T) { target, err := ioutil.TempDir("", "kubelet-umount") if err != nil { t.Errorf("Cannot create temp dir: %v", err) } defer os.RemoveAll(target) m := Mounter{withSafeNotMountedBehavior: true} if err = m.Unmount(target); err != nil { t.Errorf(`Expect complete Unmount(), but it dose not: %v`, err) } if err = tryUnmount(target, m.withSafeNotMountedBehavior, time.Minute); err != nil { t.Errorf(`Expect complete tryUnmount(), but it does not: %v`, err) } // forceUmount exec "umount -f", so skip this case if user is not root. if os.Getuid() == 0 { if err = forceUmount(target, m.withSafeNotMountedBehavior); err != nil { t.Errorf(`Expect complete forceUnmount(), but it does not: %v`, err) } } } </ins>

Discussion:
A status of Pod mounted NFS PV remain as terminating when a node shutdown and restart. A Pod is completely terminated. Deploy a Pod mounted NFS PV Shutdown the node where the Pod is running Wait for 5 min and the Pod status become Restart the node The Pod status is still and the Pod is never terminated completely <detailsPrepare a NFS Server.(I used ) Deploy a Pod mounted NFS PV like this. Shutdown the node where the Pod is running.(In this case ) And the status of node02 becomes . After 5 min later(by default), the Pod status becomes . (The time a Pod becomes status depends on .) Then, restart the node and the status of node02 becomes . But the Pod status is still and the Pod is never terminated completely. It seems that a faild to delete Pod because of trying to unmount a not mounted directory. Force delete Pod. Delete Pod's directory on the node. </detailsNo response <details</details<detailsnone(on premise) </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig storage
/sig node
It dose not happen using , so it seems to depend on NFS volume plugin.
/assign
I try to build and run kubelet with comment out this logic. Then it seems to get well. related: This change checks the result of instead of the mount point check. However, check logic is not implemented in and (these functions are used in NFS volume plugin), despite it is done in .
/remove-sig node /sig storage
Reopening, fix had to be reverted due to unit tests requiring root permissions ()
I am terribly sorry... Please wait a moment. I'll try to fix it.
no worries, just get to review the rework, making sure the units tests don't require root permissions
Thank you! Fixed in .
Are there any plans to backport this to older Kubernetes versions? This seems like a critical fix.
Change:
pods := getSummaryTestPods(f, numRestarts, pod0, pod1) f.PodClient().CreateBatch(pods) <ins> ginkgo.By("restarting the containers to ensure container metrics are still being gathered after a container is restarted") </ins> gomega.Eventually(func() error { for _, pod := range pods { err := verifyPodRestartCount(f, pod.Name, len(pod.Spec.Containers), numRestarts)

Discussion:
Which jobs are failing: ci-cri-containerd-node-e2e Which test(s) are failing: Summary API [NodeConformance] when querying /stats/summary should report resource usage through the stats api Since when has it been failing: 2020 10-12 09:04 PDT Since Testgrid link: Reason for failure: Capability set incorrectly. CAPNETRAW should be NETRAW. I1013 18:39:19.058] Oct 13 18:10:51.403: INFO: At 2020-10-13 18:09:34 +0000 UTC - event for stats-busybox-0: {kubelet tmp-node-e2e--cos-81--1210-0} Failed: Error: failed to create containerd task: OCI runtime create failed: starting container process caused: unknown capability "CAPCAPNET_RAW": unknown Anything else we need to know: I have no idea where this is documented. It's a best guess.
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
it's a node_e2e test so /sig node
Seems like there's some dispute on who is doing the correct thing.
I would like to have a try.
please see discussion in
Change:
"kubelet_resources_test.go", "kubelet_test.go", "kubelet_volumes_test.go", <ins> "networks_test.go", </ins> "oom_watcher_test.go", "pod_container_deletor_test.go", "pod_workers_test.go",

Discussion:
This is a sub issue for
cc can you please assign this to me? Thanks.
, please create PR directly and cc to Tim for review.
/sig node
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Change:
} factory.Start(wait.NeverStop) <ins> ctx, cancel := context.WithTimeout(context.Background(), TestInformerSyncTimeout) defer cancel() for ty, ok := range factory.WaitForCacheSync(ctx.Done()) { if !ok { t.Fatalf("failed to sync: %#v", ty) } } </ins> host := volumetest.NewFakeVolumeHostWithCSINodeName(t, tmpDir,

Discussion:
Which test(s) are flaking: TestAttacherWithCSIDriver Reason for failure: This is flaking rarely enough that it is not caught by our CI jobs, which currently tolerate up to 2 unit test failures per run (!). With that toleration removed in , this flake has been seen (). Reproducible with the following steps: a test binary for the affected package: the affected test using the tool (setting the timeout to a generous timeout relative to the normal test runtime of .02 seconds): failures are seen, look at the logs to see the details about the error: /sig storage cc
/assign can you help investigate this flake?
I have found the root cause. /assign
filed to address this issue.
Change:
} for _, t := range tests { test := t <del> ginkgo.It(t.name, ginkgo.SpecTimeout(f.Timeouts.PodStart), func(ctx context.Context) { </del> <ins> ginkgo.It(t.name, ginkgo.NodeTimeout(f.Timeouts.PodStart), func(ctx context.Context) { </ins> scName := "mock-csi-storage-capacity-" + f.UniqueName m.init(ctx, testParameters{ registerDriver:  true,

Discussion:
/kind flake /sig storage It seems the timeout is too short or should not apply to the cleanup of the test, since the test is failing because the context is canceled during the timeout
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
See
Change:
func (e *eventBroadcasterImpl) StartEventWatcher(eventHandler func(*v1.Event)) watch.Interface { watcher, err := e.Watch() if err != nil { <ins> // This function traditionally returns no error even though it can fail. // Instead, it logs the error and returns an empty watch. The empty // watch ensures that callers don't crash when calling Stop. </ins> klog.FromContext(e.cancelationCtx).Error(err, "Unable start event watcher (will not retry!)") <ins> return watch.NewEmptyWatch() </ins> } go func() { defer utilruntime.HandleCrash()

Discussion:
tainteviction NA No response
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
The panic is in the event watcher, you have landed several changes recently that are most probably related, can you PTAL? /sig instrumentation
ok, so the problem is this The watcher fails to be created but the goroutine keeps going and tries to get a channel from it /assign
That problem has already been there before the recent changes: When constructing the watch fails, that code needs to return instead of spawning the goroutine. I think this is okay: The indicates that the occurs after the test has completed. Before the recent changes, creating the watch would have succeeded and the test would have permanently leaked the goroutines. In that sense, the recent changes work as intended.
ok, so this just uncovered an existing bug, those are the positive news
I don't know if we'll translate the problem to other layer, as will return a nil , it seems StartEventWatcher has to also return an error?
I'm adding -
Because of , this shouldn't occur in production.
Change:
func TestPriorityQueue_Update(t *testing.T) { q := createAndRunPriorityQueue(newDefaultFramework()) q.Update(nil, &highPriorityPod) <ins> q.lock.RLock() </ins> if _, exists, _ := q.activeQ.Get(newPodInfoNoTimestamp(&highPriorityPod)); !exists { t.Errorf("Expected %v to be added to activeQ.", highPriorityPod.Name) } <ins> q.lock.RUnlock() </ins> if len(q.nominatedPods.nominatedPods) != 0 { t.Errorf("Expected nomindatePods to be empty: %v", q.nominatedPods) } // Update highPriorityPod and add a nominatedNodeName to it. q.Update(&highPriorityPod, &highPriNominatedPod) <ins> q.lock.RLock() </ins> if q.activeQ.Len() != 1 { t.Error("Expected only one item in activeQ.") } <ins> q.lock.RUnlock() </ins> if len(q.nominatedPods.nominatedPods) != 1 { t.Errorf("Expected one item in nomindatePods map: %v", q.nominatedPods) } // Updating an unschedulable pod which is not in any of the two queues, should // add the pod to activeQ. q.Update(&unschedulablePod, &unschedulablePod) <ins> q.lock.RLock() </ins> if _, exists, _ := q.activeQ.Get(newPodInfoNoTimestamp(&unschedulablePod)); !exists { t.Errorf("Expected %v to be added to activeQ.", unschedulablePod.Name) } <ins> q.lock.RUnlock() </ins> // Updating a pod that is already in activeQ, should not change it. q.Update(&unschedulablePod, &unschedulablePod) if len(q.unschedulableQ.podInfoMap) != 0 { t.Error("Expected unschedulableQ to be empty.") } <ins> q.lock.RLock() </ins> if _, exists, _ := q.activeQ.Get(newPodInfoNoTimestamp(&unschedulablePod)); !exists { t.Errorf("Expected: %v to be added to activeQ.", unschedulablePod.Name) } <ins> q.lock.RUnlock() </ins> if p, err := q.Pop(); err != nil || p.Pod != &highPriNominatedPod { t.Errorf("Expected: %v after Pop, but got: %v", highPriorityPod.Name, p.Pod.Name) }

Discussion:
<!-- 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-bazel-test Which test(s) are flaking: pkg/scheduler/internal/queue Testgrid link: Reason for failure: Anything else we need to know: /sig scheduling /assign
I just sent a pr for it according to the error message, but I'm not very sure if it will make things all right.
/assign