jiebi/CodeConvo huggingface dataset:
Change:
// this func must run in admin mode, otherwise it will fail func TestGetMountRefs(t *testing.T) { <del> fm := &FakeMounter{MountPoints: []MountPoint{}} mountPath := `c:secondmountpath` expectedRefs := []string{`c:`, `c:firstmountpath`, mountPath} // remove symbolic links first for i := 1; i < len(expectedRefs); i++ { removeLink(expectedRefs[i]) } // create symbolic links for i := 1; i < len(expectedRefs); i++ { if err := makeLink(expectedRefs[i], expectedRefs[i-1]); err != nil { t.Errorf("makeLink failed: %v", err) } </del> <ins> tests := []struct { mountPath    string expectedRefs []string }{ { mountPath:    `c:windows`, expectedRefs: []string{`c:windows`}, }, { mountPath:    `c:doesnotexist`, expectedRefs: []string{}, }, </ins> } <del> if refs, err := fm.GetMountRefs(mountPath); err != nil || !setEquivalent(expectedRefs, refs) { t.Errorf("getMountRefs(%q) = %v, error: %v; expected %v", mountPath, refs, err, expectedRefs) } </del> <ins> mounter := Mounter{"fake/path"} </ins> <del> // remove symbolic links for i := 1; i < len(expectedRefs); i++ { if err := removeLink(expectedRefs[i]); err != nil { t.Errorf("removeLink failed: %v", err) </del> <ins> for _, test := range tests { if refs, err := mounter.GetMountRefs(test.mountPath); err != nil || !setEquivalent(test.expectedRefs, refs) { t.Errorf("getMountRefs(%q) = %v, error: %v; expected %v", test.mountPath, refs, err, test.expectedRefs) </ins> } } }

Discussion:
<!-- 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 /sig windows What happened: After creating pods having PersistentVolumeClaims and deleting them, the logs are getting filled with errors regarding failing to unmount the volume [1]. Additionally, tests requiring PVCs will hang several minutes while waiting the PV to unmount [2]. [1] [2] What you expected to happen: There shouldn't be any issues while unmounting the volume, the tests shouldn't have to wait several minutes waiting for the volume to be unmounted. How to reproduce it (as minimally and precisely as possible): pod requiring PVC. the pod. logs for error messages regarding the volume not being able to be unmounted. Anything else we need to know?: Environment: Kubernetes version (use ): v1.11.2 Cloud provider or hardware configuration: Azure, acs-engine v0.21.2 (: ) OS (e.g. from /etc/os-release): Windows Server 1803 Kernel (e.g. ): Install tools: Others:
/sig azure /assign
what's your PVC type? is it azure disk?
thanks for reporting. I have identified that this is a regression introduced by UnmountDevice common code mainly for linux: the root cause is is not well implemented Error code is like following: I have a different implementation for func on windows wich could fix this issue, will file a PR tomorrow.
Change:
if (( "${found}" == "${EXPECTED_NUM_NODES}" )) && (( "${ready}" == "${EXPECTED_NUM_NODES}")); then break elif (( "${found}" > "${EXPECTED_NUM_NODES}" )); then <del> echo -e "${color_red}Found ${found} nodes, but expected ${EXPECTED_NUM_NODES}. Your cluster may not behave correctly.${color_norm}" </del> <ins> if [[ "${KUBE_USE_EXISTING_MASTER:-}" != "true" ]]; then echo -e "${color_red}Found ${found} nodes, but expected ${EXPECTED_NUM_NODES}. Your cluster may not behave correctly.${color_norm}" fi </ins> break elif (( "${ready}" > "${EXPECTED_NUM_NODES}")); then echo -e "${color_red}Found ${ready} ready nodes, but expected ${EXPECTED_NUM_NODES}. Your cluster may not behave correctly.${color_norm}"

Discussion:
I have an existing v1.2 cluster on AWS and wanted to utilize the multi-AZ functionality. After following , the new node seems to be correctly, but I received the error below after completed. It seems like the script is not aware of the total cluster size and throwing an error, even though the instance is registering correctly.
Happening to us also :+1: nothing seems broken however, looks like the up script is getting confused.
Change:
"k8s.io/kubernetes/pkg/watch" ) <del> // Give each test that starts a background controller up to 1/2 a second. // Since we need to start up a goroutine to test watch, this routine needs // to get cpu before the test can complete. If the test is starved of cpu, // the watch test will take up to 1/2 a second before timing out. const controllerTimeout = 500 * time.Millisecond </del> var alwaysReady = func() bool { return true } func newJob(parallelism, completions int) *experimental.Job {

