jiebi/CodeConvo huggingface dataset:
Change:
ginkgo.By("Checking failure metrics") updatedControllerMetrics, err := metricsGrabber.GrabFromControllerManager() framework.ExpectNoError(err, "failed to get controller manager metrics") <del> updatedStorageMetrics := getControllerStorageMetrics(updatedControllerMetrics) </del> <ins> updatedStorageMetrics := getControllerStorageMetrics(updatedControllerMetrics, pluginName) </ins> framework.ExpectNotEqual(len(updatedStorageMetrics.statusMetrics), 0, "Error fetching c-m updated storage metrics") verifyMetricCount(storageOpMetrics, updatedStorageMetrics, "volume_provision", true)

Discussion:
Which jobs are flaking: () () Which test(s) are flaking: Reason for failure: Timeout: Anything else we need to know: This test flaking about 10% of the time in this job. /sig storage /kind flake /priority important-soon cc
/remove-kind failing-test
/assign
I noticed one issue with the test is that it's not filtering metrics by plugin name. So it will just count the last plugin's metric. I'm not sure if the metrics collected are in any sorted order or not. If not, then when you have a suite that runs multiple plugins, then you might be pulling from the wrong metric.
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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
/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
/remove-lifecycle rotten
still very prevalent in sig-release dashboards
I have pushed which should hopefully fix this.
Also PR against 1.17 branch -
Change:
// owner: @micahhausler // Deprecated: v1.31 // <del> // Disable Node Admission plugin validation of CSRs for kubelet signers where CN=system:node:$nodeName. </del> <ins> // Setting AllowInsecureKubeletCertificateSigningRequests to true disables node admission validation of CSRs // for kubelet signers where CN=system:node:$nodeName. </ins> // Remove in v1.33 <del> DisableKubeletCSRAdmissionValidation featuregate.Feature = "DisableKubeletCSRAdmissionValidation" </del> <ins> AllowInsecureKubeletCertificateSigningRequests featuregate.Feature = "AllowInsecureKubeletCertificateSigningRequests" </ins> // owner: @HirazawaUi // kep: http://kep.k8s.io/4004

Discussion:
This comes from We've a feature gate, . However, we try to name feature gates after the positive thing they add, even if it's on by default, or even if we're setting if false because the positive thing is being dropped (rare, but it happens). Typically we don't start feature gate names with , as it makes the docs jar: Example quote 1: To temporarily revert to the legacy behavior, enable the feature gate. vs Example quote 2: You can enable the feature gate if you run code that relies on the previous behavior. You should plan to migrate. and because disabling things isn't really a feature. Some examples of gates you can or once could disable by turning them off_ include: - - - So, I recommend a rename of the gate before the v1.31 release. /sig auth architecture
FYI
Example gate names: (off by default) (off by default) (on by default) (on by default) (on by default) from (off by default, deprecated)
/milestone v1.31
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your Milestone Maintainers Team and have them propose you as an additional delegate for this responsibility. <detailsIn response to : /milestone v1.31 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
Another possibility: , deprecated, off by default
Hello there! I am new to kubernetes and I want to contribute in it. Is it something that I can contribute to?
This issue is not a good issue for a first-time contributor to work on.
I'm a fan of , deprecated, off by default
hoping one of you are doing the PR? :) /milestone v1.31
Change:
} } <ins> // If the command is interrupted before the end (ctrl-c), flush the // profiling files c := make(chan os.Signal, 1) signal.Notify(c, os.Interrupt) go func() { <-c flushProfiling() os.Exit(0) }() </ins> return 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: While investigating I've found that kubectl doesn't handle sigterm with profiling. This way, when profiling a long run command (as wait, drain, etc) and interrupting the command in the middle (ctrl-c, as an example) the profile file is not available. What you expected to happen: Profiling file exists if the command exists correctly or if the command is interrupted with ctrl-c How to reproduce it (as minimally and precisely as possible): Execute a long run command (as kubectl drain, kubectl wait) with --profile=cpu and then interrupt the command before it finishes the execution Anything else we need to know?: Because kubectl deals with errors with an util (cmdutil.CheckErr) that in some specific time exists with os.Exit(1), it's not possible yet to also profile programs that exits. Environment: Kubernetes version (use ): kubectl compiled from upstream Cloud provider or hardware configuration: OS (e.g: ): Ubuntu 20.04
/sig cli /assign
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:
// registerHandler will register the caller in this server's list of slaves. // /set requests will be propagated to slaves, if any. func registerHandler(w http.ResponseWriter, r *http.Request) { <del> ip, _, err := net.SplitHostPort(r.RemoteAddr) </del> <ins> values, err := url.Parse(r.URL.RequestURI()) </ins> if err != nil { <del> fmt.Fprintf(w, "userip: %q is not IP:port", r.RemoteAddr) </del> <ins> http.Error(w, fmt.Sprintf("%v", err), http.StatusBadRequest) </ins> return } <del> log.Printf("GET /register, IP: %s", ip) </del> <ins> ip := values.Query().Get("host") log.Printf("GET /register?host=%s", ip) </ins> // send all the store to the slave as well. output := make(map[string]interface{})

