jiebi/CodeConvo huggingface dataset:
Change:
MUST cause pods created by that RC to be orphaned. release: v1.9 file: test/e2e/apimachinery/garbage_collector.go <ins> - testname: Namespace, apply finalizer to a namespace codename: '[sig-api-machinery] Namespaces [Serial] should apply a finalizer to a Namespace [Conformance]' description: Attempt to create a Namespace which MUST be succeed. Updating the namespace with a fake finalizer MUST succeed. The fake finalizer MUST be found. Removing the fake finalizer from the namespace MUST succeed and MUST NOT be found. release: v1.26 file: test/e2e/apimachinery/namespace.go </ins> - testname: Namespace, apply update to a namespace codename: '[sig-api-machinery] Namespaces [Serial] should apply an update to a Namespace [Conformance]'

Discussion:
[X] Test approval issue: [X] Test PR: 15 Oct 2022 [X] Two weeks soak end date: 28 Oct 2022 [X] Test promotion PR: According to this APIsnoop query, there are still one remaining Namespace endpoint which is untested. replaceCoreV1NamespaceFinalize Note: The test also removes the fake finalize from before calling the finalize action on the test namespace a second time. This will allow the test framework to clean up all namespaces when the e2e finishes, else the test namespace will be stuck in the state. Using a number of existing e2e test practices a new has been created for one Namespace endpoint. The e2e logs for this test are listed below. This query shows that the Finalize endpoint is hit within a short period of running this e2e test If a test with these calls gets merged, test coverage will go up by 1 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
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
Change:
driverName: driverName, } if shouldTimeout { <del> timeout := plugin.PluginClientTimeout + 10*time.Millisecond </del> <ins> timeout := plugin.PluginClientTimeout + 30*time.Millisecond </ins> fakeDRADriverGRPCServer.timeout = &timeout }

Discussion:
test Since Oct 25th No response stack trace: Test has been flaking with master golang as well. /sig node
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
seems like we need to increase the timeout.. /assign
I tried with different values of timeout in function viz and running test binary using stress tool. In most cases, test is getting passed.
Flake in master blocking board: /cc
Flake in as well.
is waiting for approve been a while, which try to fix the flake
We can still observe this flakiness with 30ms timeout in CI Wondering, if timeout has to be increased further. Please let us know if more information is required.
It flaked in today as well. /reopen
Reopened this issue. <detailsIn response to : It flaked in today as well. </details
We're seeing this flake frequently downstream as well, both in TestUnprepareResources and TestPrepareResources.
cc
is trying to fix it but still pending
Change:
return nil, nil } <ins> // getIPFromLoopbackInterface gets the IPs on a loopback interface and returns a global unicast address, if any. // The loopback interface must be up, the IP must in the family requested, and the IP must be a global unicast address. func getIPFromLoopbackInterface(forFamily AddressFamily, nw networkInterfacer) (net.IP, error) { intfs, err := nw.Interfaces() if err != nil { return nil, err } for _, intf := range intfs { if !isInterfaceUp(&intf) { continue } if intf.Flags&(net.FlagLoopback) != 0 { addrs, err := nw.Addrs(&intf) if err != nil { return nil, err } klog.V(4).Infof("Interface %q has %d addresses :%v.", intf.Name, len(addrs), addrs) matchingIP, err := getMatchingGlobalIP(addrs, forFamily) if err != nil { return nil, err } if matchingIP != nil { klog.V(4).Infof("Found valid IPv%d address %v for interface %q.", int(forFamily), matchingIP, intf.Name) return matchingIP, nil } } } return nil, nil } </ins> // memberOf tells if the IP is of the desired family. Used for checking interface addresses. func memberOf(ip net.IP, family AddressFamily) bool { if ip.To4() != nil {