Discussion:
Ran a test executable with more than 20,000 times and no failures. Any hints as to how to get it to show up? I'm running 100 jobs at a time, so my system is stressed already.
I to am unable to reproduce this. I get similar errors if I reduce the timeout at the top of the file. I spent a bit looking at how to rewrite the tests without the timeout, but nothing jumped out at me. Looking at it though, it's really just a 500ms timeout for the test to complete. I'm just going to remove them. Go has a default timeout of 10 minutes. If it's going to pass, it will pass then. If not, Go will give you a nice traceback where it deadlocked.
Change:
b.WriteString(fmt.Sprintf("etcd output:n%sn", e2es.etcdCombinedOut.String())) } b.WriteString("******************************************************n") <del> glog.V(2).Infof(b.String()) </del> <ins> glog.V(0).Infof(b.String()) </ins> }

Discussion:
Looks like it maybe the ssh connect is getting killed
The relevant log snippet:
And another one, not just coreos.
Change:
if !masterNodes.Has(pod.Spec.NodeName) { if pod.Spec.NodeName != "" { _, scheduledCondition := api.GetPodCondition(&pod.Status, api.PodScheduled) <del> Expect(scheduledCondition != nil).To(Equal(true)) Expect(scheduledCondition.Status).To(Equal(api.ConditionTrue)) </del> <ins> // We can't assume that the scheduledCondition is always set if Pod is assigned to Node, // as e.g. DaemonController doesn't set it when assigning Pod to a Node. Currently // Kubelet sets this condition when it gets a Pod without it, but if we were expecting // that it would always be not nil, this would cause a rare race condition. if scheduledCondition != nil { Expect(scheduledCondition.Status).To(Equal(api.ConditionTrue)) } </ins> scheduledPods = append(scheduledPods, pod) } else { _, scheduledCondition := api.GetPodCondition(&pod.Status, api.PodScheduled) <del> Expect(scheduledCondition != nil).To(Equal(true)) Expect(scheduledCondition.Status).To(Equal(api.ConditionFalse)) </del> <ins> if scheduledCondition != nil { Expect(scheduledCondition.Status).To(Equal(api.ConditionFalse)) } </ins> if scheduledCondition.Reason == "Unschedulable" { notScheduledPods = append(notScheduledPods, pod) }

Discussion:
https://k8s- Failed: [] SchedulerPredicates [Serial] validates resource limits of pods that are allowed to run [Conformance] {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] SchedulerPredicates [Serial] validates resource limits of pods that are allowed to run [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates resource limits of pods that are allowed to run [Conformance] {Kubernetes e2e suite}
The last failure is legitimate. The file changed since the run, so for easier lookup - the expect that failed is caused by the Expect in Current assumption is that something overwrites PodStatus after Scheduler sets up ScheduledCondition (i.e. we have a conflict during first update, and then retry it without applying changes that were made to the PodStatus at that time). This is very rare flake, but it should be pretty simple to debug.
- cool; what about the previous two failure? Did you have time to look into them?
I didn't have time today. I'll look into them tomorrow.
This is caused by the way is assigned for Pods created by a DeamonController. In case of "normal" Pods assigning Node to a Pod is done in the same time as setting , for daemons DaemonController just assigns a Node, and it's a Kubelet that adds a to it. This leaves some time between Pod creation (with already assigned Node) done by the DaemonController and the time when is written - when we get unlucky this makes the test fail.
Change:
GetDeviceNameFromMount(mountPath, pluginDir string) (string, error) } <ins> // Compile-time check to ensure all Mounter implementations satisfy // the mount interface var _ Interface = &Mounter{} </ins> // This represents a single line in /proc/mounts or /etc/fstab. type MountPoint struct { Device string

Discussion:
Compilation error in GetDeviceNameFromMount declared twice. and are duplicates and one of them need to be reverted. (build is disabled for linux, that's why both of them got in)
see , please
Looks like this can be closed now. right ?
Yes, closed by
Change:
return append(allErrs, field.Invalid(fldPath, value, isInvalidQuotaResource)) } } <del> return field.ErrorList{} </del> <ins> return allErrs </ins> } // Validate limit range types

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: In some validation functions, such as , , value returned may be wrong. When return some errors and , we may just return , that is not expected What you expected to happen: return correctly
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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
/assign
Can you clarify "wrong"?
For example in will add and to field of ResourceQuotaSpec. Before , these two resources are not to standard resource sets, will return error since they are not fully-qualified neither. But will not return any error since the two resources are to standard quota resource name sets. The result above is not expected . Error happened in , we need to return it instead of returning when we ran
Change:
echo "Setting ${name}'s aliases to '${aliases}' (removed ${ip})" # Detach ${MASTER_NAME}-internal-ip from ${name} gcloud compute instances network-interfaces update "${name}" --project "${PROJECT}" --zone "${zone}" --aliases="${aliases}" <ins> gcloud compute instances remove-metadata "${name}" --zone "${zone}" --keys=kube-master-internal-ip </ins> run-gcloud-command "${name}" "${zone}" 'sudo ip route del to local '${ip}'/32 dev $(ip route | grep default | awk '''{print $5}''')' || true return $? }