Discussion:
Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Check Anything else we need to know: /cc /cc /sig cli /sig network /sig api-machinery /sig windows /priority critical-urgent /milestone v1.17
The label(s) cannot be applied. These labels are supported: <detailsIn response to : Which jobs are failing: Since when has it been failing: Testgrid link: Example: /cc /cc /sig network /sig api-machinery] /sig windows /milestone v1.17 </details
The label(s) cannot be applied. These labels are supported: <detailsIn response to : Which jobs are failing: Since when has it been failing: Testgrid link: Check /cc /cc /sig network /sig api-machinery] /sig windows /milestone v1.17 </details
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
The following have been fixed: For the DNS + Services tests, the issue is caused by: Bug report here: Disabling EndpointSlice feature-gate on kube-proxy should be enough to get them green again.
/cc
is back to just the guestbook test being solid red (tracked in ) 17 should green up similarly (was just fast-forwarded this morning)
This seems resolved. can we close this?
/close
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:
#   make generated_files .PHONY: generated_files generated_files: <del> $(MAKE) -f Makefile.$@ $@ CALLED_FROM_MAIN_MAKEFILE=1 </del> <ins> $(MAKE) -f Makefile.generated_files $@ CALLED_FROM_MAIN_MAKEFILE=1 # Verify auto-generated files needed for the build. # # Example: #   make verify_generated_files .PHONY: verify_generated_files verify_generated_files: $(MAKE) -f Makefile.generated_files $@ CALLED_FROM_MAIN_MAKEFILE=1 </ins>

