jiebi/CodeConvo huggingface dataset:
Change:
} return nil } <del> if ignoreFile(path, extensions) { </del> <ins> // Don't check extension if the filepath was passed explicitly if path != paths && ignoreFile(path, extensions) { </ins> return nil }

Discussion:
It works when I pipe but not with filename.
broke in this commit cc
Did you try to add an extension .json to the file? We filter for file extensions
ahhh ok. so working as intended. it used to autodetect :( ... thanks
That was unintended. The file extensions should only be used for deciding which files in a directory to process. For a single file, any extension should be allowed. We don't actually infer the content type from the extensions. For stdin and http sources, for instance, there are no extensions. cc
Fix is pretty straightforward (ignore file extensions when dealing with single file); I have it working with manual test, just adding unit test. Will send shortly.
Thanks, but this is v1.0-post, so no rush
Change:
start program = "/etc/init.d/kubelet start" stop program = "/etc/init.d/kubelet stop" if does not exist then restart <ins> if failed port 10250 protocol HTTP request "/healthz" with timeout 10 seconds then restart </ins>

Discussion:
We've run into issues like where the Kubelet was up but not healthy. The monit monitoring for Kubelet should ensure it is "healthy" rather than just alive. We need to define what healthy means in this context and monitor it based on that. An alternate option is for the Kubelet to exit when it gets into a situation it can't serve from. This may lead to crashloops so we'd need to be careful going this route. The answer is probably a bit of both.
Courtesy of healthchecking with monit:
Health check is under this umbrella issue:
Will send a PR shortly.
Change:
return b.String() } <del> // RunTogether returns an error the lhs and rhs run together </del> <ins> // RunTogether returns an error if containers don't run together </ins> func (o containerOutputList) RunTogether(lhs, rhs string) error { <ins> if err := o.RunTogetherLhsFirst(lhs, rhs); err != nil { if err := o.RunTogetherLhsFirst(rhs, lhs); err != nil { return err } } return nil } // RunTogetherLhsFirst returns an error if containers don't run together or if rhs starts before lhs func (o containerOutputList) RunTogetherLhsFirst(lhs, rhs string) error { </ins> lhsStart := o.findIndex(lhs, "Started", 0) if lhsStart == -1 { return fmt.Errorf("couldn't find that %s ever started, gotn%v", lhs, o)

Discussion:
master-blocking: ci-node-e2e Recent failures: No response /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
is also similar. The fix for that was bumping the delay time.
Hi Vyom - would this be a good first issue because there is a previous similar solution?
I hit the same failure in my . This seems caused because expects the regular container to start before the postStart: I posted a PR() to add to the postStart. However, there are other approaches such as: Introduce as mentioned . Remove from this test case because this check does not look the primary purpose of this testcase.
The test mentioned by is similar to this flake and doesn't use . I can just remove it. I'm also going to add a comment on RunTogether to indicate it expects ordering to be enforced. That being said, shouldn't PostStart be enforced to run after the container is started? /assign
Hey PRs are more than welcome :)
I've submitted the PR, let me know if I didn't follow any best practices or anything else is required, thanks!
Skipped after was merged. Last CI run passed. /close
Closing this issue. <detailsIn response to : Skipped after was merged. Last CI run passed. </details
/reopen close the wrong one: is closed for swap test skip. this is for another flake. Sorry.
Reopened this issue. <detailsIn response to : /reopen close the wrong one: is closed for swap test skip. this is for another flake. Sorry. 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:
}, expectedTrace: []*spanExpectation{ { <del> name: "KubernetesAPI", </del> <ins> name: "GET /api/v1/nodes", </ins> attributes: map[string]func(*commonv1.AnyValue) bool{ "http.user_agent": func(v *commonv1.AnyValue) bool { return strings.HasPrefix(v.GetStringValue(), "tracing.test")

Discussion:
When enable apiserver tracing, the webhook request spans only show spanName as /, mostly because use http request operations as default span name, which is hard to understand. ! Following the open-telemetry standard of spanName, it's recommended to use as spanName. ! SpanName of webhook request should be , like ! APIServerTracing feature gates of apiserver a pod tracing dashboard No response <details18 </details<detailsNone </details<details</details<details</details<details</details<details</details
I make a fix for this.
/sig api-machinery instrumentation
Do you know if this is fixed in later versions of opentelemetry?
/triage accepted /assign
Looks like might be related
not yet, I think we can fix this in otel upstream, but it's hard to backport to otel , which is the version of otel used in Kubernetes
Good point. It think fixing it here is a good idea in that case.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs 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 or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
could I take on this issue?
yes. Feel free to work on this.
! I test locally by 1.29 kubernetes and start a sample webhook, looks like the client span has already conforms to semantic conventions , which should be in the form of "HTTP {METHODNAME}"
! For apiserver as a server, now the spanName is still KubernetesAPI, which I think we could enhance it into "HTTP get_account/{accountId}" format
After digging for a while, I found one solution to implement this, I draft this idea in , could you help review about whether this is a correct way to implement it?
Change:
"//staging/src/k8s.io/apiserver/pkg/admission:go_default_library", "//staging/src/k8s.io/apiserver/pkg/admission/initializer:go_default_library", "//staging/src/k8s.io/client-go/kubernetes:go_default_library", <ins> "//vendor/k8s.io/klog:go_default_library", </ins> ], )

Discussion:
Look, here is the thing, this is only useful IF you are only exposing the kube api to the end user. AND even then if you do not prevent mounting the host into containers via a PodSecurityPolicy then you could just exec in by combining the file descriptors.... Like this window dressing of a feature is kinda un-useful and people are enabling it under circumstances where it is just plain stupid.... there is literally no point to this feature if you do not also have a pod security policy in place preventing people from mounting shit in to literally exec. Or if users have access to the nodes in the first place it makes literally no sense.
/sig auth
/sig node cc
Agreed. I would much prefer to see this done with a combination of RBAC, namespaces, and PodSecurityPolicy. For example: Allow privileged pods in the "privileged" namespace (PodSecurityPolicy), do not allow exec in that namespace (RBAC) Forbid privileged pods in the "unprivileged" namespace (PSP), allow exec in that namespace PSP actually covers enough ground to properly prevent escalating exec (privileged, capabilities, host paths, etc.).
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
/remove-lifecycle rotten
opened to mark as deprecated
Thanks
Change:
func (j *TestJig) checkClusterIPServiceReachability(svc *v1.Service, pod *v1.Pod) error { clusterIP := svc.Spec.ClusterIP servicePorts := svc.Spec.Ports <del> externalIPs := svc.Spec.ExternalIPs </del> err := j.waitForAvailableEndpoint(ServiceEndpointsTimeout) if err != nil {

Discussion:
Which jobs are failing: Which test(s) are failing: - Since when has it been failing: Testgrid link: Reason for failure: Nov 4 11:59:41.385: Unexpected error: &lt;*errors.errorString | 0xc00298c3d0: { s: "service is not reachable within 2m0s timeout on endpoint 203.0.113.250:80 over TCP protocol", } service is not reachable within 2m0s timeout on endpoint 203.0.113.250:80 over TCP protocol occurred Anything else we need to know: /priority important-soon /sig network /cc
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
Apparently this is related to /cc
if you're busy and want me to take a look tomorrow you can assign that to me and I can deep dive into what's missing/happening :) Happy to help and to understand better the flakiness life
so, the test adds a "fake" external IP that should be nated to the service endpoint It went through the CI, you can check the test here passing more details in the issue I opened explaining the test
ok, this is interesting the test is failing when using container runtime DOCKER https://k8s- the same periodic job that uses container runtime CONTAINERD (same as the PR) is working https://k8s- We need to understand what is different regarding the network in GCE jbos, when using docker as runtime, kubenet??? cc:
one diff between the working jobs with containerd and the failing ones with docker is that the failing ones use this part of the code for reference, kube-proxy adds the NAT rules here for external IPs here
IIRC you are using kubenet for azure jobs, are you using docker as runtime, can you please check if this tests fails there too?
The problem happens on environment that are using the bridge plugin, seems I got wrong the feature will revert until we have the right test.

We use kubenet only for IPv6 and dualstack jobs. Rest of the tests use Azure CNI. Default is docker runtime for all jobs.
Change:
} // Run tests in archive against host <del> func testHost(host, archive string) *TestResult { output, err := e2e_node.RunRemote(archive, host, *cleanup) </del> <ins> func testHost(host, archive string, deleteFiles bool) *TestResult { output, err := e2e_node.RunRemote(archive, host, deleteFiles) </ins> return &TestResult{ output: output, err:    err,

Discussion:
Looks like it maybe the ssh connect is getting killed
The relevant log snippet:
And another one, not just coreos.
Change:
- [CPU and Memory manager are not working correctly for Guaranteed Pods with multiple containers](#cpu-and-memory-manager-are-not-working-correctly-for-guaranteed-pods-with-multiple-containers) - [`CSIMigrationvSphere` feature gate has not migrated to new CRD APIs](#csimigrationvsphere-feature-gate-has-not-migrated-to-new-crd-apis) - [Workloads that saturate nodes with pods may see pods that fail due to node admission](#workloads-that-saturate-nodes-with-pods-may-see-pods-that-fail-due-to-node-admission) <del> - [Etcd v3.5.[0-2] data corruption](#etcd-v350-2-data-corruption) </del> <ins> - [Etcd v3.5.[0-2] data corruption](#etcd-v350-2-data-corruption) </ins> - [Urgent Upgrade Notes](#urgent-upgrade-notes) - [(No, really, you MUST read this before you upgrade)](#no-really-you-must-read-this-before-you-upgrade) - [Changes by Kind](#changes-by-kind-15)

Discussion:
The section of the Changelog for 1.23.14 (and sibling bugfix releases) says that 1.23.13 both has the vuln and also has the fix. The Fix version should be 1.23.14 in the above and sibling changelogs. Load the link above. No response N/A N/A N/A N/A N/A N/A
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 docs
cc
For v1.23.14, the title is . This seems to be valid. means
You're looking at the wrong text. Follow the link and see .13 in both lists: kube-apiserver v1.25.0 - v1.25.3 kube-apiserver v1.24.0 - v1.24.7 kube-apiserver v1.23.0 - v1.23.13 kube-apiserver v1.22.0 - v1.22.15 kube-apiserver <= v1.21.? kube-apiserver v1.25.4 kube-apiserver v1.24.8 kube-apiserver v1.23.13 kube-apiserver v1.22.16
Got it. Thanks for pointing out the location.
I opened to fix it.
/reopen Can you please cherry-pick to the release branches (1.25-1.22)?
Reopened this issue. <detailsIn response to : /reopen Can you please cherry-pick to the release branches (1.25-1.22)? 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
Of course. Done
Cherry-picks are done, thanks a lot /close
Closing this issue. <detailsIn response to : Cherry-picks are done, thanks a lot /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:
// annotation stored in the given endpoints object or the "zero" time if the annotation wasn't set // or was set incorrectly. func getLastChangeTriggerTime(endpoints *v1.Endpoints) time.Time { <ins> if _, ok := endpoints.Annotations[v1.EndpointsLastChangeTriggerTime]; !ok { // It's possible that the Endpoints object won't have the EndpointsLastChangeTriggerTime // annotation set. In that case return the 'zero value', which is ignored in the upstream code. return time.Time{} } </ins> val, err := time.Parse(time.RFC3339Nano, endpoints.Annotations[v1.EndpointsLastChangeTriggerTime]) if err != nil { klog.Warningf("Error while parsing EndpointsLastChangeTriggerTimeAnnotation: '%s'. Error is %v",

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!--What happened: The kube- is full of the following log lines: W0213 00:00:40. 1 ] Error while parsing EndpointsLastChangeTriggerTimeAnnotation: ''. Error is parsing time "" as "2006-01-02T15:04:05.999999999Z07:00": cannot parse "" as "2006" This is caused by the recent merge of What you expected to happen: We shouldn't log warning when EndpointsLastChangeTriggerTimeAnnotation is not set How to reproduce it (as minimally and precisely as possible): Set-up cluster, create some endpoints objects, go to the any node and open the kube-
This was caused by so assigning sig/scalability /sig scalability
Change:
// TODO: allow selection from command line. (e.g., just check links in the examples directory.) allMunges = []munge{ {"table-of-contents", updateTOC}, <ins> {"unversioned-warning", updateUnversionedWarning}, </ins> {"check-links", checkLinks}, {"blank-lines-surround-preformatted", checkPreformatted}, {"header-lines", checkHeaderLines}, <del> {"unversioned-warning", updateUnversionedWarning}, </del> {"analytics", checkAnalytics}, {"kubectl-dash-f", checkKubectlFileTargets}, }

Discussion:
If you try mimicking the release flow for a release on right now, it's busted: If I generate a dummy commit out of that failure, then run to see what gets generated, it's attempting to actually add the unversioned warnings back in: I was trying to write up a PR to enact something for , but this blocks the release piece for that. Which is fine, we have some time.
cc
Running gendocs should add the unversioned warnings, unless the doc has <!-- TAG IS_VERSIONED --. Do you know if mark-new-version that tag before failing?
Ah, I think I see what might be happening. This is the post- version of Notice the newline fun.
Sorry which newline are you talking about? :)
My PR fixes that
Ah, yes, cool. It would help if you flagged functional changes along more loudly. :)
Yea, sorry about that. Have updated the PR description to highlight each fix.
Change:
<ins> /* Copyright 2017 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package group import ( "net/http" "k8s.io/apiserver/pkg/authentication/authenticator" "k8s.io/apiserver/pkg/authentication/user" ) // AuthenticatedGroupAdder adds system:authenticated group when appropriate type AuthenticatedGroupAdder struct { // Authenticator is delegated to make the authentication decision Authenticator authenticator.Request } // NewAuthenticatedGroupAdder wraps a request authenticator, and adds the system:authenticated group when appropriate. // Authentication must succeed, the user must not be system:anonymous, the groups system:authenticated or system:unauthenticated must // not be present func NewAuthenticatedGroupAdder(auth authenticator.Request) authenticator.Request { return &AuthenticatedGroupAdder{auth} } func (g *AuthenticatedGroupAdder) AuthenticateRequest(req *http.Request) (user.Info, bool, error) { u, ok, err := g.Authenticator.AuthenticateRequest(req) if err != nil || !ok { return nil, ok, err } if u.GetName() == user.Anonymous { return u, true, nil } for _, group := range u.GetGroups() { if group == user.AllAuthenticated || group == user.AllUnauthenticated { return u, true, nil } } return &user.DefaultInfo{ Name:   u.GetName(), UID:    u.GetUID(), Groups: append(u.GetGroups(), user.AllAuthenticated), Extra:  u.GetExtra(), }, true, nil } </ins>

Discussion:
When an auth proxy tries to proxy an anonymous request, the user.Info ends up with the group system:authenticated, which is wrong.
Change:
# We don't join cockroachdb in order to avoid a node attempting # to join itself, which currently doesn't work # (https://github.com/cockroachdb/cockroach/issues/9625). <del> CRARGS+=("--join" "cockroachdb-public") </del> <ins> CRARGS+=("--join" "cockroachdb-0.cockroachdb,cockroachdb-1.cockroachdb,cockroachdb-2.cockroachdb") </ins> fi exec /cockroach/cockroach ${CRARGS[*]} # No pre-stop hook is required, a SIGTERM plus some time is all that's

Discussion:
Seems to be broken for at least the past two weeks. /sig apps /area test
can you take a look please?
Absolutely, I'll take a look today. Sorry guys!
thanks!
Change:
# Finds the master PD device find-master-pd() { <ins> if ( grep "/mnt/master-pd" /proc/mounts ); then echo "Master PD already mounted; won't remount" MASTER_PD_DEVICE="" return fi </ins> echo "Waiting for master pd to be attached" attempt=0 while true; do

Discussion:
We currently remount the master PD every boot, as part of the GCE instance-boot script. I'm wondering if this is safe: if we have services that start concurrently, should we put the master-pd into /etc/fstab instead? I think we'll have to do this on AWS, in any case.
any thoughts on whether we should also do this for GCE?
too for I don't pretend to understand the startup dance of the various master components like etcd, kube*, etc., though it does seem reasonable to add it to /fstab to me. I'm also interested in getting us to something other than containervm like trusty and friends and getting rid of as much of the instance-boot dance as possible.
helped build the master pd dance and may have some input as well.
Actually did the initial work there. The main problem is that GCE PDs (I don't know if this is different in AWS?) are unformatted, so at least on cluster creation, we have to come up, format and mount them. I don't think we can easily move it inside until after first boot.
If I understand correctly, new EBS volumes also start unformatted, and it looks as though something like would still let us automatically format the disk on initial startup because the fstab entry wouldn't exist on the first boot.
Although if there is some sort of race among services starting up on boot, we'll still hit that problem on the initial boot, and on the initial boot of each recreated master VM if we tear it down and bring it back up with the same disk/IP for upgrades.
ping - someone who understands this issue (not me) please confirm doing this for GCE is a 1.2 blocker, or else move it to next-candidate or remove milestone tag completely and demote to P2.
I wouldn't consider it a 1.2 blocker to do this for GCE -
I don't either. I'd actually rather not touch this path right now; we've lived with it this way for a while.
OK well we can see how it goes on AWS :-)
/sig cluster-lifecycle
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. Prevent issues from auto-closing with an comment.

If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/close
Change:
// Prints summary metrics for request types with latency above threshold // and returns number of such request types. func HighLatencyRequests(c *client.Client, threshold time.Duration, ignoredResources util.StringSet) (int, error) { <ins> ignoredVerbs := util.NewStringSet("WATCHLIST", "PROXY") </ins> metrics, err := ReadLatencyMetrics(c) if err != nil { return 0, err

Discussion:
I saw the below failure in [Performance suite] should allow starting 30 pods per node. Some requests with verb:PROXY took more than 10 seconds, and are causing the test to fail. I think that proxy issues are a different test, right? (maybe testMonitoringUsingHeapsterInfluxdb?) And that this taking 10 seconds could be very reasonable, depending on what we're proxying. There is this note in If that is the case, sounds like we should either clear the metrics, or if that is hard, record them before we run our test and ignore the pre-existing ones.
Yeah we should clearly exclude proxy from those metrics. This test is still being actively worked on :)
+1 for excluding proxy metrics This should be very simple fix, because we're already exluding all "watches" from the metrics. Reassigning it to me - will fix it today.
is sent out for review.
thanks for fixing!