Discussion:
If you create a private cluster via kube-up using provider GCE, you won't be able to restart your master nodes. If you restart you master, the nodes won't be able to connect to your master. This is due to this line - It gets executed on master on cluster-up, but it won't be re-executed on master restart. We should fix that, especially if we're to implement /sig scalability /priority important-soon
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 /good-first-issue I'll ask whether someone in SIG Scalability public meeting would like to take on this one
This request has been marked as suitable for new contributors. 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. <detailsIn response to : /remove-lifecycle stale /good-first-issue 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
Hello, Can I start work on this one as my first issue? :)
I don't see anyone else claiming it, so your contributions are welcome :)
let me know if you need any explanations here
Thank you :) I've made some changes and assign you can you tell me is this will be good approach?
Thanks, I replied in the PR
Change:
nodeName        types.NodeName volumeHost      volume.VolumeHost migratedPlugins map[string](func() bool) <ins> // lock protects changes to node. lock sync.Mutex </ins> } // If no updates is needed, the function must return the same Node object as the input.

Discussion:
What happened: I two CSI plugins to my Kubernetes cluster via a single call to . When I did this, the annotation was improperly set on 2 out of 3 nodes. Only one of the plugins appeared: What you expected to happen: Both and plugins should have appeared in the annotation. How to reproduce it (as minimally and precisely as possible): Apply two or more CSI plugins via a single call to . Anything else we need to know?: Kubelet logs indicate that it registered both plugins at the same time: The CSINode object looks complete: Only the node's annotation did not include Restarting kubelet fixed the issue. It looks like a race condition when InstallCSIDriver is called concurrently for multiple drivers. The code here: could lead to each thread observing the annotation as being empty, and then setting its own annotation that includes only itself. Environment: Kubernetes version (use ): v1.17.11 Cloud provider or hardware configuration: AWS OS (e.g: ): Ubuntu 20.04.1 LTS Kernel (e.g. ): Linux ip-172-31-17-163 5.4.0-1021-aws -Ubuntu SMP Fri Jul 24 09:42:29 UTC 2020 x8664 x8664 x86_64 GNU/Linux Install tools: juju
/sig storage
/assign
I can reproduce this issue with commands below ! The correct csi nodeid would be like this
Change:
clientsetPods: []runtime.Object{testPodWithOneContainers()}, actions: []testclient.Action{ testclient.NewListAction(podsResource, podsKind, "test", metav1.ListOptions{LabelSelector: "foo=bar"}), <del> getLogsAction("test", nil), </del> <ins> getLogsAction("test", &corev1.PodLogOptions{Container: "c1"}), </ins> }, expectedSources: []corev1.ObjectReference{{ Kind:       testPodWithOneContainers().Kind,

Discussion:
/kind bug The logs of pods with label will be output expected without errors. create the following resources: kubectl logs -l Kubernetes version (use ): latest master.
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 cli
I am able to pull logs from multiple containers in my test setup, this doesn't seem to be an issue with Could you check if all the containers in the specified pod are healthy?
yes, all of these pods' containers are healthy. I the section.
This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close
Closing this issue. <detailsIn response to : This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close 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
Change:
"//staging/src/k8s.io/api/rbac/v1:go_default_library", "//staging/src/k8s.io/api/storage/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", <ins> "//staging/src/k8s.io/apiserver/pkg/authentication/user:go_default_library", </ins> "//staging/src/k8s.io/apiserver/pkg/authorization/authorizer:go_default_library", "//staging/src/k8s.io/apiserver/pkg/util/feature:go_default_library", "//staging/src/k8s.io/client-go/informers/core/v1:go_default_library",

Discussion:
What happened: I checked if kubelet () has permissions for with SelfsubjectAccessReviews and I saw that it has. But when I checked its permissions with SelfsubjectRulesReviews it didn't show it. What you expected to happen: I expected that the API SelfsubjectRulesReviews will show that has permssions for . How to reproduce it (as minimally and precisely as possible): You can check it on the master or the worker. Test SelfsubjectAccessReviews: You will get answer that it has permissions: Test SelfsubjectRulesReviews: It won't show the permissions. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g: ):Kernel (e.g. ):Install tools: kubeadm /area/api /kind/bug /sig api-machinery
/sig api-machinery
This is a more clean display that show the bug: I think the problem is related to the fact that the file contain the kubelet certificate which is part of the group :
/sig auth
What is the SelfSubjectRulesReview response from the server ()? Note that not all authorizers support enumerating permissions, and the API object status includes an attribute which explicitly indicates the result is incomplete. See
It has Details:
I noticed that it also doesn't show that it has permissions to view and . It probably related to the Node authorizer: Because I assume that these rules doesn't appear in RBAC.
The node authorizer does not enumerate permissions, so it does not contribute to SelfSubjectRulesReview results
fixes setting correctly when the API is requested with a kubelet's credentials
Change:
t.Errorf("Expected mount options to be %v got %v", expectedMountOptions, mountOptions) } } <ins> func TestGetCandidateZone(t *testing.T) { const testZone = "my-zone-1a" // TODO: add test case for immediate bind volume when we have a good way to mock Cloud outside cloudprovider tests := []struct { cloud         *aws.Cloud node          *v1.Node expectedZones sets.String }{ { cloud: nil, node: &v1.Node{ ObjectMeta: metav1.ObjectMeta{ Labels: map[string]string{ v1.LabelZoneFailureDomain: testZone, }, }, }, expectedZones: sets.NewString(), }, { cloud:         nil, node:          &v1.Node{}, expectedZones: sets.NewString(), }, } for _, test := range tests { zones, err := getCandidateZones(test.cloud, test.node) assert.Nil(t, err) assert.Equal(t, test.expectedZones, zones) } } </ins>

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: We have pretty large clusters in aws and in production, we found an inefficiency in provisioning dynamic EBS volumes, where aws-ebs volume provisioner tries to look for available zone from aws directly. With scale, this can trigger massive from ec2, and affect cluster stability. This is also related to What you expected to happen: To simply get zones with available instances, we can get information from API server for efficiency. There might be a delay between node gets shutting down and such change is reflected in api server, but in case node is not ready or gets terminated, there will be higher level reconciliation triggered so we are safe. How to reproduce it (as minimally and precisely as possible): We only expect this to be hit when the cluster is huge (or aws account is huge) so not easy to reproduce. /assign /sig aws /sig cloud-provider
/assign
Change:
exec := exec.New() outputBytes, err := exec.Command(nsenterPath, args...).CombinedOutput() if len(outputBytes) != 0 { <del> glog.V(5).Infof("Output from mount command: %v", string(outputBytes)) </del> <ins> glog.V(5).Infof("Output of unmounting %s: %v", target, string(outputBytes)) </ins> } return err

Discussion:
Currently, there many error messages in that do not contain any context. This means that these messages are basically meaningless in real systems where many pods may be on a node. Examples: Every error message in this file should identify the path that the message is in relation to.
Can you handle this, since you most recently touched in ?
Change:
return nil, false, nil } <ins> // Cannot run cloud ipam controller if cloud provider is nil (--cloud-provider not set or set to 'external') if controllerContext.Cloud == nil && controllerContext.ComponentConfig.KubeCloudShared.CIDRAllocatorType == string(ipam.CloudAllocatorType) { return nil, false, errors.New("--cidr-allocator-type is set to 'CloudAllocator' but cloud provider is not configured") } </ins> clusterCIDRs, err := validateCIDRs(controllerContext.ComponentConfig.KubeCloudShared.ClusterCIDR) if err != nil { return nil, false, err