Discussion:
Right now on head () if you run it will end up having a modified file. This happened because some type has been changed and this file should have been generated before commit, and verification should have failed but they didn't.
This is not only a problem with openapi-gen. deepcopy-gen also has the same problem. I've a field to a type (autoscaling/v1) and verify-all passed for the commit (without adding generated code to it). those files will be generated on verify-codegen and it will not fail and the commit can be merged without generated code.
Yeah. So when the Makefile stuff originally went in those files were not checked in. Then we un-did that part, but I didn't re-add them to verify...
Change:
want:        "", }, { <del> name:        "duplicate audience", in:          []string{"audience", "audience"}, matchPolicy: "MatchAny", want:        `issuer.audiences[1]: Duplicate value: "audience"`, </del> <ins> name:                          "duplicate audience", in:                            []string{"audience", "audience"}, matchPolicy:                   "MatchAny", want:                          `issuer.audiences[1]: Duplicate value: "audience"`, structuredAuthnFeatureEnabled: true, </ins> }, { <del> name: "match policy not set with multiple audiences", in:   []string{"audience1", "audience2"}, want: `issuer.audienceMatchPolicy: Invalid value: "": audienceMatchPolicy must be MatchAny for multiple audiences`, </del> <ins> name:                          "match policy not set with multiple audiences", in:                            []string{"audience1", "audience2"}, want:                          `issuer.audienceMatchPolicy: Invalid value: "": audienceMatchPolicy must be MatchAny for multiple audiences`, structuredAuthnFeatureEnabled: true, </ins> }, { <del> name:        "valid multiple audiences", </del> <ins> name:                          "valid multiple audiences", in:                            []string{"audience1", "audience2"}, matchPolicy:                   "MatchAny", want:                          "", structuredAuthnFeatureEnabled: true, }, { name:        "multiple audiences set when structured authn feature is disabled", </ins> in:          []string{"audience1", "audience2"}, matchPolicy: "MatchAny", <del> want:        "", </del> <ins> want:        `issuer.audiences: Invalid value: []string{"audience1", "audience2"}: multiple audiences are not supported when StructuredAuthenticationConfiguration feature gate is disabled`, </ins> }, } for _, tt := range testCases { t.Run(tt.name, func(t *testing.T) { <del> got := validateAudiences(tt.in, api.AudienceMatchPolicyType(tt.matchPolicy), fldPath, audienceMatchPolicyFldPath).ToAggregate() </del> <ins> got := validateAudiences(tt.in, api.AudienceMatchPolicyType(tt.matchPolicy), fldPath, audienceMatchPolicyFldPath, tt.structuredAuthnFeatureEnabled).ToAggregate() </ins> if d := cmp.Diff(tt.want, errString(got)); d != "" { t.Fatalf("Audiences validation mismatch (-want +got):n%s", d) }

Discussion:
For example, should not let you set discovery URL when the feature gate is not enabled. I believe this only impacts library users, as direct usage in KAS requires the file based config, which is feature gated. /assign enj aramase /milestone v1.32
Change:
APIServerTracing: {Default: true, PreRelease: featuregate.Beta}, <ins> APIServingWithRoutine: {Default: true, PreRelease: featuregate.Beta}, </ins> ValidatingAdmissionPolicy: {Default: false, PreRelease: featuregate.Beta}, CustomResourceValidationExpressions: {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.31

Discussion:
Optimize the memory usage of goroutine stack for serving watch requests. According to the of handling a watch request, the stack memory is 0x3768, which is very close to 16 KiB and Golang runtime will double it to 32 KiB once exceeded. In fact, it does exceed if we print the traceback deeper and take the fact that extra stack memory reserved by Golang itself into consideration. A naive optimization is to run as much as preparation handlers in a separate goroutine and then move the actual serving to another goroutine, so the former routine can free the stack memory earlier and make it more memory efficient. Given the extensive use of watch requests, 32 KiB per watch could add up to a very high amount of memory overhead for . A typical watch request commonly lasts for 30s or longer, which means this memory will be active for quite long. I see a great improvement in memory efficiency to do this optimization.
/cc
/sig api-machinery
/cc if you would like to take a look when you have time :) Thank you /triage accepted
Change:
} cache.podStates[key] = ps default: <del> return fmt.Errorf("pod was already in added state. Pod key: %v", key) </del> <ins> return fmt.Errorf("pod %v was already in added state.", 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:
if len(agg) == 1 { return agg[0].Error() } <del> result := fmt.Sprintf("[%s", agg[0].Error()) for i := 1; i < len(agg); i++ { result += fmt.Sprintf(", %s", agg[i].Error()) </del> <ins> seenerrs := sets.NewString() result := "" agg.visit(func(err error) { msg := err.Error() if seenerrs.Has(msg) { return } seenerrs.Insert(msg) if len(seenerrs) > 1 { result += ", " } result += msg }) if len(seenerrs) == 1 { return result } return "[" + result + "]" } func (agg aggregate) visit(f func(err error)) { for _, err := range agg { switch err := err.(type) { case aggregate: err.visit(f) case Aggregate: for _, nestedErr := range err.Errors() { f(nestedErr) } default: f(err) } </ins> } <del> result += "]" return result </del> } // Errors is part of the Aggregate interface.

Discussion:
What happened: I configured my API server with a Webhook token authentication server by way of the "authentication-token-webhook-config-file" command-line flag, and confirmed that the API server does pass bearer tokens through, issuing HTTP POST requests with a JSON-encoded body. When my Webhook server indicates authentication failure, it responds with HTTP status code 200 and a JSON-encoded in the body, this time with the object's "Error" field populated. Here's an example: When the API server receives this response, it refuses the original motivating request with an HTTP status code 401 response, but the API server writes the following into its log file: This use of this default error message is due to an omission in file , where , and . What you expected to happen: The API server should instead log a message that includes the value from . Per a brief discussion with , he agreed that the API server log message should include such an error message from the Webhook server, provided it's present and nonempty. How to reproduce it (as minimally and precisely as possible): Configure an API server to delegate to a Webhook token authentication server. Force that Webhook server to respond "successfully" with an HTTP 200 response, but with the "Authenticated" field set to false (or omitted) and with a particular error message in the "Error" field. Make an HTTP request of the API server with an HTTP "Authentication" header with a value starting with the string "Bearer " followed by at least one more character. Inspect the logs from the API server, looking for a message that begins with "Unable to authenticate the request due to an error." Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS EC2 OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: kubeadm_
/sig auth
/assign
Change:
--service-cluster-ip-range="10.0.0.0/24" 1>&2 & APISERVER_PID=$! <del> kube::util::wait_for_url "http://127.0.0.1:${API_PORT}/healthz" "apiserver: " </del> <ins> kube::util::wait_for_url "http://127.0.0.1:${API_PORT}/healthz" "apiserver" </ins> # Start controller manager <del> kube::log::status "Starting CONTROLLER-MANAGER" </del> <ins> kube::log::status "Starting controller-manager" </ins> "${KUBE_OUTPUT_HOSTBIN}/kube-controller-manager"  --machines="127.0.0.1"  <ins> --port="${CTLRMGR_PORT}"  </ins> --master="127.0.0.1:${API_PORT}" 1>&2 & CTLRMGR_PID=$! <del> kube::util::wait_for_url "http://127.0.0.1:${CTLRMGR_PORT}/healthz" "controller-manager: " kube::util::wait_for_url "http://127.0.0.1:${API_PORT}/api/v1beta3/nodes/127.0.0.1" "apiserver(nodes): " 0.2 25 </del> <ins> kube::util::wait_for_url "http://127.0.0.1:${CTLRMGR_PORT}/healthz" "controller-manager" kube::util::wait_for_url "http://127.0.0.1:${API_PORT}/api/v1beta3/nodes/127.0.0.1" "apiserver(nodes)" </ins> # Expose kubectl directly for readability PATH="${KUBE_OUTPUT_HOSTBIN}":$PATH

Discussion:
Example:
Is kubelet healthz coupled with the docker daemon being accessible? ?
That particular error is coming from cAdvisor and should not be causing the test to block. The Kubelet does wait up to 5min for Docker to come up though. Do we use a real Docker in these tests?
Shippable is running on different os dist? ContainerOsVersion:Ubuntu precise?
Yes today kubelet healthz coupled with docker daemon. We even periodically healthcheck docker and kubelet, and restart them even there are issues.
Another example:
bumping priority because we have to get these flaky tests fixed.
This has been marked P0 for 2 months but hasn't had any updates. Is this still happening on Shippable? If so, can we just increase a timeout in the test?
This is ridiculous, I'll fix it myself.
Change:
# Print 1 if the file in $1 is not in need of additional field descriptions, 0 otherwise. FILE="$1" <del> if grep json: "${FILE}" | grep -v ,inline | grep -v -q description: | grep -v // ; then </del> <ins> if grep json: "${FILE}" | grep -v // | grep -v ,inline | grep -v -q description: ; then </ins> echo "0" else echo "1"

Discussion:
PR had a few errors in its API objects, where the "description" field errors in its JSON declarations were missing. But, the "verify-" presubmit check didn't flag them. This should be investigated and fixed.
Could you please take a look at this?
Change:
}) ginkgo.BeforeEach(func() { <ins> if err := lookEmitSignalCommand(); err != nil { e2eskipper.Skipf("skipping test because: %v", err) return } </ins> ginkgo.By("Wait for the node to be ready") waitForNodeReady()

Discussion:
Failing on cri-o serial job. Looks like the dbus command isn't available for graceful shutdown tests that aren't running on Ubuntu. /assign /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
/triage accepted /priority important-soon
/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
hmm, is this still issue? The testgrid job is still failing even after the fix appears to be merged? !
Please take a look when you get a chance, the error still seems to be that dbus-send is unavailable... /cc
oops... I forgot to add this to the other
Change:
"golang.org/x/net/websocket" <ins> "go.opentelemetry.io/otel/propagation" sdktrace "go.opentelemetry.io/otel/sdk/trace" "go.opentelemetry.io/otel/sdk/trace/tracetest" "go.opentelemetry.io/otel/trace" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types" utilnet "k8s.io/apimachinery/pkg/util/net" "k8s.io/apimachinery/pkg/util/proxy" "k8s.io/apimachinery/pkg/util/sets" "k8s.io/apiserver/pkg/authentication/user" <ins> "k8s.io/apiserver/pkg/endpoints/filters" </ins> genericapirequest "k8s.io/apiserver/pkg/endpoints/request" "k8s.io/apiserver/pkg/server/egressselector" utilflowcontrol "k8s.io/apiserver/pkg/util/flowcontrol"

Discussion:
Extension API servers do not currently receive the header when requests are proxied through kube-aggregator, so spans are not linked properly. Traces from the extension API sever should be linked to the parent in kube-aggregator. tracing for kube-apiserver tracing for sample-apiserver and aggregate it to kube-apiserver a request to kube-apiserver for one of the resources from sample-apiserver sample-apiserver traces will not be linked to the kube-apiserver traces No response <detailsThis problem currently exists on . </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/cc /triage accepted