jiebi/CodeConvo huggingface dataset:
Change:
t.Errorf("did not set env: %s", buf.String()) } } <ins> func TestSetMultiResourcesEnvLocal(t *testing.T) { f, tf, codec, ns := cmdtesting.NewAPIFactory() tf.Client = &fake.RESTClient{ GroupVersion:         legacyscheme.Registry.GroupOrDie(api.GroupName).GroupVersion, NegotiatedSerializer: ns, Client: fake.CreateHTTPClient(func(req *http.Request) (*http.Response, error) { t.Fatalf("unexpected request: %s %#vn%#v", req.Method, req.URL, req) return nil, nil }), } tf.Namespace = "test" tf.ClientConfig = &restclient.Config{ContentConfig: restclient.ContentConfig{GroupVersion: &legacyscheme.Registry.GroupOrDie(api.GroupName).GroupVersion}} buf := bytes.NewBuffer([]byte{}) cmd := NewCmdEnv(f, os.Stdin, buf, buf) cmd.SetOutput(buf) cmd.Flags().Set("output", "name") cmd.Flags().Set("local", "true") mapper, typer := f.Object() tf.Printer = &printers.NamePrinter{Decoders: []runtime.Decoder{codec}, Typer: typer, Mapper: mapper} opts := EnvOptions{FilenameOptions: resource.FilenameOptions{ Filenames: []string{"../../../../test/fixtures/pkg/kubectl/cmd/set/multi-resource-yaml.yaml"}}, Out:   buf, Local: true} err := opts.Complete(f, cmd, []string{"env=prod"}) if err == nil { err = opts.RunEnv(f) } if err != nil { t.Fatalf("unexpected error: %v", err) } expectedOut := "replicationcontrollers/first-rcnreplicationcontrollers/second-rcn" if buf.String() != expectedOut { t.Errorf("expected out:n%snbut got:n%s", expectedOut, buf.String()) } } </ins>

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: my yaml: exec kubectl set resources command,just update first object: 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cli
/kind bug
/assign
Change:
package volume_test import ( <del> "io/fs" "os" "runtime" </del> "testing" . "k8s.io/kubernetes/pkg/volume"

Discussion:
On a clean Ubuntu dev environment I get the following error when I executed the I think that the tests should not fail and should handle the case where there is a cdrom device but there is not an actual CD media inserted. I got feedback from and this is also happing on his environment with the following error: I am coping also his comment from the slack that may help: Looks like it's not a problem with cdrom, but some dependence on device. I don't think it should try try to access at all. This is my very first issue, I am new to this, any help is welcome. I am really looking forward to starting coding but I am overwhelmed with the amount of information that I need to digest. /cc serathius /sig instrumentation
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
Fact that this tests fails only locally and not on CI means that there will not be a lot of interest in fixing it. Feel free to prepare a fix for it. Please let me know if you need help with setting up development workflow.
this is probably related to Because other tests have this same issue, CI is still running unit tests as UID=0. I have work to remove that but I wasn't sure about another storage test.
The block metrics tests were introduced in - I am fine with deleting the test in question. We have e2e that captures this more accurately and unit test seems kinda less useful anyways.
opened to remove the test. I think we should be fine without it.
Thank you! Also just for the record noting that I can of course locally reproduce this (with in my case).
thanks all. similar issues are tracked in ,
Change:
APIVersion: "v1", FieldPath:  "spec.containers[3]", }, <del> Reason:  "Stopped", Message: "some verbose message: 1", Source:  v1.EventSource{Component: "eventTest"}, Count:   2, Type:    v1.EventTypeNormal, </del> <ins> Reason:              "Stopped", Message:             "some verbose message: 1", Source:              v1.EventSource{Component: "eventTest"}, ReportingController: "eventTest", Count:               2, Type:                v1.EventTypeNormal, </ins> }, expectLog:    `Event(v1.ObjectReference{Kind:"Pod", Namespace:"baz", Name:"foo", UID:"differentUid", APIVersion:"v1", ResourceVersion:"", FieldPath:"spec.containers[3]"}): type: 'Normal' reason: 'Stopped' some verbose message: 1`, expectUpdate: true,