Discussion:
Cloud-providers started to move out of tree its controller, but they share some functionalities, one of them is the NodeIPAM controller. There is a type that is GCE specific, the type. If this type is used, but no configuration for GCE is passed, the kcm panics. This can be observed in the following job: The question is, should this type be removed or a noop in KCM?
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 /cc
/sig cloud-provider
Is this a case of CCM handling IPAM so KCM needs to not handle it? What I mean is why is this set without a config? What was the intention? The fact that this has GCE-cloud-provider baked in is awful and should probably have been inverted (GCE provider calls a "register" method or something), but that's aside
Context: I started to set up jobs using the CCM by default, the cluster set up uses the script. The script doesn't consider IPAM, so it configures both KCM and CCM, but if set to "external" , it doesn't configure GCEPROVIDER in KCM When , the scripts set ... and CloudAllocator only runs with GCE My concern is that if this happens to me, it is possible that users that have to migrate custom cluster will face the same issue
A panic here seems appropriate, right? They specifically asked for a config that doesn't work and action needed to be taken. Am I misunderstanding?
A panic is appropriate given we never did any handling of this corner case -- I think it would be reasonable going forward to have a check in place to disable nodeipam controller if the allocator is but the cloud provider is not configured.
Opened with the check and a warning when this happens. We can also consider erroring out KCM if we see this happen so it's really clear to users that they misconfigured something