jiebi/CodeConvo huggingface dataset:
Change:
t.Errorf("%v: Unexpected error: %v", name, err) return } <ins> if item.reqHost != "" { req.Host = item.reqHost } </ins> resp, err := item.transport.RoundTrip(req) if err != nil { t.Errorf("%v: Unexpected error: %v", name, err)

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: When accessing a service (e.g., ) by using the Apiserver proxy feature and the service returns with header, such as The returned header does not preserve the path if the service sent a redirect with an absolute path. Depending on the cluster, the header written by the service itself might have been and the apiserver proxy did rewrite the host:port to match the correct values. Unfortunately, it did not rewrite the path segment. What you expected to happen: I would expect the apiserver to rewrite the path segment of the response header so that it reflects the fact that it's proxied under the path: How to reproduce it (as minimally and precisely as possible): The path was not preserved. Anything else we need to know?: To work around this issue, a service may return strictly a relative url in the header such as: The feature to rewrite headers is quite common. For instance, Apache Httpd does it thanks to: Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: custom_ OS (e.g. from /etc/os-release): Kernel (e.g. ):
/sig api-machinery /sig network
/assign
Thanks for the bug report!
GitHub didn't allow me to assign the following users: roycaihw. Note that only can be assigned. <detailsIn response to : /assign 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:
// TestBootstrapTokenAuth tests the bootstrap token auth provider func TestBootstrapTokenAuth(t *testing.T) { <del> tokenID, err := bootstraputil.GenerateTokenID() if err != nil { t.Fatalf("unexpected error: %v", err) } secret, err := bootstraputil.GenerateTokenSecret() if err != nil { t.Fatalf("unexpected error: %v", err) } </del> <ins> validTokenID := "token1" validSecret := "validtokensecret" </ins> var bootstrapSecretValid = &corev1.Secret{ ObjectMeta: metav1.ObjectMeta{ Namespace: metav1.NamespaceSystem,

Discussion:
Originally tracked at . After fixing "not include test files in import-boss" in , we have a regression here: is using . We need remove dependencies from integration tests to e2e tests again. /assign /sig testing
/sig auth as per the required change
/kind cleanup /area test
It would be helpful to outline an argument as to why this is the case. I can imagine reasons, but none are mentioned here.
Description updated.
/triage accepted /priority backlog /milestone v1.21 This seems a simple enough fix to land (and thank you for doing this) but marking low enough priority to make it clear we may back out and wait for v1.22 if we don't have bandwidth for this
So while I think we should probably do this anyhow I want to note: This issue lists the reasons: we have no intention to stage e2e (there's been much discussion about this since then) we generally don't want anything non-informational (required jobs) running only sometimes anyhow, it's just not reliable Decoupling these seems like a good idea from a purely code-organization perspective, but the reasons in the previous issue are no longer valid.
/milestone v1.22 The PR didn't land in time. At this point I view this as nice to have. Even if it's low impact, let's wait until next release.
Change:
t.Fatalf(`expected error "%s"`, expectedError) } <ins> func TestDontAllowForceApplyWithServerSide(t *testing.T) { expectedError := "error: --force cannot be used with --server-side" cmdutil.BehaviorOnFatal(func(str string, code int) { panic(str) }) defer func() { actualError := recover() if expectedError != actualError { t.Fatalf(`expected error "%s", but got "%s"`, expectedError, actualError) } }() tf := cmdtesting.NewTestFactory().WithNamespace("test") defer tf.Cleanup() tf.ClientConfigVal = cmdtesting.DefaultClientConfig() ioStreams, _, _, _ := genericclioptions.NewTestIOStreams() cmd := NewCmdApply("kubectl", tf, ioStreams) cmd.Flags().Set("filename", filenameRC) cmd.Flags().Set("server-side", "true") cmd.Flags().Set("force", "true") cmd.Run(cmd, []string{}) t.Fatalf(`expected error "%s"`, expectedError) } </ins> func TestDontAllowApplyWithPodGeneratedName(t *testing.T) { expectedError := "error: from testing-: cannot use generate name with apply" cmdutil.BehaviorOnFatal(func(str string, code int) {

Discussion:
What happened: A resource is not replaced (deleted and recreated) when passing the flag to and the change cannot be applied. What you expected to happen: I expected the service to be replaced. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ):
/sig api-machinery /wg api-expression
/sig cli
/cc
Good to know, that's certainly worthy of a fix.
/cc
This is slightly related: If we want to support we could try and make the behavior clearer.
Can you weigh in on how important this is? We feel that is super, super dangerous in general. It's also very easy to confuse it with for server side apply, so it's extra dangerous. Do we need to implement this field for this command? Can we give an error, like "use one of: --force-conflicts or --delete-then-create"? Can SIG CLI do something about this flag in general?
/cc
Noted, I'll make sure this is in the agenda for the next sig-cli meeting.
I don't think the two are related. is now error-ing when used with , but it'll still fail with server-side apply.
You're right... my recall was bad. I deleted my comment where I thought was this, but it is not. Sorry about that
Looks like in the SIG-CLI meeting it was decided to not enable the user to use the and flag together. kubectl should fail immediately with a warning that should not be used with server side apply. Do you mind if I start working on this issue? I will reach out to you and other members of the SIG to get more details needed. I am a new contributor to k8s and would like to work on this issue.
Thanks for summarizing the discussion! I'd love to see you submit a PR for that, that's awesome!
/assign /lifecycle-active
Change:
// Testing a 1.17 version of the sample-apiserver TestSampleAPIServer(f, aggrclient, imageutils.GetE2EImage(imageutils.APIServer)) }) }) func cleanTest(client clientset.Interface, aggrclient *aggregatorclient.Clientset, namespace string) {

Discussion:
[x] test pr : kuberenetes/kubernetes# [x] two weeks soak start date : testgrid-link [x] two weeks soak end date : [x] test promotion pr : kubernetes/kubernetes#? According to this APIsnoop query, there are still some remaining APIService endpoints which are untested. With this query you can filter untested endpoints by their category and eligiblity for conformance. e.g below shows a query to find all conformance eligible untested,stable,core endpoints Addressing the following endpoints in this document; Using the current e2e test as a template, create an APIService for Using the REST client, read the APIService status (readApiregistrationV1APIServiceStatus) and confirm the value of . Using the REST client, patch the APIService (patchApiregistrationV1APIService) before confirming that it has been updated. Using the REST client, list all APIServices in the cluster (listApiregistrationV1APIService) before confirming that can be found. Clean up APIService resources used by the test. Due to the complexity of setting up the resources for APIService we have used the current e2e test as template. It has been extended in a for review. This query shows the endpoints hit within a short period of running the e2e test example endpoint | useragent ---------------------------------------|
createApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 deleteApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 listApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 patchApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 readApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 readApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator2 (6 rows) Based on the initial APIsnoop query and the results listed above there are three new endpoints hit.

If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
Change:
as.Equal(len(runContainerOpts.Devices), len(expectedResp.Devices)) as.Equal(len(runContainerOpts.Mounts), len(expectedResp.Mounts)) as.Equal(len(runContainerOpts.Envs), len(expectedResp.Envs)) <ins> pod2 := makePod(v1.ResourceList{ v1.ResourceName(res1.resourceName): *resource.NewQuantity(int64(0), resource.DecimalSI)}) activePods = append(activePods, pod2) podsStub.updateActivePods(activePods) err = testManager.Allocate(pod2, &pod2.Spec.Containers[0]) as.Nil(err) _, err = testManager.GetDeviceRunContainerOptions(pod2, &pod2.Spec.Containers[0]) as.Nil(err) select { case <-time.After(time.Millisecond): t.Log("When pod resourceQuantity is 0,  PreStartContainer RPC stub will be skipped") case <-ch: break } </ins> } func TestResetExtendedResource(t *testing.T) {

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: When I register a device plugin and set the option in true, then when I create a pod and specify this resource as 0 in yaml, an error will be reported. Examples are as follows. The request to register the device pluginA pod yaml with the resource 0kubelet return error What you expected to happen: I think when the kubelet calls , the resource value should be checked. If it is 0, the step should be skipped to avoid errors. How to reproduce it (as minimally and precisely as possible): Register a device plugin which set option is true Create a pod with the above resource 0 Anything else we need to know?: In fact, when the amount of requested resources is 0, devicemanager will get the number of allocated devices as nil, resulting in the internal cache not storing the application resource information corresponding to the container. But if is set to true at the same time, then devicemanager will check podDevices cache. The two processing steps contradict each other so it will return an error.
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 node
Change:
return "", err } <del> return fmt.Sprintf("%d.%d.%s.%dn", majorVersionNumber[0], minorVersionNumber[0], buildNumber, revision), nil </del> <ins> return fmt.Sprintf("%d.%d.%s.%d", majorVersionNumber[0], minorVersionNumber[0], buildNumber, revision), nil </ins> } // getOSImageVersion gets the osImage name and version.

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!--What happened: Was adding automation using node output and was unable to parse json from nodes due to newline in kernel version: What you expected to happen: json returned from to be valid json (no new lines). How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: /sig windows Environment: Kubernetes version (use ): 1.13 Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release):Windows Server version 1809 Kernel (e.g. ): 10.0..194 Install tools: acs-engine master
Do you have the raw json output by ? An escaped newline in a quoted string is valid json, though trimming it for windows would still probably be fine
might be turning n into an actual newline and causing your issues. the first output in the PR description is valid json
The raw json is: <details<summarykubectl get nodes -l "" -o json </summary</detailsI think you are correct that it was the echo that turning n into a an actual new line. Any idea why there would in a new line in the output like that? Is is safe to remove it as I did in my PR ()?
I also just noticed that the output from as is formated incorrectly because the new line is the kernel version (the container runtime ends up on second line):
yeah, newlines would screw up the human readable output, which is ugly, but aren't an API issue, which would be much more urgent. trimming the newline in the data source seems reasonable to me, but it was clearly explicitly so I would recommend hunting down the original reason for that to be sure
Change:
mustFail bool err      error }{ <ins> {testName: "supported version", ver: &csipb.Version{Major: 0, Minor: 0, Patch: 0}}, </ins> {testName: "supported version", ver: &csipb.Version{Major: 0, Minor: 1, Patch: 0}}, <del> {testName: "unsupported version", ver: &csipb.Version{Major: 0, Minor: 0, Patch: 0}, mustFail: true}, </del> <ins> {testName: "supported version", ver: &csipb.Version{Major: 0, Minor: 1, Patch: 10}}, {testName: "supported version", ver: &csipb.Version{Major: 1, Minor: 1, Patch: 0}}, {testName: "supported version", ver: &csipb.Version{Major: 1, Minor: 0, Patch: 10}}, {testName: "unsupported version", ver: &csipb.Version{Major: 10, Minor: 0, Patch: 0}, mustFail: true}, {testName: "unsupported version", ver: &csipb.Version{Major: 0, Minor: 10, Patch: 0}, mustFail: true}, </ins> {testName: "grpc error", ver: &csipb.Version{Major: 0, Minor: 1, Patch: 0}, mustFail: true, err: errors.New("grpc error")}, }

Discussion:
/kind bug What happened: Kubelet CSI client checks for an exact version match. What you expected to happen: Kubelet CSI client checks for a Major.Minor.X match. It should not check that the patch level matches. cc:
/sig storage
Change:
cn = fmt.Sprintf("debugger-%s", nameSuffixFunc(5)) } if !o.Quiet { <del> fmt.Fprintf(o.ErrOut, "Defaulting debug container name to %s.n", cn) </del> <ins> fmt.Fprintf(o.Out, "Defaulting debug container name to %s.n", cn) </ins> } name = cn }

Discussion:
This issue tracks implementing node debugging with privileged containers for , as described in the This feature allows administrators to start a privileged container on a node in host namespaces rather than having to SSH to the node. For example: /kind feature /sig cli
/assign
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
Change:
// NewRequest creates a new request helper object for accessing runtime.Objects on a server. func NewRequest(client HTTPClient, verb string, baseURL *url.URL, apiVersion string, codec runtime.Codec, namespaceInQuery bool, preserveResourceCase bool) *Request { <ins> metrics.Register() </ins> return &Request{ client:  client, verb:    verb,

Discussion:
Currently we do not measure latency for REST operations. This is important for any component that performs non-watch operations (scheduler, controllers, kubelet). This is also prerequisite to actually make sure that all API calls take less than 1 sec ( ).
The apiserver is already , including for REST operations. You can scrape the metrics by hitting the /metrics HTTP endpoint.
Sorry, I was not clear in the description. I'm more interested on the client side and with more details so that I can measure things like: how long it takes to write bindings in scheduler how long it takes to update status in kubelet I'd think about it as a counterpart for apiserver stats.
Change:
<del> apiVersion: v1 kind: Pod metadata: name: dns-frontend labels: name: dns-frontend spec: containers: - name: dns-frontend image: registry.k8s.io/example-dns-frontend:v1 command: - python - client.py - http://dns-backend.development.svc.cluster.local:8000 imagePullPolicy: Always restartPolicy: Never </del>

Discussion:
master-blocking: gce-cos-master-alpha-featuresKubernetes e2e suite:Failed runs: 09-16 09:58 CDT 09-15 23:41 CDT Both of these runs were on the same commit which also has passing builds. The test fails due to a , specifically when attempting to connect to the DNS backend service . The error indicates that the DNS backend service is either not running or not accessible on the specified address and port. This caused multiple retries in the test, with the pod failing to establish a connection to the backend service each time. As a result, the expected output "Hello World!" was not found in the logs, leading to the failure of the test. The service being unreachable could be due to several potential issues: misconfigured DNS, networking issues within the cluster, or the DNS backend service failing to start properly.Further investigation into the DNS service deployment and networking might be required to resolve this issue. There were two other failures ( , ) on the same commit that seemed to be related to cluster instance not being found: This caused failure when attempting to SSH into the instance and retrieve logs (kube-, , etc.). For those, the cluster setup (e2e-) likely failed, as no nodes were found, resulting in no instances being available. /sig network /kind flake cc:
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 network /kind flake
This test should not be running in this job, it was picked recently ! since we already have coverage I think is better to remove it, is also using images that the sources are not available anymore
Change:
srcs = [ "azure_acr_helper.go", "azure_credentials.go", <ins> "doc.go", </ins> ], importpath = "k8s.io/kubernetes/pkg/credentialprovider/azure", deps = [

Discussion:
make verify WHAT=typecheck-providerless outputs /cc /milestone v1.19
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
see example successful run:
For reference -
fix in
screaming
Change:
vm.StorageProfile.DataDisks = &disks ctx, cancel := getContextWithCancel() defer cancel() <del> glog.V(2).Infof("azureDisk - update(%s): vm(%s) - detach disk", nodeResourceGroup, nodeName) resp, err := ss.VirtualMachineScaleSetVMsClient.Update(ctx, nodeResourceGroup, ssName, instanceID, vm) if ss.CloudProviderBackoff && shouldRetryHTTPRequest(resp, err) { glog.V(2).Infof("azureDisk - update(%s) backing off: vm(%s)", nodeResourceGroup, nodeName) retryErr := ss.UpdateVmssVMWithRetry(ctx, nodeResourceGroup, ssName, instanceID, vm) if retryErr != nil { err = retryErr glog.V(2).Infof("azureDisk - update(%s) abort backoff: vm(%s)", nodeResourceGroup, nodeName) } } if err != nil { glog.Errorf("azureDisk - azure disk detach %q from %s failed, err: %v", diskName, nodeName, err) </del> <ins> glog.V(2).Infof("azureDisk - update(%s): vm(%s) - detach disk(%s)", nodeResourceGroup, nodeName, diskName) if _, err := ss.VirtualMachineScaleSetVMsClient.Update(ctx, nodeResourceGroup, ssName, instanceID, vm); err != nil { glog.Errorf("azureDisk - detach disk(%s) from %s failed, err: %v", diskName, nodeName, err) </ins> } else { <del> glog.V(4).Info("azureDisk - azure detach succeeded") </del> <ins> glog.V(2).Infof("azureDisk - detach disk(%s) succeeded", diskName) </ins> // Invalidate the cache right after updating key := buildVmssCacheKey(nodeResourceGroup, ss.makeVmssVMName(ssName, instanceID)) ss.vmssVMCache.Delete(key)

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!--What happened: retry azure disk attach operation produce too many API calls Not the default value is 6 which means if AttachDisk operation failed, it will retry 6 more times, when disk quota is full on a VM, it produces too many API calls. Retry attach disk behavior is not necessary since it AttachVolume operation fails, k8s attachdetach-controller will retry once a minute until it succeeds. default setting in 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 ): v1.10, v1.11, v1.12 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug /sig azure /assign
Change:
/* <del> Copyright 2017 The Kubernetes Authors. </del> <ins> Copyright 2018 The Kubernetes Authors. </ins> Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.

Discussion:
Happy New Year! Now when I run make I get a diff like this in every zz_generated file: Not sure what a smart solution is, but we could merge something like in the meantime.
Change:
DummyDiskName         = "kube-dummyDisk.vmdk" ProviderPrefix        = "vsphere://" vSphereConfFileEnvVar = "VSPHERE_CONF_FILE" <ins> UUIDPrefix            = "VMware-" </ins> ) // GetVSphere reads vSphere configuration from system environment and construct vSphere object

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: Running the vSphere cloud provider on a windows node throws the following error: This is because the vm identifier is retrieved with the command - , which assumes that the uuid and serial are the same. On some vmware vm versions, the uuid and serial are not the same. vmware (comment), vmware (comment) What you expected to happen: Kubelet is able to find vm in vCenter from the identifier looked up on the node. or should be used instead to find the vm identifier. How to reproduce it (as minimally and precisely as possible): Issue only occurs on some vm versions, such as 13. Anything else we need to know?: On the linux side, this issue was resolved by switching from looking up the id from to . See Some discussion about this issue here - Environment: Kubernetes version (use ): 14.0-beta.1 Cloud provider or hardware configuration: Vsphere OS (e.g: ): Windows 2019 Kernel (e.g. ): Install tools: Others:
/sig windows /sig vmware
/milestone v1.14
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility. <detailsIn response to : /milestone v1.14 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
/assign