jiebi/CodeConvo huggingface dataset:
Change:
s.lock.Lock() defer s.lock.Unlock() s.writeCalled = true <del> s.dataWritten = make([]byte, len(p)) copy(s.dataWritten, p) return len(p), io.EOF </del> <ins> s.dataWritten = append(s.dataWritten, p...) // Indicate the stream accepted all the data, and can accept more (no err) // Returning an EOF here will cause the port forwarder to immediately terminate, which is incorrect, in case someone writes more data return len(p), nil </ins> } func (s *fakeUpgradeStream) Close() error {

Discussion:
ok 1.520s coverage: 25.5% of statements I0414 23:19:35. ] Forwarding from 5000 -5000 W0414 23:19:35. ] Unable to listen on port {5000 5000}: listen tcp 127.0.0.1:5000: bind: address already in use I0414 23:19:35. ] Forwarding from 6000 -6000 I0414 23:19:35. ] Handling connection for 5000 --- FAIL: TestForwardPorts (0.22s) 2: expected to read '1234', got '' FAIL coverage: 83.3% of statements FAIL 0.677s
It looks like the crux is this: ] Unable to listen on port {5000 5000}: listen tcp 127.0.0.1:5000: bind: address already in use listen often needs a retry after a recent close, to account for TIME_WAIT state of the port. But that's pure speculation on my part. We need to repro and fix.
http://hea- is perhaps a better link.
I'll have a go at it in the next few days if nobody else picks it up before me.
There were two issues... one was multiple test cases reusing the same port and deferring the close until the end of the function, not the end of the loop... that was fixed in The other issue was with the fake stream returning an EOF on a Write(), fixed in
Change:
} } path = strings.Replace(n.itemPath, "{name}", name, 1) <del> if !n.allNamespaces { path = strings.Replace(path, "{"+n.scope.ParamName()+"}", namespace, 1) } </del> <ins> path = strings.Replace(path, "{"+n.scope.ParamName()+"}", namespace, 1) </ins> return path, "", nil }