Discussion:
From the Deprecated API Migration Guide: , since v1.19, the has been using the new reportingController and reportingInstance to replace the decrecated source.component and But when I checked the Kube events in a cluster with version 1.26.0, those new fields are empty and the supposed to be deprecated fields have not been renamed. Seeing the values in the new fields like reportingController and reportingInstance an Kubernetes cluster with version 1.26.0 some Kube events the Kube events details for the field of reportingController, reportingInstance, source.component, No response <detailsServer Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2022-12-11T00:15:47Z", GoVersion:"go1.19.4", Compiler:"gc", Platform:"linux/amd64"} </details<detailsAzure </details<details</details<details</details<details</details<details</details
/sig instrumentation
I have also encountered this issue in my local 1.26.0 Kubernetes cluster, which does not align with the deprecation guide described in I believe I can investigate this further
/assign
Thank you for making the PR to fix this! Also a comment in the PR for the doc update.
/triage accepted
Change:
const PluginClientTimeout = 45 * time.Second <del> // Strongly typed address. type draAddr string </del> // draPluginClient encapsulates all dra plugin methods. type draPluginClient struct { <del> pluginName        string addr              draAddr nodeClientCreator nodeClientCreator } var _ drapb.NodeClient = &draPluginClient{} type nodeClientCreator func(addr draAddr) ( nodeClient drapb.NodeClient, nodeClientOld drapbv1alpha2.NodeClient, closer io.Closer, err error, ) // newNodeClient creates a new NodeClient with the internally used gRPC // connection set up. It also returns a closer which must be called to close // the gRPC connection when the NodeClient is not used anymore. // This is the default implementation for the nodeClientCreator, used in // newDRAPluginClient. func newNodeClient(addr draAddr) (nodeClient drapb.NodeClient, nodeClientOld drapbv1alpha2.NodeClient, closer io.Closer, err error) { var conn *grpc.ClientConn conn, err = newGrpcConn(addr) if err != nil { return nil, nil, nil, err } return drapb.NewNodeClient(conn), drapbv1alpha2.NewNodeClient(conn), conn, nil </del> <ins> pluginName string plugin     *Plugin </ins> } func NewDRAPluginClient(pluginName string) (drapb.NodeClient, error) {

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:
s.Lock() defer s.Unlock() for i := begin; i <= end; i++ { <del> s.used.SetBit(&s.used, i, 0) s.allocatedCIDRs-- cidrSetReleases.WithLabelValues(s.label).Inc() </del> <ins> // Only change the counters if we change the bit to prevent // double counting. if s.used.Bit(i) != 0 { s.used.SetBit(&s.used, i, 0) s.allocatedCIDRs-- cidrSetReleases.WithLabelValues(s.label).Inc() } </ins> } cidrSetUsage.WithLabelValues(s.label).Set(float64(s.allocatedCIDRs) / float64(s.maxCIDRs)) return nil } <del> // Occupy marks the given CIDR range as used. Occupy does not check if the CIDR </del> <ins> // Occupy marks the given CIDR range as used. Occupy succeeds even if the CIDR </ins> // range was previously used. func (s *CidrSet) Occupy(cidr *net.IPNet) (err error) { begin, end, err := s.getBeginingAndEndIndices(cidr)

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: With a /22 pod network and a /24 assigned to each node, a third node cannot get a pod CIDR if kube-controller-manager has ever been restarted. What you expected to happen: Once a third or fourth node joins, it gets a /24. How to reproduce it (as minimally and precisely as possible): 150% usage on the IPAM controller is not a good sign. Anything else we need to know?: During the creation of the rangeAllocator, Occupy() is called twice on the pod networks. The first time is before subscribing to the node informer. The second time is during the node informer callbacks because on subscribing it calls Add for all existing nodes. I will submit a proposed fix shortly. Environment: Kubernetes version (use ): 1.19.2
/sig network
/triage accepted thanks for finding the bug I 've introduced :)
Change:
}, { ObjectMeta: metav1.ObjectMeta{ Name:              "2001:db8::2", <del> CreationTimestamp: metav1.Time{Time: time.Now().AddDate(-5, 0, 0)}, </del> <ins> CreationTimestamp: metav1.Time{}, </ins> }, Spec: networking.IPAddressSpec{ ParentRef: &networking.ParentReference{

Discussion:
and also v1.27-1.29 TestPrintIPAddressList After 03-01 the leap day caused the failure /sig cli network
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
Change:
config-ip-firewall create-dirs <ins> setup-kubelet-dir </ins> ensure-local-ssds setup-logrotate if [[ "${KUBERNETES_MASTER:-}" == "true" ]]; then

Discussion:
GCI Test Failing: (kubernetes-gci-gce-alpha-features-release-1.4) ([] PetSet [Slow] [Feature:PetSet] [] Deploy clustered applications [Slow] [Feature:PetSet] should creating a working mysql cluster [Feature:PetSet]) https://k8s-
This one, and appear to be failing because of the same reasons. The files being written by the init containers don't have the right permissions perhaps? This is what I observed so far. Looks like it's mounted with noexec for some reason. cc
nice debug
Random tip, came across this looking for another bug. GCI broken emptydir because kubelet's root-dir is noexec. Petset is just a victim:
Seems to be a dup of I have posted a fix. , Prashanth B wrote:
Change:
url := fmt.Sprintf("%s/%s.txt", bucketURL, versionLabel) body, err := fetcher(url, getReleaseVersionTimeout) if err != nil { <del> // If the network operaton was successful but the server did not reply with StatusOK if body != "" { return "", err } </del> if clientVersionErr == nil { // Handle air-gapped environments by falling back to the client version. klog.Warningf("could not fetch a Kubernetes version from the internet: %v", 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: I was using kubeadm to generate cluster ca: The CA generation failed because of 502 bad gateway returned and the response body isn't empty when it's trying to fetch stable version from internet. In this case, the function returns error instead of falling back to local client version: is how kubeadm fetches stable version and is how the error is handled for . Should kubeadm always fall back to client version when there is any internet issue? Otherwise, this sounds defeat the purpose of fallback. /sig cluster-lifecycle What you expected to happen: kubeadm falls back to local client version when there is any internet issue. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.13.7 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:
I'd like to take this issue. It would be better if you could give some directions. /assign
recreate the issue in kubernetes/kubeadm: /close
Closing this issue. <detailsIn response to : recreate the issue in kubernetes/kubeadm: Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
the fix will be removing the when failed to and add some unit test if I don't missing anything
Got it. Thanks.
Change:
password=$(python -c 'import string,random; print("".join(random.SystemRandom().choice(string.ascii_letters + string.digits) for _ in range(16)))') <del> gcloud compute ssh --zone="${ZONE}" --project="${PROJECT}" "${MASTER_NAME}"  </del> <ins> run-gcloud-compute-with-retries ssh --zone="${ZONE}" --project="${PROJECT}" "${MASTER_NAME}"  </ins> --command="sudo mkdir /home/kubernetes -p && sudo mkdir /etc/srv/kubernetes -p &&  sudo bash -c "echo ${CA_CERT_BASE64} | base64 --decode > /etc/srv/kubernetes/ca.crt" &&  sudo bash -c "echo ${MASTER_CERT_BASE64} | base64 --decode > /etc/srv/kubernetes/server.cert" && 

Discussion:
https://k8s- Failed: Kubemark {} Previous issues for this test:
Builds: ci-kubernetes-kubemark-5-gce Failed: Kubemark {}
There are few things here: 3443 run - can you please invstigate it? 3480 run - gcloud copy-files should be retried 3550 run - we should better handle "already exists" errors (and not retry them). I think was looking into it at some point, so he may have already did something
https://k8s- Failed: Kubemark {}
I was looking at 'already exists' problem in RouteController, not in Kubemark.
Builds: ci-kubernetes-kubemark-5-gce Failed: Kubemark {}
Here are the causes of the above tests to fail and fixes: Test Fix ------ ------ ci-kubernetes-kubemark-5-gce/3443 Ignore (as its super flaky) or change create-certs/generate-certs to use a different directory ci-kubernetes-kubemark-5-gce/3480 Run the copy-files with retries as it is idempotent ci-kubernetes-kubemark-5-gce/3550 Don't retry when resource already exists ci-kubernetes-kubemark-5-gce/3666 Not worry as it is flaky or add retrying logic to all gclouds in that script ci-kubernetes-kubemark-5-gce/3787 Run the ssh with retries as it is idempotent
This PR fixes issues with the 2nd, 3rd and 5th tests in the above table. Could you PTAL at the PR? Also, I think we can safely ignore the 1st test (which is super flaky) and what do you suggest about the 4th test (do we add retrying logic to just call inside detect-master function of or let it stay as it is because there are a lot of other such gcloud calls inside the file, all of which should be changed rightfully)?
Let's not fix everything - fix just the things that you need, and direct vicinity.
Ok. So then let's ignore the 1st and the 4th tests in the above table as they are not really important. 2nd, 3rd and 5th are solved by PR . And regarding failure of , it looks like it is a flaky issue as well.

The density test succeeded, but the load test failed. From the logs it appears to be an issue with the client caches returning old resource versions for pod watches, with many such log statements: Does this worry you or you'd deem it to be just some weird flake?
It might mean a number of things, but most likely something gets overloaded/congested. It might be hard to debug, as we're seeing this from time to time, but it doesn't look very serious so I think we never investigated it thoroughly.
Change:
vers := rsp.GetSupportedVersions() glog.V(4).Info(log("driver reports %d versions supported: %s", len(vers), versToStr(vers))) <ins> // If our supported version is still at 0.X.X, then check // also the minor number. If our supported version is >= 1.X.X // then check only the major number. </ins> for _, v := range vers { <del> //TODO (vladimirvivien) use more lenient/heuristic for exact or match of ranges etc if verToStr(v) == verToStr(ver) { </del> <ins> if ver.GetMajor() == uint32(0) && (ver.GetMajor() == v.GetMajor() && ver.GetMinor() == v.GetMinor()) { supported = true break } else if ver.GetMajor() != uint32(0) && ver.GetMajor() == v.GetMajor() { </ins> supported = true break }

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:
}() ginkgo.By("Waiting for events to ingest") <del> zone := framework.TestContext.CloudConfig.Zone c := utils.NewLogChecker(p, utils.UntilFirstEntryFromZone(zone), utils.JustTimeout, "") </del> <ins> location := framework.TestContext.CloudConfig.Zone if framework.TestContext.CloudConfig.MultiZone { location = framework.TestContext.CloudConfig.Region } c := utils.NewLogChecker(p, utils.UntilFirstEntryFromLocation(location), utils.JustTimeout, "") </ins> err := utils.WaitForLogs(c, ingestionInterval, ingestionTimeout) framework.ExpectNoError(err) })

Discussion:
This test consistently fails for GKE Regional Clusters: https://k8s- - can you please triage?
/assign
Hey, this was removed from 1.10 because it was never updated. Just want to make sure that this isn't a significant bug.
Yes, this is a significant bug in tests, sorry that it slipped our attention
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
/open
Change:
totals.added = desiredSet.Len() - existingMatches return totals } <ins> func needRebuildExistingSlices(endpoints *corev1.Endpoints, existingSlice *discovery.EndpointSlice) bool { for index := range existingSlice.OwnerReferences { owner := existingSlice.OwnerReferences[index] if owner.Kind == "Endpoints" && owner.Name == endpoints.Name && owner.UID != endpoints.UID { return true } } return false } </ins>

