jiebi/CodeConvo huggingface dataset:
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! If the matter is security related, please disclose it privately via --What happened: Azure data disk should use same encryption key as os disk if key is not provided by user, otherwise user would mess up with too many keys What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 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: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure

Discussion:
if isManagedDisk { managedDisk := &compute.ManagedDiskParameters{ID: &diskURI} <ins> if diskEncryptionSetID == "" { if vm.StorageProfile.OsDisk != nil && vm.StorageProfile.OsDisk.ManagedDisk != nil && vm.StorageProfile.OsDisk.ManagedDisk.DiskEncryptionSet != nil && vm.StorageProfile.OsDisk.ManagedDisk.DiskEncryptionSet.ID != nil { // set diskEncryptionSet as value of os disk by default diskEncryptionSetID = *vm.StorageProfile.OsDisk.ManagedDisk.DiskEncryptionSet.ID } } </ins> if diskEncryptionSetID != "" { managedDisk.DiskEncryptionSet = &compute.DiskEncryptionSetParameters{ID: &diskEncryptionSetID} }

} if isManagedDisk { managedDisk := &compute.ManagedDiskParameters{ID: &diskURI} <ins> if diskEncryptionSetID == "" { if vm.StorageProfile.OsDisk != nil && vm.StorageProfile.OsDisk.ManagedDisk != nil && vm.StorageProfile.OsDisk.ManagedDisk.DiskEncryptionSet != nil && vm.StorageProfile.OsDisk.ManagedDisk.DiskEncryptionSet.ID != nil { // set diskEncryptionSet as value of os disk by default diskEncryptionSetID = *vm.StorageProfile.OsDisk.ManagedDisk.DiskEncryptionSet.ID } } </ins> if diskEncryptionSetID != "" { managedDisk.DiskEncryptionSet = &compute.DiskEncryptionSetParameters{ID: &diskEncryptionSetID} }
Change:
Which jobs are flaking: pull-kubernetes-e2e-gce Which test(s) are flaking: Testgrid link: /sig cli
This test seems to stop flake. Can you check if we can close this issue?
still looks flaky to me
Can you take a look?
/milestone v1.19
have you had a chance to look into this?
Possibly related to
Let's see if removing makes it less flaky

Discussion:
ginkgo.By("Sending the expected data to the local port") fmt.Fprint(conn, "abc") <del> ginkgo.By("Closing the write half of the client's connection") if err = conn.CloseWrite(); err != nil { framework.Failf("Couldn't close the write half of the client's connection: %v", err) } </del> ginkgo.By("Reading data from the local port") fromServer, err := ioutil.ReadAll(conn) if err != nil {

framework.Failf("Expected %q from server, got %q", e, a) } <ins> ginkgo.By("Closing the write half of the client's connection") if err = conn.CloseWrite(); err != nil { framework.Failf("Couldn't close the write half of the client's connection: %v", err) } </ins> ginkgo.By("Waiting for the target pod to stop running") if err := WaitForTerminatedContainer(f, pod, "portforwardtester"); err != nil { framework.Failf("Container did not terminate: %v", err)
Change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We are making a series of enhancements to scheduler benchmarks. Once we are done, we should update the Ref , Why is this needed: /sig scheduling cc
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

Discussion:
make test-integration WHAT=./test/integration/scheduler_perf KUBE_TIMEOUT="-timeout=3600s" KUBE_TEST_VMODULE="''" KUBE_TEST_ARGS="-alsologtostderr=false -logtostderr=false -run=^$$ -benchtime=1ns -bench=BenchmarkPerfScheduling -cpuprofile ~/cpu-profile.out" ``` <ins> ### How to configure bechmark tests Configuration file located under config/performance-config.yaml contains a list of templates. Each template allows to set: - node manifest - manifests for initial and testing pod - number of nodes, number of initial and testing pods - templates for PVs and PVCs - feature gates See `simpleTestCases` data type implementation for available configuration for each template. Initial pods create a state of a cluster before the scheduler performance measurement can begin. Testing pods are then subject to performance measurement. The configuration file under config/performance-config.yaml contains a default list of templates to cover various scenarios. In case you want to add your own, you can extend the list with new templates. It's also possible to extend `simpleTestCases` data type, respectively its underlying data types to extend configuration of possible test cases. </ins> <!-- BEGIN MUNGE: GENERATED_ANALYTICS --> [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/test/component/scheduler/perf/README.md?pixel)]() <!-- END MUNGE: GENERATED_ANALYTICS -->
Change:
What happened: I have a test case: This behaves different with different client-go versions. With , the test passes. This is using in with in With , this test panics. This is using in with in Panic logs: Basically it its creating an object to decode into, and this object has some maps. These are set to nil, so when we try to populate them we get a panic. What you expected to happen: Behavior remains the same as previous release, or at least have some alternative that works here? How to reproduce it (as minimally and precisely as possible): I pasted the test above that reproduces this. This can be reproduced with a project with just that file, and a file with only client-go. Using go 1.13
/sig api-machinery
/assign

Discussion:
if err := Convert_v1_Cluster_To_api_Cluster(&curr.Cluster, newCluster, s); err != nil { return err } <ins> if *out == nil { *out = make(map[string]*api.Cluster) } </ins> if (*out)[curr.Name] == nil { (*out)[curr.Name] = newCluster } else {

if err := Convert_v1_AuthInfo_To_api_AuthInfo(&curr.AuthInfo, newAuthInfo, s); err != nil { return err } <ins> if *out == nil { *out = make(map[string]*api.AuthInfo) } </ins> if (*out)[curr.Name] == nil { (*out)[curr.Name] = newAuthInfo } else {

if err := Convert_v1_Context_To_api_Context(&curr.Context, newContext, s); err != nil { return err } <ins> if *out == nil { *out = make(map[string]*api.Context) } </ins> if (*out)[curr.Name] == nil { (*out)[curr.Name] = newContext } else {

if err := runtime.Convert_runtime_RawExtension_To_runtime_Object(&curr.Extension, &newExtension, s); err != nil { return err } <ins> if *out == nil { *out = make(map[string]runtime.Object) } </ins> if (*out)[curr.Name] == nil { (*out)[curr.Name] = newExtension } else {

} ) <ins> func TestNilOutMap(t *testing.T) { var fakeKubeconfigData = `apiVersion: v1 kind: Config clusters: - cluster: certificate-authority-data: UEhPTlkK server: https://1.1.1.1 name: production contexts: - context: cluster: production user: production name: production current-context: production users: - name: production user: auth-provider: name: gcp` _, _, err := clientcmdlatest.Codec.Decode([]byte(fakeKubeconfigData), nil, nil) if err != nil { t.Fatalf("unexpected error: %v", err) } } </ins> func TestNonExistentCommandLineFile(t *testing.T) { loadingRules := ClientConfigLoadingRules{ ExplicitPath: "bogus_file",
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! If the matter is security related, please disclose it privately via --What happened: In the to acquire AAD token, because of the inclusion of the API version in the URLs for authorization, the returned token is not compatible with many AAD scenarios like OIDC and On-Behalf-Of flow. There is a long list of issues documenting this problem: The fix is pretty simple, use with set to . This incompatible behavior impacts What you expected to happen: Follow the to acquire AAD token How to reproduce it (as minimally and precisely as possible): use kubectl to get AAD token, paste token into and verify the audience claim Anything else we need to know?: Environment: Kubernetes version (use ): all versions 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:
/area provider-azure
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /area provider-azure 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
/area provider/azure
/sig cli
/sig cloud-provider
/assign

Discussion:
return nil, err } <del> oauthConfig, err := adal.NewOAuthConfig(env.ActiveDirectoryEndpoint, token.tenantID) </del> <ins> oauthConfig, err := adal.NewOAuthConfigWithAPIVersion(env.ActiveDirectoryEndpoint, token.tenantID, nil) </ins> if err != nil { return nil, fmt.Errorf("building the OAuth configuration for token refresh: %v", err) }

} func (ts *azureTokenSourceDeviceCode) Token() (*azureToken, error) { <del> oauthConfig, err := adal.NewOAuthConfig(ts.environment.ActiveDirectoryEndpoint, ts.tenantID) </del> <ins> oauthConfig, err := adal.NewOAuthConfigWithAPIVersion(ts.environment.ActiveDirectoryEndpoint, ts.tenantID, nil) </ins> if err != nil { return nil, fmt.Errorf("building the OAuth configuration for device code authentication: %v", err) }

env.ServiceManagementEndpoint) } <del> oauthConfig, err := adal.NewOAuthConfig(env.ActiveDirectoryEndpoint, tenantID) </del> <ins> oauthConfig, err := adal.NewOAuthConfigWithAPIVersion(env.ActiveDirectoryEndpoint, tenantID, nil) </ins> if err != nil { return nil, fmt.Errorf("creating the OAuth config: %v", err) }
Change:
<!-- 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-e2e-gce Which test(s) are flaking: [sig-api-machinery] ResourceQuota should verify ResourceQuota with best effort scope. [Conformance] [sig-api-machinery] ResourceQuota should create a ResourceQuota and capture the life of a replication controller. [Conformance] [sig-api-machinery] ResourceQuota should verify ResourceQuota with terminating scopes. [Conformance] [sig-api-machinery] ResourceQuota should create a ResourceQuota and capture the life of a pod. [Conformance] [sig-api-machinery] ResourceQuota should create a ResourceQuota and capture the life of a secret. [Conformance] Testgrid link: Reason for failure: I'm guessing it's a timeout waiting for resource quota to get refreshed, eg: Anything else we need to know: links to specific failures /sig api-machinery /priority important-soon
/cc
For , observed the following in kube- around the above time period:
We hit today as well. FYI
/assign
failed with a timeout for PR . see:
FYI I figured out the problem by looking at the audit logs and seeing the "orphan" finalizer. We looked there due to observing successful PUTs to the RC's status after it was supposedly deleted.

Discussion:
framework.ExpectNoError(err) ginkgo.By("Deleting a ReplicationController") <del> err = f.ClientSet.CoreV1().ReplicationControllers(f.Namespace.Name).Delete(replicationController.Name, nil) </del> <ins> // Without the delete options, the object isn't actually // removed until the GC verifies that all children have been // detached. ReplicationControllers default to "orphan", which // is different from most resources. (Why? To preserve a common // workflow from prior to the GC's introduction.) err = f.ClientSet.CoreV1().ReplicationControllers(f.Namespace.Name).Delete(replicationController.Name, &metav1.DeleteOptions{ PropagationPolicy: func() *metav1.DeletionPropagation { p := metav1.DeletePropagationBackground return &p }(), }) </ins> framework.ExpectNoError(err) ginkgo.By("Ensuring resource quota status released usage")
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! If the matter is security related, please disclose it privately via --What happened: When preserve-destination annotation is set to true the routing mesh is getting disabled for actual traffic flow but the route mesh isn’t getting disabled for LB liveness probes. As a result the VM's which doesn't have active pods are looking healthy from the point of view of LB and getting active customer traffic. The VM's are dropping the traffic since the routing mesh is disabled. What you expected to happen: When preserve-destination annotation is set routing mesh should be disabled for LB liveness probes as well as end user traffic. How to reproduce it (as minimally and precisely as possible): Enable preserve-destination=true annotation in Azure k8s service and deploy an app that is registered with the service. Anything else we need to know?: Environment: Kubernetes version (use ): v1.15.1 Cloud provider or hardware configuration: Azure (ACS) OS (e.g: ): Windows 1903 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
Fixed by
Hey Yu-Ju this missed the 1.17 deadline and it’s a bug fix for the Windows preserve-destination feature. Can we back port this?
/sig node windows
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
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
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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

Discussion:
// If nodePort is specified, user should be able to use nodeIP:nodePort to reach the backend endpoints if svcInfo.nodePort > 0 { <ins> // If the preserve-destination service annotation is present, we will disable routing mesh for NodePort. // This means that health services can use Node Port without falsely getting results from a different node. nodePortEndpoints := hnsEndpoints if svcInfo.preserveDIP { nodePortEndpoints = hnsLocalEndpoints } </ins> hnsLoadBalancer, err := hns.getLoadBalancer( <del> hnsEndpoints, </del> <ins> nodePortEndpoints, </ins> loadBalancerFlags{localRoutedVIP: true}, sourceVip, "",
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! If the matter is security related, please disclose it privately via --What happened: Cannot mount azure disk on Standard_DC4s/DC2s instances details: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 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: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure

Discussion:
utilexec "k8s.io/utils/exec" ) <del> // exclude those used by azure as resource and OS root in /dev/disk/azure </del> <ins> // exclude those used by azure as resource and OS root in /dev/disk/azure, /dev/disk/azure/scsi0 // "/dev/disk/azure/scsi0" dir is populated in Standard_DC4s/DC2s on Ubuntu 18.04 </ins> func listAzureDiskPath(io ioHandler) []string { <del> azureDiskPath := "/dev/disk/azure/" </del> var azureDiskList []string <del> if dirs, err := io.ReadDir(azureDiskPath); err == nil { for _, f := range dirs { name := f.Name() diskPath := azureDiskPath + name if link, linkErr := io.Readlink(diskPath); linkErr == nil { sd := link[(libstrings.LastIndex(link, "/") + 1):] azureDiskList = append(azureDiskList, sd) </del> <ins> azureResourcePaths := []string{"/dev/disk/azure/", "/dev/disk/azure/scsi0/"} for _, azureDiskPath := range azureResourcePaths { if dirs, err := io.ReadDir(azureDiskPath); err == nil { for _, f := range dirs { name := f.Name() diskPath := filepath.Join(azureDiskPath, name) if link, linkErr := io.Readlink(diskPath); linkErr == nil { sd := link[(libstrings.LastIndex(link, "/") + 1):] azureDiskList = append(azureDiskList, sd) } </ins> } } }
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! If the matter is security related, please disclose it privately via --What happened: In below README files, URLs are written. But these URL include version name(master, release-1.0, etc...) which are enclosed in <and not shown in md files. What you expected to happen: URL will be shown correctly.
/sig storage
/remove-kind bug /kind documentation
can I take it up, as there is no activity for some days?
I already posted PR, thanks.

Discussion:
<del> The original file is https://github.com/kubernetes-csi/external-attacher/blob/<version>/deploy/kubernetes/rbac.yaml </del> <ins> The original file is https://github.com/kubernetes-csi/external-attacher/blob/VERSION/deploy/kubernetes/rbac.yaml </ins>

<del> The original file is https://github.com/kubernetes-csi/external-provisioner/blob/<version>/deploy/kubernetes/rbac.yaml </del> <ins> The original file is https://github.com/kubernetes-csi/external-provisioner/blob/VERSION/deploy/kubernetes/rbac.yaml </ins>

<del> The original file is https://github.com/kubernetes-csi/external-resizer/blob/<version>/deploy/kubernetes/rbac.yaml </del> <ins> The original file is https://github.com/kubernetes-csi/external-resizer/blob/VERSION/deploy/kubernetes/rbac.yaml </ins>

<del> The original file is https://github.com/kubernetes-csi/external-snapshotter/blob/<version>/deploy/kubernetes/rbac.yaml </del> <ins> The original file is https://github.com/kubernetes-csi/external-snapshotter/blob/VERSION/deploy/kubernetes/rbac.yaml </ins>
Change:
What happened: Unit test failed by command : What you expected to happen: How to reproduce it (as minimally and precisely as possible): Just run command . Anything else we need to know?: Happened on . I first met this issue at v1.15. Environment: Kubernetes version (use ):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:
/remove-kind bug /kind failing-test /sig cloud-provider
/area provider/gcp
I would be curious to know how is passing then
The reason is that is required here: I guess all CI machinery has a . This will fail in all environments without a .
ah, fixed in
Great!

Discussion:
"github.com/GoogleCloudPlatform/k8s-cloud-provider/pkg/cloud" compute "google.golang.org/api/compute/v1" <ins> option "google.golang.org/api/option" </ins> "k8s.io/client-go/tools/cache" )

// NewFakeGCECloud constructs a fake GCE Cloud from the cluster values. func NewFakeGCECloud(vals TestClusterValues) *Cloud { <del> service, _ := compute.NewService(context.Background()) </del> <ins> service, err := compute.NewService(context.Background(), option.WithoutAuthentication()) if err != nil { panic(err) } </ins> gce := &Cloud{ region:           vals.Region, service:          service,
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! If the matter is security related, please disclose it privately via --What happened: Kubemark cluster fails to be created when KUBEGCEPRIVATE_CLUSTER is set to false. What you expected to happen: Kubemark cluster should be created. How to reproduce it (as minimally and precisely as possible): Running ./start- script. Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig testing /sig scalability
/assign
IIUC the bug was introduced in The problem is with not being guarded with checking which causes the error:

Discussion:
REGION=$(grep -o "^[a-z]*-[a-z0-9]*" "${KUBE_TEMP}"/cluster-location.txt) MASTER_NAME="${KUBE_GCE_INSTANCE_PREFIX}"-master <del> MASTER_INTERNAL_IP=$(gcloud compute addresses describe "${MASTER_NAME}-internal-ip"  --project "${PROJECT}" --region "${REGION}" -q --format='value(address)') </del> <ins> if [[ ${GCE_PRIVATE_CLUSTER:-} == "true" ]]; then MASTER_INTERNAL_IP=$(gcloud compute addresses describe "${MASTER_NAME}-internal-ip"  --project "${PROJECT}" --region "${REGION}" -q --format='value(address)') fi </ins> MASTER_IP=$(gcloud compute addresses describe "${MASTER_NAME}-ip"  --project "${PROJECT}" --region "${REGION}" -q --format='value(address)')
Change:
<!-- 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: runcrdtests Testgrid link: Reason for failure: I am unfamiliar with this test, but the log suggests that the test did not properly wait for required resources to be available.
/sig cli api-machinery
/assign
the foo CR "test" with a Foreground delete, and it to be gone. However in those the foo CR "test" was still visible. I think this is caused by test running fast, and the garbage collector hasn't removed the object from REST API yet. I will send a fix to let the test to retry
Created . For the record the test failed 13 times since 2/14:
/reopen I will verify the test results in the next few days.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The test is green. /close
Closing this issue. <detailsIn response to : The test is green. 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

Discussion:
# apply --prune on bar.yaml that has bar/test kubectl apply --prune -l pruneGroup=true -f hack/testdata/CRD/bar.yaml "${kube_flags[@]}" --prune-whitelist=company.com/v1/Foo --prune-whitelist=company.com/v1/Bar # check right crds exist <del> kube::test::get_object_assert foos "{{range.items}}{{$id_field}}:{{end}}" '' </del> <ins> kube::test::wait_object_assert foos "{{range.items}}{{$id_field}}:{{end}}" '' </ins> kube::test::get_object_assert bars "{{range.items}}{{$id_field}}:{{end}}" 'test:' # Delete the resource