Discussion:
What happened: When attempting to kubeadm join a control plane node or worker on a machine with global IPv4 unicast addresses on a loopback address (router to the host w/ BGP Unnumbered), the join fails with the following output: See this issue for details : Also: What you expected to happen: The correct IPv4 address should be selected from the loopback adapter, or we should be able to specify an IPv4 address to use for egress. The IPv6 addresses on the network adapters themselves are only used to establish upstream peering. IPv4 nexthops are fake 169.254.x.x addresses artificially programmed via RFC5549 into the ARP table. How to reproduce it (as minimally and precisely as possible): On a node with the following conditions: Routing to the host with FRR IPv6 link locals on physical network interfaces No IPv4 addresses on physical network interfaces Unicast IPv4 on the loopback adapter IPv4 default route present via RFC5549 Attempt to kubeadm join a node, and it will fail. Anything else we need to know?: We've been patching kubeadm with , which works as expected. There was a fix applied to allow initing control plane nodes w/ bind address 127.0.0.1 which would then select an IPv4 from the loopback, but it doesn't appear to have fixed the joining issues. Pinging and by request on kubeadm issues. Environment: Kubernetes version (use ): 1.17.12 Cloud provider or hardware configuration: baremetal OS (e.g: ): Centos 7 Kernel (e.g. ): 3.10.0-1127.19.1.el7.x86_64 Install tools: kubeadm Network plugin and version (if this is a network-related bug): Calico Others: FRR for peering with routers on physical network interfaces
/sig api-machinery
is defined but we should note the same function is used for the --bind-address of the kube-apiserver. /sig network
/assign
/triage accepted
Change:
config: "kind: KubeSchedulerConfiguration", expErr: "unexpected config type", }, <ins> { name:   "Missing quotes around :: bindAddress", config: "bindAddress: ::", expErr: "mapping values are not allowed in this context", }, </ins> } version := "apiVersion: componentconfig/v1alpha1" for _, tc := range testCases {

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?: /kind feature What happened: Upon code inspection, found that kube-proxy server takes into consideration a bind address of 0.0.0.0 (IPv4), but does not check for a bind address of :: (all-zeros IPv6) when calculating its node IP. What you expected to happen: IPv6 address "::" should be taken into consideration when calculating node IP. How to reproduce it (as minimally and precisely as possible): Code inspection. Anything else we need to know?: Environment: Kubernetes version (use ): Latest master Cloud provider or hardware configuration**: VirtualBox cluster, Ubuntu 16.04.1 host, CentOS 7 guests OS (e.g. from /etc/os-release): CentOS 7 Kernel (e.g. ): 3.10.0-514.26.2.el7.x8664 SMP Tue Jul 4 15:04:05 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/area ipv6 /sig network
Change:
// ScaleApplyConfiguration constructs an declarative configuration of the Scale type for use with // apply. func Scale() *ScaleApplyConfiguration { <del> return &ScaleApplyConfiguration{} </del> <ins> b := &ScaleApplyConfiguration{} b.WithKind("Scale") b.WithAPIVersion("extensions/v1beta1") return b </ins> } // WithKind sets the Kind field in the declarative configuration to the given value

Discussion:
Most of the FooApplyConfiguration constructors pre-fill the Kind and APIVersion fields to make using them smooth. But () is missing this, making patterns like this fail: Currently this code fails with (server-side) error . The constructor should set the minimum required fields for the resulting object to be usable with calls, similar to how e.g. the `D Create a deployment (however) Create a clientset, and get the Deployments client from it Try to call deployments.ApplyScale using a ScaleApplyConfiguration created by the Scale() constructor I can see that the presence or absence of these metadata fields is driven by some code generation, but I wasn't able to follow through to what configures that code generation. I assume it's something in the schemas somewhere, but that wasn't clear to me. <details</details<detailsminikube v1.25.1 </detailsN/A N/A N/A N/A
/sig api-machinery
/assign /triage accepted
/assign
Change:
"path/filepath" "strings" "sync" <ins> "time" </ins> "github.com/golang/glog" <ins> "k8s.io/kubernetes/pkg/util/wait" </ins> ) // DockerConfigJson represents ~/.docker/config.json file info

Discussion:
http://pr-
Something holding the port already?
The previous masterless case just barely passed with a 12.5 second timeout (25 tries at 0.5 second interval) I think we just need to increase the timeout.
I randomly sampled 5 green builds and they all have this test (starting kubelet in masterful/less mode) finished in 3s or less. Judging for the successful masterless mode startup before the failure, kubelet spent the most time trying to register credential providers (a 10s gap in the log). The same roughly applies to the failed "masterful mode", based on where the log message stopped. From , the registering process basically tries to access the metadata url to see if the credential provider is enabled. I think this may just be the slow response from the metadata server.
I am wondering even if this issue might be related to a slow response from the metadata server, why it does not show "Registering credential provider: .dockercfg" always in failed logs?
If there is a possibility that ReadUrl in may take longer than expected, would it be preferred to use a Timeout (0) with the http client to not get stuck longer than expected?
I am unsure why it didn't show that, but even in the passing round we see a 10 second gap, which almost maxed out the timeout. I think adding a timeout is reasonable, but I am not sure what value is reasonable given that the previous request took 10s. do you have any idea?
Even I am not sure exactly what should be a reasonable value. My guess would be that if in normal cases, average response time is x seconds (perhaps a guestimate could be computed based on "normal" successful tests), then x could be a starting point, or otherwise another option is choosing something randomly (like 5s). And I think that if at some point, the server is responding in 10s, and even though the test passes, its not normal and something is going wrong.
uses a 10 second timeout, but the request will be retried. Given that we don't retry this request, a short timeout is worrisome. Maybe we should add both retry and timeout in this case.
SGTM.
I reopen this one since pr was reverted.

Noticed a similar hang in: The logs are a bit different from those observed in
if kubelet couldn't start up properly, the test itself should've timed out and logged "Timed out waiting for kubelet to answer at http://127.0.0.1:/healthz; tried 25 waiting 0.5 between each". I am not sure if this failure is related.
failure is not relevant to this issue. The most recent report of such flake was over a week ago. I think the cause is the slow metadata url response in GCE, and that should've been fixed by the recent rollout. I am going to close this issue. Feel free to reopen if there is another occurrence.
Change:
"strings" "k8s.io/klog" <ins> "k8s.io/utils/keymutex" </ins> utilpath "k8s.io/utils/path" )

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: I am using Windows containers (Server Core ltsc 2019). These all have volumes mounted to three different Azure file shares under a single storage account. Multiple instances of these containers run on each node. On deploying the containers I get the following errors. Sometimes this does manage to resolve itself. MountVolume.SetUp failed for volume "log-share" : Remove-SmbGlobalMapping failed: exit status 1, output: "Remove-SmbGlobalMapping : No MSFTSmbGlobalMapping objects found with property 'RemotePath' equal to rn'storageaccounturllogs'. Verify the value of the property and retry.rnAt line:1 char:1rn+ Remove-SmbGlobalMapping -RemotePath $Env:smbremotepath -Forcern+ ~rn + CategoryInfo : ObjectNotFound: (storageaccounturllogs:String) [Remove-SmbGlobalMapping], Ci rn mJobExceptionrn + FullyQualifiedErrorId : CmdletizationQueryNotFoundRemotePath,Remove-SmbGlobalMappingrn rn" MountVolume.SetUp failed for volume "config-share" : New-SmbGlobalMapping failed: exit status 1, output: "New-SmbGlobalMapping : Generic failure rnAt line:1 char:190rn+ ... ser, Env:smbremotepath -Cred ...rn+ ~~~rn + CategoryInfo : NotSpecified: (MSFTSmbGlobalMapping:ROOT/Microsoft/...mbGlobalMapping) [New-SmbGlobalMa rn pping], CimExceptionrn + FullyQualifiedErrorId : HRESULT 0x80041001,New-SmbGlobalMappingrn rn" What you expected to happen: For the volumes to be mounted. This all worked ok in k8s 1.12.1 using Windows 1803. I have now upgraded to 1.13.4 and Windows ltsc2019.

How to reproduce it (as minimally and precisely as possible): Use aks-engine to create a 1.13.4 cluster with Windows nodes Create a storage account Create multiple file shares under the account. Add access credentials to the storage account as a secret on k8s Create a windows container with folders that will be used to mount the Azure storage account file shares. Deploy to k8s defining volume mounts and volumes in the container section of the deployment e.g. volumeMounts: name: folder1-share mountPath: "c:appfolder1" name: folder2-share mountPath: "c:appfolder2" volumes: name: folder1-share azureFile: secretName: azure-file-share-cred shareName: share1 readOnly: false name: folder2-share azureFile: secretName: azure-file-share-cred shareName: share2 readOnly: true Anything else we need to know?: This maybe related to the fix for Environment: Kubernetes version (use ): 1.13.4 Cloud provider or hardware configuration: Azure OS (e.g: ): Windows 2019 Kernel (e.g. ): 10.0..316 Install tools: aks-engine 0.13.2 Others:
/sig Azure
/sig windows
/assign
hi in your logs, the remotepath is , so is the share name? also, could you log on to that agent node, and provide , there are logs like
I think this is a race condition issue, let me file a PR to fix this, thanks for reporting
Change:
} } <del> func expectStop(t *testing.T, w *worker, c bool, msg string) { if c { t.Errorf("[%s - %s] Expected to stop, but did not", w.probeType, msg) } } </del> func resultsManager(m *manager, probeType probeType) results.Manager { switch probeType { case readiness:

Discussion:
We detected behavior change in v1.21.0 Example: POD has and for some containers Behavior in v1.20.5: starts applied startupProbe success, then start checks for livenessProbe working failed restarted startupProbe applied startupProbe success, then start checks for livenessProbe working Behavior in v1.21.0: starts applied startupProbe success, then start checks for livenessProbe working failed restarted applied, startupProbe skipped not ready yet, killed by liveness check in restart loop So, in v1.21 is applied to "fresh" starts only and not used when container restarted. There is not mentions in changelog that behavior of the is changed. should run on container restarts also. POD with and fail that doesn't apply after container restart Kubernetes version (use ):Cloud provider or hardware configuration: baremetal
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
Thanks for the quick fix
it was fixed in master (1.22) but not for 1.21, does it need a backport? /reopen
Reopened this issue. <detailsIn response to : it was fixed in master (1.22) but not for 1.21, does it need a backport? /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
/close never mind i just saw the backports.
Closing this issue. <detailsIn response to : /close </details
can you summarize the impacted patch releases (looks like the regression was backported to 1.18-1.20 as well)
These 4 patch releases are impacted, 1.18.18, 1.19.10, 1.20.6, 1.21.0
Change:
ExpectedContent: expectedContent, }, } <del> volume.TestVolumeClient(f, testConfig, nil, "", tests) </del> <ins> volume.TestVolumeClientSlow(f, testConfig, nil, "", tests) </ins> } l.testCase.TestDynamicProvisioning() })

Discussion:
Which jobs are flaking: gce-cos-master-alpha-features Which test(s) are flaking: [sig-storage] CSI Volumes [Driver: ][Serial] [Testpattern: Dynamic PV (default fs)] provisioning should provision storage with snapshot data source [Feature:VolumeSnapshotDataSource] Testgrid link: Reason for failure: It takes 6 minutes to start a pod with PVC that has been restored from a snapshot, while the test waits only 5 minutes: csi-attacher sidecar says: Perhaps the provisioner should wait until the volume is ready to be used? That may not help with this test timeout, as PVC is provisioned after the Pod is scheduled and the total time could be the same. All this is caused by my PR to test block snapshots, It reworked the tests from using . If snapshots are slow, should all persistent storage tests use / ?
/sig storage
Generally, cutting a snapshot is quick, but uploading can take longer. Does provisioner wait until the snapshot is "ready" before returning success?
cc
(But yes, we should increase the timeout because overall time will still be longer no matter which order we take)
The provisioner does not wait. If snapshot is not readyToUse, creating a volume from it will fail. I'll have to check to see if there's logic to wait in the e2e test. Regarding GCE PD, at restore time, do we need to download the snapshot from object store? If that's the case, it could take a while to download as well.
volume controller should keep trying until snapshot is ready. Looks like attacher tried to attach while disk is not ready. It is strange because I think attach only happen after volume is successfully provisioned.
AFAIK, most cloud providers' snapshot ATM will be uploaded to some remote when taking, and will be downloaded when restoring. GCE PD is one of them.
It's not taking snapshots what slows the test, it's restoring it - returns quickly, but the returned volume is not really usable and attach fails for ~4 minutes until the snapshot is fully restored somewhere in GCE. Now that I am thinking about it, maybe it's better if the driver returns the volume early, so it does not end up orphaned when user deletes corresponding PVC and the provisioner is restarted at the same time.

Anyway, I'll extend the timeout in volume checks. /assign
Which brings me to idea: what about other storage backends? Some of them may take even longer that 10 minutes to restore a snapshot. Or more than 5 minutes to provision an empty volume and run a pod. There should be some configuration of timeouts (timeout multiplier?) for
I opened to investigate from GCE side if this behavior is expected.
Change:
delete(cache.assumedPods, key) delete(cache.podStates, key) default: <del> return fmt.Errorf("pod %v state wasn't assumed but get forgotten", key) </del> <ins> return fmt.Errorf("pod %v wasn't assumed so cannot be forgotten", key) </ins> } return nil }

Discussion:
/kind bug There are several error messages in the scheduler cache that are confusing to read, at least one of these surfaced up to end users via Events. I noticed these two in particular but there may be others: Whether or not these should actually be surfacing as events, the messages should be cleaned up.
cc
Seems that these are internal or implement details in scheduler, do our end users can fully understand what the events really mean? I think it is depend on our own implement. idea?
I believe, the problem is with in the message but I am not able to reproduce it, can you please share steps to reproduce this.
No unfortunately, one of our users reported seeing it when there system was in a bad state, not in a reproducible way. The point of the issue is just that the grammar in those messages is bad, which should be fixable even if you can't get them to fire.
Change:
updated.Status.LoadBalancer = *newStatus klog.V(2).Infof("Patching status for service %s/%s", updated.Namespace, updated.Name) <del> _, err := patch(s.kubeClient.CoreV1(), service, updated) </del> <ins> _, err := servicehelper.PatchService(s.kubeClient.CoreV1(), service, updated) </ins> return err }

Discussion:
PR service patch methods to Once there is a release with that PR included, the code in service-controller and legacy-cloud-providers/gce can be updated to use those. /area platform/gce /assign
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Those labels are not set on the issue: <detailsIn response to : /remove-triage unresolved 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
Created a PR to use these new functions in Service-controllers.
Change:
volumeName := "aws://" + az + "/" + awsID // apply tags <del> if volumeOptions.Tags != nil { if err := s.createTags(awsID, *volumeOptions.Tags); err != nil { </del> <ins> tags := make(map[string]string) for k, v := range volumeOptions.Tags { tags[k] = v } if s.getClusterName() != "" { tags[TagNameKubernetesCluster] = s.getClusterName() } if len(tags) != 0 { if err := s.createTags(awsID, tags); err != nil { </ins> // delete the volume and hope it succeeds _, delerr := s.DeleteDisk(volumeName) if delerr != nil {

Discussion:
We should tag EBS volumes created by k8s with our tags, just like we (should) tag everything else we create/own.
Is there any documentation yet on automatic EBS volume creation?
from a user perspective, they are not AWS specific. That said, I don't know that we have clear user-facing docs. Here's an example though, from my (very) WIP Ubernetes-Lite docs: ... The PV is also tagged with the zone & region is is in (us-central1-a): Create a pod that uses the PVC:
It doesn't seem to cleanup the volume when the PV is deleted... probably intended behavior. Any way to tell it to automatically delete the volume on PV delete?
- I'm not sure about foo - hopefully that'll be resolved with docs. I think the failure to delete the volume is actually pretty important. Do you want to open an issue? It's not AWS specific (and this particular issue was auto-closed when the PR merged)
yeah I will open an issue later today. Issue seems to still be happening - the PV is never deleted. On Sat, Mar 12, 2016, 6:24 AM Justin Santa Barbara wrote: