jiebi/CodeConvo huggingface dataset:
Change:
return filteredDisks } <ins> func (c *controllerCommon) filterNonExistingDisks(ctx context.Context, unfilteredDisks []compute.DataDisk) []compute.DataDisk { filteredDisks := []compute.DataDisk{} for _, disk := range unfilteredDisks { filter := false if disk.ManagedDisk != nil && disk.ManagedDisk.ID != nil { diskURI := *disk.ManagedDisk.ID exist, err := c.cloud.checkDiskExists(ctx, diskURI) if err != nil { klog.Errorf("checkDiskExists(%s) failed with error: %v", diskURI, err) } else { // only filter disk when checkDiskExists returns <false, nil> filter = !exist if filter { klog.Errorf("disk(%s) does not exist, removed from data disk list", diskURI) } } } if !filter { filteredDisks = append(filteredDisks, disk) } } return filteredDisks } func (c *controllerCommon) checkDiskExists(ctx context.Context, diskURI string) (bool, error) { diskName := path.Base(diskURI) resourceGroup, err := getResourceGroupFromDiskURI(diskURI) if err != nil { return false, err } if _, rerr := c.cloud.DisksClient.Get(ctx, resourceGroup, diskName); rerr != nil { if rerr.HTTPStatusCode == http.StatusNotFound { return false, nil } return false, rerr.Error() } return true, nil } </ins> func getValidCreationData(subscriptionID, resourceGroup, sourceResourceID, sourceType string) (compute.CreationData, error) { if sourceResourceID == "" { return compute.CreationData{

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: check disk status before disk azure disk There is little possibility that attach disk would cost 10min, and disk could be attached, deleted in same time, that would cause race condition. 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
Change:
import ( "fmt" "path/filepath" <del> "strings" </del> "k8s.io/klog/v2" )

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Before node e2e tests are started, iptables rules are applied. The rules aren't correctly applied for some OSes like, Fedora CoreOS. Which test(s) are failing: node e2e tests that depend on communication between the containers tend to fail on Fedora CoreOS where the iptable rules don't get applied properly before starting the tests. Since when has it been failing: Probably always. I am in the process of fixing issues that I am seeing on Fedora CoreOS. Testgrid link: Reason for failure: The test infra currently checks if is to or not. But like in case of Fedora CoreOS, the iptables policy might be but it still lacks the individual rule for , and . In that case, since the iptables policy is not the test infra doesn't attempt to add any required iptable rules for , and . To fix this we need to see if the iptable policy is not set to plus check if the rules of , and are actually present or not. Anything else we need to know:
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
/assign
Change:
}, "secure, no roots": { TLSConfig:   &tls.Config{InsecureSkipVerify: false}, <del> ExpectError: "unknown authority", </del> <ins> ExpectError: "unknown authority|not trusted", </ins> }, "secure with roots": { TLSConfig: &tls.Config{InsecureSkipVerify: false, RootCAs: roots},

Discussion:
unit tests since switching to go1.18 No response No response Weirdly, the test is passing in CI () and failing locally /sig api-machinery auth testing
seems related Jordan, are you using mac ?
yes, though the description in that issue seems to be not just test-only changes to the errors received from invalid certificates (which is what I saw), but actual certificates that previously validated
marking as release blocker until it is determined that go1.18 is not rejecting valid certificates
this needs an assignee and a reproducer we can file as an upstream issue for golang to ask why previously valid certificates now fail validation
marking critical until root-caused and determined whether this is prod-impacting, since (in my opinion) this should block rc0
On linux it works fine: on MacOS, it fails:
Looks like the change in golang that broke the scenario was:
if the only impact is a different failure message on an already-invalid certificate, I don't care and we can update the test to accept either message is what makes me wonder what previously-accepted certificates are now failing
reproducer test case here. this one has no issues under go 1.17 and fails with go 1.18 (stripped down version of ) : :
the new error message is minted here: i suspect it is related to: So essentially this seems to be something that may hit in our case. right?
yeah, if this is scoped to just darwin clients, and only ones using system roots, that greatly narrows the impact
Asked on gophers slack -
xref:
opened to tolerate the additional errors discussion in indicates the tightened validation is very bounded (darwin-only, so clients-only, system roots only), and certificates issued by public CAs would be expected to pass this validation dropping release-blocking label and priority to important-soon, but should still make it into 1.24 to make unit tests pass locally
Change:
// according to https://docs.microsoft.com/en-us/rest/api/compute/disks/get func getResourceGroupFromDiskURI(diskURI string) (string, error) { fields := strings.Split(diskURI, "/") <del> if len(fields) != 9 || fields[3] != "resourceGroups" { </del> <ins> if len(fields) != 9 || strings.ToLower(fields[3]) != "resourcegroups" { </ins> return "", fmt.Errorf("invalid disk URI: %s", diskURI) } return fields[4], nil

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: azure resource id should be case insensitve, while some places are case sensitve: 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: /sig azure /assign
Change:
func (az *Cloud) getPublicIPAddressResourceGroup(service *v1.Service) string { if resourceGroup, found := service.Annotations[ServiceAnnotationLoadBalancerResourceGroup]; found { <del> return resourceGroup </del> <ins> resourceGroupName := strings.TrimSpace(resourceGroup) if len(resourceGroupName) > 0 { return resourceGroupName } </ins> } return az.ResourceGroup

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: LoadBalancer is stuck on pending state when annotation azure-load-balancer-resource-group is set to empty string. The error would be: Though the error message introduces some confusion here, it's actually because the resourceGroup name is missing when cloud provider trying to list publicIPs: What you expected to happen: The service should be provisioned successfully. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.12.8 Cloud provider or hardware configuration: Azure OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig azure /kind bug /priority critical-urgent
/assign
Change:
diskName := av.volumeName[(strings.LastIndex(av.volumeName, "/") + 1):] <ins> kind := v1.AzureManagedDisk </ins> pvSource := v1.PersistentVolumeSource{ AzureDisk: &v1.AzureDiskVolumeSource{ DiskName:    diskName, DataDiskURI: av.volumeName, <ins> Kind:        &kind, </ins> ReadOnly:    &readOnly, }, }

Discussion:
I am trying to run Azure e2e tests: The test creates a volume in the cloud + runs a pod with the volume as in-line. The pod never starts: The test creates a "blob" disk, while the Azure machine expects "managed" disk. Does anyone run storage e2e tests on Azure regularly? Was it ever working? Managed disks are provisioned . Should the test suite create "managed" disks by default too? Environment: Kubernetes version (use ): v1.17.0-alpha.0.1089+-dirty
/sig azure
/sig cloud-provider
managed disk should be the default, the azure disk storage class in the test case may have
The volume is created outside of kubernetes dynamic provisioning to test pre-provisioned and inline volumes: I wonder if anyone actually runs the tests.
Change:
// with gingko.BeforeEach/AfterEach/DeferCleanup. // // When a test runs, functions will be invoked in this order: <ins> // - BeforeEaches defined by tests before f.NewDefaultFramework //   in the order in which they were defined (first-in-first-out) </ins> // - f.BeforeEach <del> // - all BeforeEaches in the order in which they were defined (first-in-first-out) </del> <ins> // - BeforeEaches defined by tests after f.NewDefaultFramework </ins> // - It callback // - all AfterEaches in the order in which they were defined // - all DeferCleanups with the order reversed (first-in-last-out) // - f.AfterEach <ins> // // Because a test might skip test execution in a BeforeEach that runs // before f.BeforeEach, AfterEach callbacks that depend on the // framework instance must check whether it was initialized. They can // do that by checking f.ClientSet for nil. DeferCleanup callbacks // don't need to do this because they get defined when the test // runs. </ins> NewFrameworkExtensions []func(f *Framework) )

Discussion:
After merged, build logs for e2e tests have started showing stack traces that look like: It seems like the used in this is nil I have a suspicion this is happening for storage tests that skip No new stack traces in build logs Run e2e tests against the in-development version of kubernetes I identified when this started happening by looking for an increase in build-log size is the first build where this started happening, which happens to be the first build after merged, which is the PR that introduced this new way of invoking <details</details<details</details<details</details<details</details<details</details<details</details
/sig testing /triage accepted /assign To put this on your radar
/cc
Correct. This happens because of the ordering in Tests gets skipped before is called. This avoids the expensive namespace creation/deletion for tests that don't need to run. The for then gets executed although the framework didn't get initialized. My preferred solution is to document that the framework instance might not be initialized in an AfterEach callback and add a nil check to .
See Only was affected. The other framework extensions use DeferCleanup, which only runs when needed.
Change:
err) } } else { <del> // If volume is not safe to detach (is mounted) wait a max amount of time before detaching any way. </del> <ins> // If volume is not safe to detach (is mounted) wait a max amount of time before detaching anyway. </ins> if timeElapsed > rc.maxWaitForUnmountDuration { glog.V(5).Infof("Attempting to start DetachVolume for volume %q from node %q. Volume is not safe to detach, but maxWaitForUnmountDuration expired.", attachedVolume.VolumeName, attachedVolume.NodeName) err := rc.attacherDetacher.DetachVolume(attachedVolume.AttachedVolume, false /* verifySafeToDetach */, rc.actualStateOfWorld)

Discussion:
Looks like similar issue with
That's the PV controller this is the attach controller, thus separate issues.
Change:
} waitGroup.Wait() <del> verifyCalls(t, fakeDocker, []string{ </del> <ins> verifyUnorderedCalls(t, fakeDocker, []string{ </ins> "list", "list", "list", "list", "inspect_container", "inspect_container", "list", "inspect_container", "inspect_container", "stop", "create", "start", "inspect_container", "create", "start", "list", "inspect_container", "inspect_container"}) // A map iteration is used to delete containers, so must not depend on

Discussion:
Seeing random failures.
Looks like lately refactory makes docker API requests are not deterministic. Will look into it.
Any update? It seems to be failing a lot.
I just looked into this and found that is the only test that there are two pods in the which is fed to I think podworker was syncing the two pods in parallel, this causes non-deterministic behaviour I have tried , no errors. , error happens continuously. I can try to fix this :)
Yes, that is what I believe here, but never have time working on it. Thanks for looking into this, and re-assign it to you.
I saw your old PR for this, I think we still need to keep the parallel sync here. Just need to create a for this case :)
Change:
import ( "fmt" "math" <del> "path" </del> <ins> "path/filepath" </ins> "strconv" "strings" "time"

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: [sig-storage] In-tree Volumes [Driver: hostPath] [Testpattern: Inline-volume (default fs)] volumeIO should write files of various sizes, verify size, validate content [Slow] Since when has it been failing: 11/13 Testgrid link: https://k8s- Reason for failure: Anything else we need to know: This is consistently failing in 1.13 branch and is release blocking. <!-- DO NOT EDIT BELOW THIS LINE --/kind failing-test /sig storage /priority critical-urgent /milestone v1.13 /assign /cc
The test case is failing because it wrote 2MB instead of the expected 1MB. It's also very odd that the test is failing in soak, but passing in regular CI suites.
There's a few problems: .GetVolumeSource returns "/tmp" for everything. This means all tests will share the same directory. This should be probably use some unique directory instead volume IO test generates a unique mountPath directory, however that doesn't mean a unique directory is actually created on the host. Ie, a mountPath of "/a/b/c" on a hostpath volume at "/tmp" doesn't mean directory "/tmp/a/b/c" is created. io test file name is not unique seems like the IO test is not cleaning up the files it creates, so the files are getting reused on subsequent tests due to the non-unique naming issues.
The other thing I can't explain is why it's failing only now
Fix is here:
As per discussion in 1.13 burndown this morning, this is a test job issue and its not release blocking at this point. So we can take this fix in 1.14 as opposed now during code freeze let us know if you feel otherwise
/milestone v1.14 /priority important-soon
/remove-priority critical-urgent
Change:
} } <del> json, err := runtime.Encode(r.codecs.LegacyCodec(), discoveryGroupList) if err != nil { http.Error(w, err.Error(), http.StatusInternalServerError) return } if _, err := w.Write(json); err != nil { panic(err) } </del> <ins> responsewriters.WriteObjectNegotiated(r.codecs, schema.GroupVersion{}, w, req, http.StatusOK, discoveryGroupList) </ins> } // convertToDiscoveryAPIGroup takes apiservices in a single group and returns a discovery compatible object.

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): build--5-v1.7.5-3 Environment: Cloud provider or hardware configuration: Laptop (bare metal) OS (e.g. from /etc/os-release): Fedora 26 Kernel (e.g. ): Linux localhost.localdomain 4.11.0-0.rc6.git0.1.fc26.x8664 SMP Mon Apr 10 19:45:50 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: make && hack/local-cluster- -o _output/bin What happened: built from and ran with local-cluster- All commands gave the following error: Running showed the output: What you expected to happen: for commands to work, and Content-type to show How to reproduce it (as minimally and precisely as possible):
ccing
I see the text plain content type, but not kubectl errors
i was using the wrong version of kubectl. updated to new and i'm not getting an error any longer.
Text/plain coming back from the server is still an issue
cc
I'm not seeing against head and the pastebin is gone. Did you reproduce?
I did last week. Insecure and secured port behaved differently
You can reproduce this using against a Kubernetes cluster built from HEAD
Hi all, I think we could use write Content-type correctly. I have made a PR to fix this.
Change:
proxier.mu.Lock() defer proxier.mu.Unlock() <del> start := time.Now() defer func() { SyncProxyRulesLatency.Observe(metrics.SinceInSeconds(start)) klog.V(4).InfoS("Syncing proxy rules complete", "elapsed", time.Since(start)) }() </del> // don't sync rules till we've received services and endpoints if !proxier.isInitialized() { klog.V(2).InfoS("Not syncing hns until Services and Endpoints have been received from master") return } <ins> // Keep track of how long syncs take. start := time.Now() defer func() { metrics.SyncProxyRulesLatency.Observe(metrics.SinceInSeconds(start)) klog.V(4).InfoS("Syncing proxy rules complete", "elapsed", time.Since(start)) }() </ins> hnsNetworkName := proxier.network.name hns := proxier.hns

