jiebi/CodeConvo huggingface dataset:
Code change:
<!-- 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!--What happened: azure file remount on Windows in same node would fail What you expected to happen: If user delete a pod with azure file mount in deployment and it would probably schedule a pod on same node, azure file mount will fail since command would fail if file share is already mounted on the node: It's related to bug: Error logs would be like following: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.9-v1.12, master Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /assign
/sig windows
/sig azure
/milestone v1.14 cc This may be good to backport to 1.12 or 1.13 too if customers are using those versions.

Related discussion:
text: return nil } <ins> // do the SMB mount with username, password, remotepath // return (output, error) func newSMBMapping(username, password, remotepath string) (string, error) { if username == "" || password == "" || remotepath == "" { return "", fmt.Errorf("invalid parameter(username: %s, password: %s, remoteapth: %s)", username, password, remotepath) } // use PowerShell Environment Variables to store user input string to prevent command line injection // https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_environment_variables?view=powershell-5.1 cmdLine := `$PWord = ConvertTo-SecureString -String $Env:smbpassword -AsPlainText -Force` + `;$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $Env:smbuser, $PWord` + `;New-SmbGlobalMapping -RemotePath $Env:smbremotepath -Credential $Credential` cmd := exec.Command("powershell", "/c", cmdLine) cmd.Env = append(os.Environ(), fmt.Sprintf("smbuser=%s", username), fmt.Sprintf("smbpassword=%s", password), fmt.Sprintf("smbremotepath=%s", remotepath)) output, err := cmd.CombinedOutput() return string(output), err } // check whether remotepath is already mounted func isSMBMappingExist(remotepath string) bool { cmd := exec.Command("powershell", "/c", `Get-SmbGlobalMapping -RemotePath $Env:smbremotepath`) cmd.Env = append(os.Environ(), fmt.Sprintf("smbremotepath=%s", remotepath)) _, err := cmd.CombinedOutput() return err == nil } // remove SMB mapping func removeSMBMapping(remotepath string) (string, error) { cmd := exec.Command("powershell", "/c", `Remove-SmbGlobalMapping -RemotePath $Env:smbremotepath -Force`) cmd.Env = append(os.Environ(), fmt.Sprintf("smbremotepath=%s", remotepath)) output, err := cmd.CombinedOutput() return string(output), err } </ins> // Unmount unmounts the target. func (mounter *Mounter) Unmount(target string) error { klog.V(4).Infof("azureMount: Unmount target (%q)", target)
Code change:
<!-- 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!--What happened: azure file remount on Windows in same node would fail What you expected to happen: If user delete a pod with azure file mount in deployment and it would probably schedule a pod on same node, azure file mount will fail since command would fail if file share is already mounted on the node: It's related to bug: Error logs would be like following: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.9-v1.12, master Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /assign
/sig windows
/sig azure
/milestone v1.14 cc This may be good to backport to 1.12 or 1.13 too if customers are using those versions.

Related discussion:
text: } } } <ins> func TestNewSMBMapping(t *testing.T) { tests := []struct { username    string password    string remotepath  string expectError bool }{ { "", "password", `remotepath`, true, }, { "username", "", `remotepath`, true, }, { "username", "password", "", true, }, } for _, test := range tests { _, err := newSMBMapping(test.username, test.password, test.remotepath) if test.expectError { assert.NotNil(t, err, "Expect error during newSMBMapping(%s, %s, %s, %v)", test.username, test.password, test.remotepath) } else { assert.Nil(t, err, "Expect error is nil during newSMBMapping(%s, %s, %s, %v)", test.username, test.password, test.remotepath) } } } </ins>
Code change:
We need to add Windows-specific DNS tests to cover the following fields: Test cases needed for : Default, ClusterFirst, None Test cases needed for Test cases needed for Test cases needed for These need to run on Windows containers because the domain resolution policy is different, so different results need to be checked. Windows assumes that any name with a in it is a FQDN, not a PQDN. There is an to cover simple PQDN resolution, but they don't cover the Pod DNS configurations above. /sig windows /milestone v1.14
FYI I'm working on this. I plan to start out by porting over to Windows.
I just moved it into the in progress column. THanks!
What test cases are needed for , , and ? My thoughts were that covers and . I'm adding test cases for Default and ClusterFirst. Does cover the test cases needed for and or do I need more? Or should I just be porting over the entire file?
For the first one - yes. The main differences will be checking the output of instead of , and maybe using instead of but the flow is the same Checking second one now
Agree on second one. I think that will cover it. It may make sense to simplify it a bit because the common methods used there are all based on running bash + dig. If it works with busybox, that may be feasible. The description at matches those test cases
If at all possible, could we use native Windows cmdlets such as instead of relying on Linux cmdlets that have been ported to Windows like ? Am not 100% confident if they are going to behave consistently.
yeah, I think what David's suggesting makes sense if the test cases are forked for Windows.
Opened PR for enabling custom DNS on Azure CNI:
/milestone clear This will need to merge after 1.14 as we're waiting on CNI updates for these tests to pass. I this status note to the Windows kep
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
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 rotten