Discussion:
create a service without selector, and manual create endpoints for this service endpointslicemirroring controller will create an endpointslice for this service. after endpoint slice created, and kube-controller-manager restart. during the kube-controller-manager restart, the endpoint was deleted and recreated after kube-controller-manager restart, garbagecollector controller delete this endpointslice and endpointslice not recreate until endpoint/service update event or kube-controller-manager restart endpointslice will be recreated create a service without selector, and manual create endpoints for this service endpointslicemirroring controller will create an endpointslice for this service. after endpoint slice created, and kube-controller-manager restart. during the kube-controller-manager restart, the endpoint was deleted and recreated No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig network
/assign
Trying to understand this, mostly just restating what you've said above to make sure I'm getting it: during the kube-controller-manager restart, the endpoint was deleted and recreated after kube-controller-manager restart, garbagecollector controller delete this endpointslice and endpointslice not recreate until endpoint/service update event or kube-controller-manager restart So an Endpoints resource is being deleted while kube-controller-manager is not running. The EndpointSlice mirroring controller to point to the Endpoints they're mirroring. When kube-controller-manager is restarted, the garbage collector will delete the mirrored EndpointSlice because it's owned by an Endpoints resource that was previously deleted. That deletion by garbage collection would then be , but if the EndpointSliceTracker doesn't think it should have that resource, it will ignore the deletion and not reconcile, resulting in the mirrored EndpointSlice not being recreated until something updates the Service or Endpoints resource.
/triage accepted
Change:
## Create the MySQL Password Secret Use a [Secret](http://kubernetes.io/docs/user-guide/secrets/) object <del> to store the MySQL password. First create a temporary file called </del> <ins> to store the MySQL password. First create a file (in the same directory as the wordpress sample files) called </ins> `password.txt` and save your password in it. Make sure to not have a trailing newline at the end of the password. The first `tr` command will remove the newline if your editor added one. Then, create the