Discussion:
Accessing entities without namespaces in the url makes the selflink to look corrupted (has namespace missing): Example - invoking: http://localhost:8080/api/v1beta3/services/ returns entities with this selflink (note the part after namespaces) "selfLink": "/api/v1beta3/namespaces/%7Bnamespaces%7D/services/guestbook"
I thought accessing namespaced objects without the namespace was just disallowed in v1beta3. ?
Oh, probably list is allowed for components that need to watch all objects across all namespaces, such as kube-proxy. In that case, the selfLink looks broken, yes.
- right. I will look into the self link this afternoon to see what's going on. Self assigning.
The api has to allow fetching all objects cross namespaces without specifying namespace, otherwise it will cause multiple requests to the api - per namespace, big overhead for clients.
Change:
if j.beginRange > 0 { j.beginRange-- j.inRange++ <del> for _, value := range results { </del> <ins> if len(results) > 0 { for _, value := range results { j.parser.Root.Nodes = nodes[i+1:] nextResults, err := j.FindResults(value.Interface()) if err != nil { return nil, err } fullResult = append(fullResult, nextResults...) } } else { // If the range has no results, we still need to process the nodes within the range // so the position will advance to the end node </ins> j.parser.Root.Nodes = nodes[i+1:] <del> nextResults, err := j.FindResults(value.Interface()) </del> <ins> _, err := j.FindResults(nil) </ins> if err != nil { return nil, err } <del> fullResult = append(fullResult, nextResults...) </del> } j.inRange--

Discussion:
What happened: throws errors if no pods are found in v1.19.3, but returns success with empty response in v1.16.8 What you expected to happen: If there are no pods that return, no error should be thrown as the range should evaluate to "no op". How to reproduce it (as minimally and precisely as possible): Adapt the example from to get the command . Run this when there are pods in default namespace - all is well. Run this when there are no pods in default namespace and you get the error: Anything else we need to know?: This breaks all kinds of code that relies on jsonpath's earlier behaviour. I found an old report () that seems appropriate, but that is long since merged and closed. Environment: Kubernetes version (use ): 1.19.3 Cloud provider or hardware configuration: x86-64 OS (e.g: ): RedHat Enterprise Linux 7.6 (Maipo) Kernel (e.g. ): Install tools: n/a Network plugin and version (if this is a network-related bug): n/a Others: n/a
/sig cli
/cc
/sig api-machinery
/assign cc /triage accepted
Change:
EnableV1Beta3:          v1beta3, MasterServiceNamespace: s.MasterServiceNamespace, ClusterName:            s.ClusterName, <ins> SyncPodStatus:          s.SyncPodStatus, </ins> } m := master.New(config)

Discussion:
Split off as a smaller more specific work item. Apiserver should have a flag that makes it not attempt to GET from kubelets. This would be used in conjunction with . After we have converted the top N Getting-started-guides to the new style, we can rip out the kubelet client from the apiserver altogether.
This is tightly related to so I'll take it.
Change:
"flag" "fmt" "log" <ins> "math/rand" </ins> "net" "os" "strconv"

Discussion:
In Kubernetes 1.26, Kubernetes Enhancement Proposal, KEP-3352[1]: Aggregated Discovery, enhanced the discovery mechanism and supported aggregated discovery optimizing response for discovery api. To support this KEP, Changes were made to both API server and client to support aggregated discovery mechanism. This feature was available alpha in Kubernetes 1.26 behind a feature flag, . In Kubernetes 1.27, aggregated discovery endpoint was promoted to beta and enabled by default[2]. Here is a class of problems that ended up getting triggered. GOOD NEWS!! is that it is already fixed by in 1.27 and a cherry pick in 1.26 For example, With Prometheus adapter, we saw issues across repositories: One signature of this is following in the traceback:
Searching for that method signature: Currently shows the following:
Leaving this open for some time, just to serve as a point of coordination if needed. The advice/guidance here is for folks to update to newer versions of 1.26/1.27 client-go.
/sig api-machinery
Components that do generate custom metrics (grepping through sources!): etc..
Thanks, Any custom server, sending nil GVK could trigger this bug. So far have seen it through custom metrics via promethus-adapter.
Thanks for tracking this /cc /triage accepted
For those searching in the future, the impacted versions are: 26.0 - 0.26.3 The fixed versions are: 26.4+ As well as updating , make sure that your other dependencies do not pull in any of the affected versions.
/close i think that's about it for now..
Closing this issue. <detailsIn response to : /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
Change:
} } if pointedModel == nil { <del> return fmt.Errorf("Requested resourse: %s doesn't exit", inModel) </del> <ins> return fmt.Errorf("Requested resource: %s doesn't exist", inModel) </ins> } if len(fieldsPath) == 0 {

Discussion:
It would be nice if let me explain experimental resources to aid users ability to experiment.
It's possible this works today, but it was non-obvious how to use. Attempts:
cc
cc
No, this isn't supported, since current implementation only use v1 Client but not experimental Client.
do we need to fix this for 1.1?
How difficult do you think it would be to fix?
It has dependency on ServerAPIVersions(), for which we plan to make a clean-up PR. I guess it needs 3-4 days to get two PRs merged.
With , this can be fixed now. What's the expected behavior of ? I assume in case of , it should search hpa in both v1 and extensions/v1bata1, and determines hpa as a resource in the extensions group? BTW, the use of "api-version" flag is problematic It adds extra meaning to the generic "api-version" flag.
Change:
"//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime/serializer:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/runtime/serializer/yaml:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/errors:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/net:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/validation:go_default_library",

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add an external MetaFactory that allows for serializing multiple YAML (or JSON) files in kubeadm. The logic of marshalling YAML should be factored out from to . Why is this needed: This will allow processing component configs containing multiple documents per file. Additionally, an out-of-tree library would allow sharing this functionality with other components.
I will try work on this as carry-on from /sig cluster-lifecycle /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
/remove-lifecycle stale
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:
applyContainerSecurityContext(lc, podSandboxID, createConfig.Config, hc) } <ins> // Apply cgroupsParent derived from the sandbox config. if lc := sandboxConfig.GetLinux(); lc != nil { // Apply Cgroup options. // TODO: Check if this works with per-pod cgroups. // TODO: we need to pass the cgroup in syntax expected by cgroup driver but shim does not use docker info yet... hc.CgroupParent = lc.GetCgroupParent() } </ins> // Set devices for container. devices := make([]dockercontainer.DeviceMapping, len(config.Devices)) for i, device := range config.Devices {

Discussion:
When debugging Pod level QoS with CRI dockershim, I found that Pod level OoS actually doesn't work: dockershim+cgroupfs dockertools+cgroupfs And after dug it deeper, I noticed CgroupParent is not properly set at all: Finally, found the root cause is that that in is accidentally override, so it's always empty. PR: will fix this.
BTW, I also wrote a patch to make based Pod level QoS work in CRI dockershim, I will send it after this is fixed.
-- i am interested in the systemd patch.. i was hoping to find time to add that this week, so its good to know you have something. the problem if i recall was no clear place to inspect docker's configured cgroup driver.
Yes, so a is to dockershim during initialization. May I send a PR and and have you review if it sounds good. It's:
Change:
&cfg.ExtraConfig, } <del> serviceIPRange, apiServerServiceIP, err := DefaultServiceIPRange(c.ExtraConfig.ServiceIPRange) </del> <ins> serviceIPRange, apiServerServiceIP, err := ServiceIPRange(c.ExtraConfig.ServiceIPRange) </ins> if err != nil { klog.Fatalf("Error determining service IP ranges: %v", err) }