Discussion:
function on is not being used, and kproxy metrics are not showing on endpoint. See kube-proxy related metrics. Access kube-proxy on and search for kube-proxy specific metrics. No response <detailsKube-proxy build from master </details<details</details<details</details<details</details<details</details<details</details
/sig windows
/triage accepted /priority important-soon
/milestone v1.24
Change:
# List all allowed actions in namespace "foo" kubectl auth can-i --list --namespace=foo`) <ins> resourceVerbs       = sets.NewString("get", "list", "watch", "create", "update", "patch", "delete", "deletecollection", "use", "bind", "impersonate", "*") nonResourceURLVerbs = sets.NewString("get", "put", "post", "head", "options", "delete", "patch", "*") </ins> ) // NewCmdCanI returns an initialized Command for 'auth can-i' sub command

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 using kubectl auth can-i <verb<resourcesthe "verb" isn't check and returns yes on any resource regardless of what the verb is. What you expected to happen: I expected the cli to register an error like when you don't have enough arguments. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): client version GitVersion: 1.19.2 server version: GitVersion: 1.19.0 Cloud provider or hardware configuration: Mac OS X OS (e.g: ): n/a Kernel (e.g. ): Darwin Install tools: brew Network plugin and version (if this is a network-related bug): n/a Others:
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
This is working as intended. The authorization layer can answer questions about arbitrary verbs, and the response to can-i mirrors the response you would get from a subjectaccessreview permission check. Getting a "yes" response to arbitrary verbs likely means you are a superuser and would be authorized for any operation.
Wouldn't a superuser only have access to the Kubernetes verbs that exist and not the arbitrary verbs that it is allowed to query that is defined here () This seems to go against the selfsubjectaccessreview which will return a set of actions that a user can perform. Arbitrary verbs seem like they shouldn't be allowed from that definition.
No, the cluster-admin superuser role allows verbs which allows any verb
Change:
if err != nil { t.Fatalf("expected to open %s, got %v", lockPath16x, err) } <del> defer runLock.Close() </del> <ins> defer func() { runLock.Close() os.Remove(lockPath16x) }() </ins> if err := grabIptablesFileLock(runLock); err != nil { t.Errorf("expected to lock %s, got %v", lockPath16x, err)

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: files like: are being created, I think from the "unit" tests. What you expected to happen: running tests should not leave files in tree, especially not tracked by git! How to reproduce it (as minimally and precisely as possible): ? I think? Anything else we need to know?: spotted in a PR commit 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 network /assign
I'm also finding an file while working on this locally??? /triage accepted
I suspect , which introduced these lockfile paths and removed deferred removal
is a simple approach to mitigate, but it doesn't solve cluttering the source tree with leaked files. I'm not sure we actually want to take that approach.