Discussion:
Version: Running this example on RHEL 7.2 (assume same for centos), and using hostPath, I get a permissions error when the mysql container does a . If I set selinux to permissive on the host it works. If I manually run the container with it works. I was not able to get it to work when adding to the deployment. My fix was to locate the PVs in by changing the local- file, and doing . I this comment to local- If this issue is valid I will create a quick PR to doc this selinux solution.
See pr
Change:
const ( // how long to wait for a resource quota update to occur <del> resourceQuotaTimeout = 30 * time.Second </del> <ins> resourceQuotaTimeout = time.Minute </ins> podName              = "pfpod" )

Discussion:
Which jobs are flaking: Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: Triage: Spyglass: /sig api-machinery
/sig scheduling /remove-sig api-machinery I get the log from the artifacts. ResourceQuota check for best-effort pod failed for a pod that is not scheduled due to below error that is expected as The scheduling error is expected. no error/warning messages in kube controller manager with resourcequotacontroller. The case was failed after 30 seconds. Try to fix it like for configmap check. It seems that resource quota status/used updating is not that quick.
/remove-sig scheduling /sig api-machinery
BTW, if we want to fix it in kube-controller-manager side. Increase the namespace syncs concurrent may help If there are some metrics, it can be proved to be right or wrong.
/cc /triage accept
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /cc /triage accept 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
/triage accepted
past weeks looks good to me, can we move it to observe?