Discussion:
API server defaults the service CIDR. We should instead just fail if it is not specified. Defaulting is a wild guess and very likely to be wrong. /sig network /kind bug
For existing clusters that don't currently set it, is setting it to anything other than the current default a breaking change?
Yes. You can not really change it (well, you can expand it, but not totally move it), unless you delete ALL services, including kubernetes.default. I filed this aspirationally. It's not on fire, it's just a dumb thing to have provided a default for.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/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
Change:
return err } <del> if lb.opts.FloatingNetworkId != "" && vip != nil { </del> <ins> if vip != nil && vip.PortID != "" { </ins> floatingIP, err := getFloatingIPByPortID(lb.network, vip.PortID) if err != nil && !isNotFound(err) { return err

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Currently openstack cloud provider just support for specifying internal LoadBalancerIP. I think that is unreasonable, actually user just use a floating ip to access a LoadBalancer service. So it is necessary to spport for specifying external LoadBalancerIP. What you expected to happen: Support for specifying external LoadBalancerIP on openstack Anything else we need to know?: Currently LoadBalancerIP can be specified in service.Spec.LoadBalancerIP, we can add annotation to distinguish between internal and external.
/sig openstack /assign I'd like to work for it.
Change:
<ins> //go:build linux && amd64 </ins> /* Copyright 2022 The Kubernetes Authors.

Discussion:
periodic-kubernetes-unit-test-ppc64le TestCleanup Probably since it was merged in https://k8s- No response The error from build log trace is: Please go through the above job for complete build log. /sig testing
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
This test has been constantly failing in our environment and not just flaking. Also, We see it still failing even after your fix for is the job that ran after merge of
^^
cc
This is a data race in the control plane setup. cc
So yes, this is different from the failure that I ran into. It's still a flake (races don''t always go wrong), but apparently the conditions in your jobs are so that it always triggers.
I'll take care of this /assign
At first glance it looks like access to in lacks protection by a mutex. But why are and racing with each other in different goroutines, and why is called first?
in some executions it seems that it just timeouts, no races I think that the problem is that this environment is under resourced and this test is not able to boot the apsierver , that may explain the race and why Stop is racing with Start
Should we perhaps make this unit test run only on amd64 architectures, with the rationale a) that it isn't architecture-dependent and thus testing it in one unit test job is sufficient and b) that it is an expensive test that stresses slower architectures too much?
the apiserver times out starting up, I think we can make it lighter with it sound fair to me, since we use etcd and it is only guaranteed to build do you want to make the honors? or should I?
Can you do it because we probably want both and you know best how to explain the patch above in the commit message?

I thought about this twice, and I don't think we should tune the tests for running on constrained environments, this is a slippery slope, this environment is clearly constrained , there are also other issues reporting timeouts in this environment ... we should not tune test just to pass The skip based on etcd not supported may be reasonable though
Met this again when running , see
this is for the ppc64le specific problem, we should open a new one for this test it seems there were 2 occurrences more
For tracking, opened a new issue here
Change:
"sync" v1 "k8s.io/api/core/v1" <ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> "k8s.io/apiserver/pkg/admission" cloudprovider "k8s.io/cloud-provider" cloudvolume "k8s.io/cloud-provider/volume"

Discussion:
API server latency for PV creation depends on underlying cloud API latency. We have admission plugin that examines incoming PV and adds topology labels and node selector: When the cluster (and cloud) are under pressure, e.g. lot of PVCs are created and dynamically provisioned at one time and attached to nodes, API server latency increases. We've seen cases when we ran out of cloud API request quota and the admission plugin needed to sleep for couple of seconds (on AWS). There should be an easy fix: check, if the created PV already has all necessary labels and topology information and ask the cloud for them only when they're missing. Dynamically provisioned volumes already have these labels. The admission plugin will then ask the cloud only for manually provisioned PVs, which we believe is just a fraction of all PVs in the cluster. There is one glitch: previously, when user created a PV with wrong topology labels, the admission plugin corrected them. With the fix suggested above, this PV won't be corrected. /sig storage cc
Implementation of the above:
Change:
} return &draPluginClient{ <del> pluginName:        pluginName, addr:              draAddr(existingPlugin.endpoint), nodeClientCreator: newNodeClient, </del> <ins> pluginName: pluginName, plugin:     existingPlugin, </ins> }, nil }

Discussion:
See comment for details:
/sig node
/area kubelet
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
/triage accepted
Change:
glog.Fatalf("Failed to get supported resources from server: %v", err) } <del> namespaceController := namespacecontroller.NewNamespaceController(clientset.NewForConfigOrDie(client.AddUserAgent(kubeconfig, "namespace-controller")), &unversioned.APIVersions{}, s.NamespaceSyncPeriod) </del> <ins> namespaceController := namespacecontroller.NewNamespaceController(clientset.NewForConfigOrDie(client.AddUserAgent(kubeconfig, "namespace-controller")), versions, s.NamespaceSyncPeriod) </ins> go namespaceController.Run(s.ConcurrentNamespaceSyncs, wait.NeverStop) groupVersion := "extensions/v1beta1"

Discussion:
Yet another case of not being deleted properly?
I can take a look in morning. Assign to me. I am blocked on generalizing the controller until the dynamic client is done. On Wednesday, February 10, 2016, Tim Hockin wrote:
Are you seeing this on HEAD? I had moved in a recent PR to call DeleteCollection instead of per item deletes. Possibly job has a bug there.
yes head , Derek Carr wrote:
- I see be bug. The list of version strings being passed to the controller got messed up in my last PR. I will send a patch soon.
I patched this into my cluster and it seems fixed, but the same problem exists for replicaset now.
Change:
accountsLock = &sync.Mutex{} ) <del> func newBlobDiskController(common *controllerCommon) (*BlobDiskController, error) { c := BlobDiskController{common: common} </del> <ins> func (c *BlobDiskController) initStorageAccounts() { accountsLock.Lock() defer accountsLock.Unlock() </ins> <del> // get accounts accounts, err := c.getAllStorageAccounts() if err != nil { klog.Errorf("azureDisk - getAllStorageAccounts error: %v", err) c.accounts = make(map[string]*storageAccountState) return &c, nil </del> <ins> if c.accounts == nil { // get accounts accounts, err := c.getAllStorageAccounts() if err != nil { klog.Errorf("azureDisk - getAllStorageAccounts error: %v", err) c.accounts = make(map[string]*storageAccountState) } c.accounts = accounts </ins> } <del> c.accounts = accounts return &c, nil </del> } // CreateVolume creates a VHD blob in a storage account that has storageType and location using the given storage account.

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: A storageAccount API call blocks kubelet from becoming Ready when there isn't any outbound IP, 1. eventually (after 10mins), the kubelet registers again... there is a call to the ARM API done by which blocks for 10mins, before letting kubelet complete with its starting logic and making the node as 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 ): v1.11.5 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig azure /assign
Change:
"k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" <ins> "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/types" </ins> "k8s.io/apimachinery/pkg/util/intstr" <ins> utilrand "k8s.io/apimachinery/pkg/util/rand" </ins> "k8s.io/apimachinery/pkg/util/wait" clientset "k8s.io/client-go/kubernetes" "k8s.io/kubernetes/pkg/quota/v1/evaluator/core"

Discussion:
[x] test approval issue : [x] test pr : 7 July 2022 [X] two weeks soak end date : 21 July 2022 [X] test promotion pr : According to this APIsnoop query, there is still some remaining ResourceQuota endpoints which are untested. The Status endpoints will be addressed in another test. listCoreV1ResourceQuotaForAllNamespacespatchCoreV1NamespacedResourceQuotadeleteCoreV1CollectionNamespacedResourceQuota Using a number of existing e2e test practices a new has been created for three ResourceQuota endpoints. The e2e logs for this test are listed below. This query shows the endpoints hit within a short period of running the e2e test 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
/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:
"//pkg/api/v1/pod:go_default_library", "//pkg/client/clientset_generated/clientset:go_default_library", "//pkg/client/informers/informers_generated/externalversions/core/v1:go_default_library", <ins> "//pkg/client/leaderelection/resourcelock:go_default_library", </ins> "//pkg/client/listers/core/v1:go_default_library", "//pkg/controller:go_default_library", "//pkg/util/metrics:go_default_library",

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG OR Do i miss something important? Kubernetes version (use ): k8s 1.3.5. still exists in 1.6.2 What happened: HA of kube-controller-manager and kube-scheduler is achieved by create endpoint and update it periodically. However, endpoint controller deletes endpoints without corresponding services which is implemented in checkLeftoverEndpoints func: That will result in leader transition. What you expected to happen: checkLeftoverEndpoints func shouldn't delete endpoints used by LeaderElection. How to reproduce it (as minimally and precisely as possible): turn on LeaderElection for kube-controller-manager and kube-scheduler. After five minutes, endpoint controller will delete orphan endpoints. Anything else we need to know: we can add some logic in checkLeftoverEndpoints, for example, not add endpoint in kube-system namespace to queue.
Fixed by
Thanks