Related discussion:
text: name = "go_default_library", srcs = [ "density.go", <ins> "dns.go", </ins> "framework.go", "gmsa.go", "hybrid_network.go",
Code change:
<!-- 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!--What happened: In an otherwise-stable bare-metal setup, with only LocalVolume and NFS storage, and without any volume mount activity, I get 80,000+ of these warning messages per day: What you expected to happen: No warnings; and if there is a reason to generate these warnings, more info about what operation is being attempted should be to the warnings message. How to reproduce it (as minimally and precisely as possible): I don't know. This issue emerged after I about 40 services and 300 volumes on a 3-worker cluster. Anything else we need to know?: Environment: Kubernetes version (use ): 1.13.0Cloud provider or hardware configuration: Bare-metal OS (e.g. from /etc/os-release): Ubuntu 18.04.1 bionic Kernel (e.g. ): 4.15.0-42-generic Install tools: kubeadm Others:
/sig storage

Related discussion:
text: if spec.IsKubeletExpandable() { // for kubelet expandable volumes, return a noop plugin that // returns success for expand on the controller <del> klog.Warningf("FindExpandablePluginBySpec(%s) -> returning noopExpandableVolumePluginInstance", spec.Name()) </del> <ins> klog.V(4).Infof("FindExpandablePluginBySpec(%s) -> returning noopExpandableVolumePluginInstance", spec.Name()) </ins> return &noopExpandableVolumePluginInstance{spec}, nil } <del> klog.Warningf("FindExpandablePluginBySpec(%s) -> err:%v", spec.Name(), err) </del> <ins> klog.V(4).Infof("FindExpandablePluginBySpec(%s) -> err:%v", spec.Name(), err) </ins> return nil, err }
Code change:
Which jobs are failing: Which test(s) are failing: Job Reason for failure --- --- Since when has it been failing: 2019-02-11 Anything else we need to know: started failing with commit started failing with commit cc /kind failing-test /priority important-soon /sig api-machinery

Related discussion:
text: optional APIServiceStatus status = 3; } <ins> // APIServiceCondition describes the state of an APIService at a particular point </ins> message APIServiceCondition { // Type is the type of the condition. optional string type = 1;
Code change:
What happened: The preparation step of the e2e tests were failed sometimes on my local environment like What you expected to happen: These tests can be passed without any errors. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.13.1 Cloud provider or hardware configuration: OpenStack OS (e.g. from /etc/os-release): 16.04.4 LTS (Xenial Xerus) Kernel (e.g. ): 4.4.0-138-generic Install tools: kubeadm Others:
/sig storage
After discussing on the PR I have known I need to enable StorageObjectInUseProtection plugin of admission controller which is disabled by default. The corresponding e2e tests require the plugin is enabled, so I think it is better to enable the plugin by default for most users.
Investigation of StorageObjectInUseProtection plugin of admission controller under kubernetes/kubernetes: cluster/centos/config- Enabled cluster/gce/config- Enabled cluster/gce/config- Enabled cluster/kubemark/gce/config- Enabled hack/local-up- Enabled cluster/juju/layers/kubernetes- Disabled This is the reason why we don't face this issue on the upstream CI system, and I it on my local environment which is deployed with kubeadm.

Related discussion:
text: # Admission Controllers to invoke prior to persisting objects in cluster ENABLE_ADMISSION_PLUGINS="LimitRanger,ResourceQuota" <del> DISABLE_ADMISSION_PLUGINS="ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook" </del> <ins> DISABLE_ADMISSION_PLUGINS="ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,StorageObjectInUseProtection" </ins> # Include RBAC (to exercise bootstrapping), and AlwaysAllow to allow all actions AUTHORIZATION_MODE="RBAC,AlwaysAllow"
Code change:
What happened: The preparation step of the e2e tests were failed sometimes on my local environment like What you expected to happen: These tests can be passed without any errors. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.13.1 Cloud provider or hardware configuration: OpenStack OS (e.g. from /etc/os-release): 16.04.4 LTS (Xenial Xerus) Kernel (e.g. ): 4.4.0-138-generic Install tools: kubeadm Others:
/sig storage
After discussing on the PR I have known I need to enable StorageObjectInUseProtection plugin of admission controller which is disabled by default. The corresponding e2e tests require the plugin is enabled, so I think it is better to enable the plugin by default for most users.
Investigation of StorageObjectInUseProtection plugin of admission controller under kubernetes/kubernetes: cluster/centos/config- Enabled cluster/gce/config- Enabled cluster/gce/config- Enabled cluster/kubemark/gce/config- Enabled hack/local-up- Enabled cluster/juju/layers/kubernetes- Disabled This is the reason why we don't face this issue on the upstream CI system, and I it on my local environment which is deployed with kubeadm.

Related discussion:
text: ETCDCTL=$(which etcdctl) KUBECTL="${KUBE_OUTPUT_HOSTBIN}/kubectl" UPDATE_ETCD_OBJECTS_SCRIPT="${KUBE_ROOT}/cluster/update-storage-objects.sh" <del> DISABLE_ADMISSION_PLUGINS="ServiceAccount,NamespaceLifecycle,LimitRanger,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PersistentVolumeLabel,DefaultStorageClass" </del> <ins> DISABLE_ADMISSION_PLUGINS="ServiceAccount,NamespaceLifecycle,LimitRanger,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PersistentVolumeLabel,DefaultStorageClass,StorageObjectInUseProtection" </ins> function startApiServer() { local storage_versions=${1:-""}
Code change:
What happened: The preparation step of the e2e tests were failed sometimes on my local environment like What you expected to happen: These tests can be passed without any errors. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.13.1 Cloud provider or hardware configuration: OpenStack OS (e.g. from /etc/os-release): 16.04.4 LTS (Xenial Xerus) Kernel (e.g. ): 4.4.0-138-generic Install tools: kubeadm Others:
/sig storage
After discussing on the PR I have known I need to enable StorageObjectInUseProtection plugin of admission controller which is disabled by default. The corresponding e2e tests require the plugin is enabled, so I think it is better to enable the plugin by default for most users.
Investigation of StorageObjectInUseProtection plugin of admission controller under kubernetes/kubernetes: cluster/centos/config- Enabled cluster/gce/config- Enabled cluster/gce/config- Enabled cluster/kubemark/gce/config- Enabled hack/local-up- Enabled cluster/juju/layers/kubernetes- Disabled This is the reason why we don't face this issue on the upstream CI system, and I it on my local environment which is deployed with kubeadm.

Related discussion:
text: // DefaultOffAdmissionPlugins get admission plugins off by default for kube-apiserver. func DefaultOffAdmissionPlugins() sets.String { defaultOnPlugins := sets.NewString( <del> lifecycle.PluginName,                //NamespaceLifecycle limitranger.PluginName,              //LimitRanger serviceaccount.PluginName,           //ServiceAccount setdefault.PluginName,               //DefaultStorageClass resize.PluginName,                   //PersistentVolumeClaimResize defaulttolerationseconds.PluginName, //DefaultTolerationSeconds mutatingwebhook.PluginName,          //MutatingAdmissionWebhook validatingwebhook.PluginName,        //ValidatingAdmissionWebhook resourcequota.PluginName,            //ResourceQuota </del> <ins> lifecycle.PluginName,                    //NamespaceLifecycle limitranger.PluginName,                  //LimitRanger serviceaccount.PluginName,               //ServiceAccount setdefault.PluginName,                   //DefaultStorageClass resize.PluginName,                       //PersistentVolumeClaimResize defaulttolerationseconds.PluginName,     //DefaultTolerationSeconds mutatingwebhook.PluginName,              //MutatingAdmissionWebhook validatingwebhook.PluginName,            //ValidatingAdmissionWebhook resourcequota.PluginName,                //ResourceQuota storageobjectinuseprotection.PluginName, //StorageObjectInUseProtection </ins> ) if utilfeature.DefaultFeatureGate.Enabled(features.PodPriority) {
Code change:
I have been deploying master-branch kubernetes on Windows using flannel/host-gateway networking, with one master, one linux worker, and three windows worker. Recently, kube-proxy stopped running correctly. It exits with an error about not finding the HNS Network. I have confirmed that the HNS network exists on the host with the correct name (cbr0), and have identified the last commit where kube-proxy works. What happened: Starting with the commit merging , kube-proxy outputs the following error message: This is confusing because does show : (nat network removed from above output) What you expected to happen: kube-proxy to work in host-gateway mode. How to reproduce it (as minimally and precisely as possible): Build kubernetes at or after . Start flanneld, kubelet, and kube-proxy on a windows 2019 vm. See kube-proxy fail despite flanneld having created the network. Anything else we need to know?: Environment: Kubernetes version (use ): kube-proxy breaks on commit and later; works on Cloud provider or hardware configuration: vsphere OS (e.g: ): windows server 2019, with up-to-date patches Kernel (e.g. ): windows nodes are , linux master/worker are Install tools: deployed using /sig windows cc
I'm aware of this issue. The fix will be out within an hour.

Related discussion:
text: var hns HostNetworkService hns = hnsV1{} supportedFeatures := hcn.GetSupportedFeatures() <del> if supportedFeatures.Api.V2 { </del> <ins> if supportedFeatures.RemoteSubnet { </ins> hns = hnsV2{} }
Code change:
Which jobs are failing: All new tests introduced for api change Which test(s) are failing: New alpha subpathExpr tests [Feature:VolumeSubpathEnvExpansion][NodeAlphaFeature:VolumeSubpathEnvExpansion] Existing tests are working fine and the whole suite works correctly in the gce suite https://k8s- Since when has it been failing: 21st February 2019 (since merge of PR) Testgrid link: https://k8s- Reason for failure: Investigation shows that node e2e tests use a different framework pod creation pattern Doing some comparisons of tests that work and those that don't reveals differences in the standard client set as and the existing ones which do work go through the intermediate which uses The version has an additional function specifically for node tests
/sig storage
/sig node /sig test
/assign
/cc
/sig test

Related discussion:
text: } By("creating the pod with failed condition") <del> pod, err := f.ClientSet.CoreV1().Pods(f.Namespace.Name).Create(pod) Expect(err).ToNot(HaveOccurred(), "while creating pod") err = framework.WaitTimeoutForPodRunningInNamespace(f.ClientSet, pod.Name, pod.Namespace, framework.PodStartShortTimeout) Expect(err).To(HaveOccurred(), "while waiting for pod to be running") </del> var podClient *framework.PodClient podClient = f.PodClient() <ins> pod = podClient.Create(pod) err := framework.WaitTimeoutForPodRunningInNamespace(f.ClientSet, pod.Name, pod.Namespace, framework.PodStartShortTimeout) Expect(err).To(HaveOccurred(), "while waiting for pod to be running") </ins> By("updating the pod") podClient.Update(podName, func(pod *v1.Pod) {
Code change:
Which jobs are failing: All new tests introduced for api change Which test(s) are failing: New alpha subpathExpr tests [Feature:VolumeSubpathEnvExpansion][NodeAlphaFeature:VolumeSubpathEnvExpansion] Existing tests are working fine and the whole suite works correctly in the gce suite https://k8s- Since when has it been failing: 21st February 2019 (since merge of PR) Testgrid link: https://k8s- Reason for failure: Investigation shows that node e2e tests use a different framework pod creation pattern Doing some comparisons of tests that work and those that don't reveals differences in the standard client set as and the existing ones which do work go through the intermediate which uses The version has an additional function specifically for node tests
/sig storage
/sig node /sig test
/assign
/cc
/sig test

Related discussion:
text: } By("creating the pod") <del> pod, err := f.ClientSet.CoreV1().Pods(f.Namespace.Name).Create(pod) </del> <ins> var podClient *framework.PodClient podClient = f.PodClient() pod = podClient.Create(pod) </ins> By("waiting for pod running") <del> err = framework.WaitTimeoutForPodRunningInNamespace(f.ClientSet, pod.Name, pod.Namespace, framework.PodStartShortTimeout) </del> <ins> err := framework.WaitTimeoutForPodRunningInNamespace(f.ClientSet, pod.Name, pod.Namespace, framework.PodStartShortTimeout) </ins> Expect(err).NotTo(HaveOccurred(), "while waiting for pod to be running") By("creating a file in subpath")
Code change:
Which jobs are failing: All new tests introduced for api change Which test(s) are failing: New alpha subpathExpr tests [Feature:VolumeSubpathEnvExpansion][NodeAlphaFeature:VolumeSubpathEnvExpansion] Existing tests are working fine and the whole suite works correctly in the gce suite https://k8s- Since when has it been failing: 21st February 2019 (since merge of PR) Testgrid link: https://k8s- Reason for failure: Investigation shows that node e2e tests use a different framework pod creation pattern Doing some comparisons of tests that work and those that don't reveals differences in the standard client set as and the existing ones which do work go through the intermediate which uses The version has an additional function specifically for node tests
/sig storage
/sig node /sig test
/assign
/cc
/sig test

Related discussion:
text: } By("updating the annotation value") <del> var podClient *framework.PodClient podClient = f.PodClient() </del> podClient.Update(podName, func(pod *v1.Pod) { pod.ObjectMeta.Annotations["mysubpath"] = "mynewpath" })
Code change:
Which jobs are failing: All new tests introduced for api change Which test(s) are failing: New alpha subpathExpr tests [Feature:VolumeSubpathEnvExpansion][NodeAlphaFeature:VolumeSubpathEnvExpansion] Existing tests are working fine and the whole suite works correctly in the gce suite https://k8s- Since when has it been failing: 21st February 2019 (since merge of PR) Testgrid link: https://k8s- Reason for failure: Investigation shows that node e2e tests use a different framework pod creation pattern Doing some comparisons of tests that work and those that don't reveals differences in the standard client set as and the existing ones which do work go through the intermediate which uses The version has an additional function specifically for node tests
/sig storage
/sig node /sig test
/assign
/cc
/sig test

Related discussion:
text: // Start pod By(fmt.Sprintf("Creating pod %s", pod.Name)) <del> pod, err := f.ClientSet.CoreV1().Pods(f.Namespace.Name).Create(pod) Expect(err).ToNot(HaveOccurred(), "while creating pod") </del> <ins> var podClient *framework.PodClient podClient = f.PodClient() pod = podClient.Create(pod) </ins> defer func() { framework.DeletePodWithWait(f, f.ClientSet, pod) }() <del> err = framework.WaitForPodRunningInNamespace(f.ClientSet, pod) </del> <ins> err := framework.WaitForPodRunningInNamespace(f.ClientSet, pod) </ins> Expect(err).ToNot(HaveOccurred(), "while waiting for pod to be running") <del> var podClient *framework.PodClient podClient = f.PodClient() </del> By("updating the pod") podClient.Update(podName, func(pod *v1.Pod) { pod.ObjectMeta.Annotations = map[string]string{"mysubpath": "newsubpath"}