jiebi/CodeConvo huggingface dataset:
Change:
}, expectedTrace: []*spanExpectation{ { <del> name: "KubernetesAPI", </del> <ins> name: "POST /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:
// if container doesn't exist, create one and retry PutPageBlob detail := err.Error() if strings.Contains(detail, errContainerNotFound) { <del> err = blobClient.CreateContainer(vhdContainerName, azs.ContainerAccessTypeContainer) </del> <ins> err = blobClient.CreateContainer(vhdContainerName, azs.ContainerAccessTypePrivate) </ins> if err == nil { err = blobClient.PutPageBlob(vhdContainerName, name, vhdSize, tags) }

Discussion:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig azure
fixed by
/label official-cve-feed (Related to kubernetes/sig-security)
Change:
"k8s.io/client-go/openapi/cached" "k8s.io/client-go/openapi/openapitest" "k8s.io/client-go/openapi3" <ins> "k8s.io/kube-openapi/pkg/spec3" </ins> ) func TestV3SupportsQueryParamBatchV1(t *testing.T) {

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: Following the example here: Everything here works when you use , but when using 1.27.1, I see the following panic: What you expected to happen: When downgrading, this works as expected: How to reproduce it (as minimally and precisely as possible): <!-- Please make sure you are able to reproduce the bug using a supported version and version skew of Kubernetes. See for which versions and are currently supported. --You will need a Kubernetes cluster with Agones installed (I'm testing on 1.25.x, as you can see above), then follow this quickstart: Anything else we need to know?: The is implemented as an API Extension, not a CRD -- which is probably where the issue lies. Looking at the line: There seems to be an assuming that there will be a under and , in - there should be some nil checks in there. Environment: Kubernetes client and server versions (use ): See above Cloud provider or hardware configuration: GKE OS (e.g: ): Linux
seems like an another edge case; Due to the server version is old and openapiv3 is returning empty?
Thanks for opening this issue /triage accepted
I'm digging into the Agones code, but I'm 99.4% sure we don't even implement openapiv3 at all for our api endpoint
Yep, confirmed -- I see a bunch of 404's in my API Extension logs for requests for
/transfer kubernetes /kind regression
/sig cli /assign
I can also work on tomorrow if Sean can not get time to look at it
If nothing else, this does also force me to publish an openapi spec for our API extension
not sure if needed to handle nils inside the schema better, or if didn't fall back to v2 correctly in the absence of v3 data
It appears to be the former, where an OpenAPI V3 document is returned without , while the code assumes this field is non-nil.
seems like that should still fall back to v2
Can we get a kubectl -v8 to see what actually happens with downloading the OpenAPI?
As requested!

Thanks for the quick response. It looks like the OpenAPI V3 document is almost completely empty The code is expecting an Open API document with . I will have a fix out shortly.
I was digging through that - I found that really interesting. We only expose an basically empty spec for the api extension. It's always "just worked", so never needed to update it. I am curious where K8s is even getting the something that it is outputting for , but that's a side note.
Change:
"k8s.io/kubernetes/pkg/scheduler/framework" "k8s.io/kubernetes/pkg/scheduler/framework/parallelize" "k8s.io/kubernetes/pkg/scheduler/metrics" <ins> "k8s.io/kubernetes/pkg/util/slice" </ins> ) const (

Discussion:
Scheduler's default plugin returns an invalid score that is not in the range of [0, 100], resulting in no Pods being scheduled: After investigation, I found that there was a bug in the code that built the framework when the scheduler started. When using the plugins declared in the regular extension point to override the plugins declared in the MultiPoint, the traversed variable will be modified in the following loop: This may cause a same scoring plugin (e.g. ) to be loaded multiple times: Further, this results in a node being processed multiple times by a plugin's (e.g. 's) method, resulting in an invalid score that is not in the range of [0, 100]: If the scheduler's MultiPoint feature is used (either through the default plugins or through manual configuration), and the configuration (e.g. the scoring weight) of a certain plugin is overridden in a regular extension point, the plugin will only be loaded once in this extension point, and no illegal scores will be returned. An example KubeSchedulerConfiguration: No response K8s v1.24.15 or higher None <details</details<details</details<details</details<details</details
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 scheduling
Can I work on this?
this is being worked on. see
I see, Is there any other task that you are aware of and I can work on? Thanks.
Change:
return resTags.Items } <ins> // GetNodeTags gets k8s node tag from one of the nodes func GetNodeTags(c clientset.Interface, cloudConfig CloudConfig) []string { nodes := GetReadySchedulableNodesOrDie(c) if len(nodes.Items) == 0 { Logf("GetNodeTags: Found 0 node.") return []string{} } return GetInstanceTags(cloudConfig, nodes.Items[0].Name).Items } </ins> // GetInstancePrefix returns the INSTANCE_PREFIX env we set for e2e cluster. // From cluster/gce/config-test.sh, master name is set up using below format: // MASTER_NAME="${INSTANCE_PREFIX}-master"

Discussion:
1 tests failed, 3 jobs failed, 73 builds failed. Failure stats cover 1 day time range '26 Jun 2017 23:52 UTC' to '27 Jun 2017 23:52 UTC'. <details<summaryRationale for assignments:</summary </details<br
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
This was broke by . I'm working on a fix for this. /assign
Change:
"context" "fmt" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/runtime" corelisters "k8s.io/client-go/listers/core/v1" "k8s.io/klog" <del> "k8s.io/kubernetes/pkg/scheduler/algorithm/predicates" "k8s.io/kubernetes/pkg/scheduler/framework/plugins/migration" </del> framework "k8s.io/kubernetes/pkg/scheduler/framework/v1alpha1" schedulerlisters "k8s.io/kubernetes/pkg/scheduler/listers" "k8s.io/kubernetes/pkg/scheduler/nodeinfo"

Discussion:
Part of See example /sig scheduling /kind cleanup /help /priority important-soon
/assign /remove-help
Change:
statusCode:         http.StatusForbidden, reqPath:            "/apis", reason:             "Forbidden", <del> message:            `forbidden: User "" cannot get path "/apis": Everything is forbidden.`, </del> <ins> message:            `forbidden: User "unprivileged" cannot get path "/apis": Everything is forbidden.`, </ins> }, { name:               "401",

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/kind flake <!-- Please assign a SIG using: /sig SIG-NAME --/sig api-machinery
/assign I want to take a try
2 but actual 0 till timeout resource services, expected 2, actual 0 error waiting or ResourceQuota status: timed out waiting for the condition time later, actual state became 2 Seems polls a ResourceQuota status with timeout 10s may be not enough, we should enlarge it into 300s, that is poll for 300s timeout instead of 10s.
/triage accepted
Change:
} // ConstructFirewallForIngress returns the expected GCE firewall rule for the ingress resource <del> func (j *IngressTestJig) ConstructFirewallForIngress(gceController *GCEIngressController, nodeTag string) *compute.Firewall { </del> <ins> func (j *IngressTestJig) ConstructFirewallForIngress(gceController *GCEIngressController, nodeTags []string) *compute.Firewall { </ins> nodePorts := j.GetIngressNodePorts() fw := compute.Firewall{} fw.Name = gceController.GetFirewallRuleName() fw.SourceRanges = gcecloud.LoadBalancerSrcRanges() <del> fw.TargetTags = []string{nodeTag} </del> <ins> fw.TargetTags = nodeTags </ins> fw.Allowed = []*compute.FirewallAllowed{ { IPProtocol: "tcp",

Discussion:
1 tests failed, 3 jobs failed, 73 builds failed. Failure stats cover 1 day time range '26 Jun 2017 23:52 UTC' to '27 Jun 2017 23:52 UTC'. <details<summaryRationale for assignments:</summary </details<br
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
This was broke by . I'm working on a fix for this. /assign
Change:
Args: []string{ "/bin/sh", "-c", <del> fmt.Sprintf("for i in $(seq 1 5); do wget -T 8 %s.%s:%d -O - && exit 0 || sleep 1; done; exit 1", </del> <ins> fmt.Sprintf("for i in $(seq 1 5); do curl -s -m 8 %s.%s:%d && exit 0 || sleep 1; done; exit 1", </ins> targetService.Name, targetService.Namespace, targetPort), }, },

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig testing What happened: Some commands used in tests are Linux specific and do not exist or do not behave the same on Windows nodes. This can cause those tests to fail on Windows nodes. Some of the tests are: [sig-network] Networking Granular Checks: Pods should function for node-pod communication: http [NodeConformance] [sig-network] Networking Granular Checks: Pods should function for node-pod communication: udp [NodeConformance] [sig-network] Networking Granular Checks: Services [Slow] should function for node-Service: http [sig-network] Networking Granular Checks: Services [Slow] should function for node-Service: udp [sig-network] Networking Granular Checks: Services [Slow] should update nodePort: http [Slow] [sig-network] Networking Granular Checks: Services [Slow] should update nodePort: udp [Slow] [sig-network] NetworkPolicy NetworkPolicy between server and client should support a 'default-deny' policy [Feature:NetworkPolicy] [sig-network] NetworkPolicy NetworkPolicy between server and client should enforce policy based on PodSelector [Feature:NetworkPolicy] [sig-network] NetworkPolicy NetworkPolicy between server and client should enforce policy based on NamespaceSelector [Feature:NetworkPolicy] [sig-network] NetworkPolicy NetworkPolicy between server and client should enforce policy based on Ports [Feature:NetworkPolicy] [sig-network] NetworkPolicy NetworkPolicy between server and client should enforce multiple, stacked policies with overlapping podSelectors [Feature:NetworkPolicy] [sig-network] NetworkPolicy NetworkPolicy between server and client should support allow-all policy [Feature:NetworkPolicy] [sig-network] NetworkPolicy NetworkPolicy between server and client should allow ingress access on one named port [Feature:NetworkPolicy] [sig-network] NetworkPolicy NetworkPolicy between server and client should allow egress access on one named port [Feature:NetworkPolicy] What you expected to happen: The commands used by those tests should be platform agnostic, so they can pass using Windows Nodes as well. How to reproduce it (as minimally and precisely as possible): Run the mentioned tests using Windows Nodes. Anything else we need to know?

: Environment: Kubernetes version (use ): v1.12.0-rc.2 Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): Windows Server 1803 compute nodes Kernel (e.g. ): N/A Install tools: N/A Others:
Change:
import ( "encoding/json" "testing" <del> "github.com/GoogleCloudPlatform/kubernetes/pkg/api" </del> ) <ins> type FakeJSONBase struct { ID string } type FakePod struct { FakeJSONBase `json:",inline" yaml:",inline"` Labels       map[string]string Int          int Str          string } </ins> func TestMakeJSONString(t *testing.T) { <del> pod := api.Pod{ JSONBase: api.JSONBase{ID: "foo"}, </del> <ins> pod := FakePod{ FakeJSONBase: FakeJSONBase{ID: "foo"}, </ins> Labels: map[string]string{ "foo": "bar", "baz": "blah", }, <ins> Int: -6, Str: "a string", </ins> } body := MakeJSONString(pod)

Discussion:
Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /sig cluster-lifecycle /cc /priority critical-urgent /milestone v1.19
it seems like the cluster being brought up does not have the API (new in 1.19 and newly tested in conformance) enabled
Digging into this further now
/assign
So... The issue boils down to the way we are pulling in the k8s artifacts and the conformance test binary for this test: The installed kubernetes version is pulled in through the version marker, which is currently referencing an older build (from July 1st before the eventsv1 commit was merged). The test binary is built from the current state of master While we could target a different version marker file to get the version, I believe this issue should be resolved without any further intervention with once it is finished and merged.
This should be fixed in
Opened accompanying PRs for other Cluster API variants: capz: capa:
Thanks
Change:
// ServeHTTP processes watch requests. func (h *WatchHandler) ServeHTTP(w http.ResponseWriter, req *http.Request) { ctx := api.NewContext() <ins> namespace := req.URL.Query().Get("namespace") if len(namespace) > 0 { ctx = api.WithNamespace(ctx, namespace) } </ins> parts := splitPath(req.URL.Path) if len(parts) < 1 || req.Method != "GET" { notFound(w, req)

Discussion:
is always using the cross namespace context. This needs to be fixed to support scoped watches.
Change:
} return subsets, readyEps, notReadyEps } <ins> func shouldPodBeInEndpoints(pod *v1.Pod) bool { switch pod.Spec.RestartPolicy { case v1.RestartPolicyNever: return pod.Status.Phase != v1.PodFailed && pod.Status.Phase != v1.PodSucceeded case v1.RestartPolicyOnFailure: return pod.Status.Phase != v1.PodSucceeded default: return true } } </ins>

Discussion:
If you create a job in which pods are crashing and a service spawning those pods, this may result in generating extremely huge Endpoints object (which will cause different performance issues). [Based on situation from one of our customers cluster]. After 30m from creating the objects below in my 3 node-cluster I have an endpoint which has almost 1MB of size: Example objects which are enough to cause this : :
- I think that we want to have "failed pods" that have "restart policy" "Always" to be part of "NotReadyAddresses". But do we want to keep pod that are in Failed state and have restart policy "Never"? I think it doesn't make sense. And this would be a quick and easy fix to this particular problem...
Can you update the issue title to "Failed pods with restart policy=Never should not be in the Endpoints.NotReadyAddresses"
done Do you agree that this is a reasonable request?
Geniunely interested: in what case do you want a service and a job? cc:
I can imagine a map-reduce-like thing that serves status from each worker, and uses a headless Service for discovery.
Yes - this is the example I've heard during discussions on last Kubecon.
Well - I don't know if it was map-reduce-like-thing, but it was about headless Service for discovery (and also reporting status from workers).
/assign
GitHub didn't allow me to assign the following users: xiangpengzhao. Note that only can be assigned. <detailsIn response to : /assign 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
We should also not put such pods in the Endpoints.NotReadyAddresses: Succeeded pods with restart policy=Never Succeeded pods with restart policy=OnFailure
- thanks for working on it. I commented on the PR.
Change:
return nil, fmt.Errorf("failed to create target pool %s: %v", loadBalancerName, err) } if len(hosts) <= maxTargetPoolCreateInstances { <del> glog.V(4).Infof("EnsureLoadBalancer(%v(%v)): created target pool", loadBalancerName, serviceName) </del> <ins> glog.Infof("EnsureLoadBalancer(%v(%v)): created target pool", loadBalancerName, serviceName) </ins> } else { <del> glog.V(4).Infof("EnsureLoadBalancer(%v(%v)): created initial target pool (now updating with %d hosts)", loadBalancerName, serviceName, len(hosts)-maxTargetPoolCreateInstances) </del> <ins> glog.Infof("EnsureLoadBalancer(%v(%v)): created initial target pool (now updating with %d hosts)", loadBalancerName, serviceName, len(hosts)-maxTargetPoolCreateInstances) </ins> created := sets.NewString() for _, host := range createInstances {

Discussion:
Restarting master causes a recreation of fwrule and target pool for type=loadbalancer services. We are saved in the non restart case because we compare a cached verson of the service to decided if we should even call into the cloudprovider and update resources. This is happening because our reconciliation routines are confused about session affintiy and lbip, leading them to recreate, since inplace update isn't allowed. The impact is at best a few seconds of radio silence, at worst who knows? Repro: Create a loadbalanced service, eg: Wait for it to acquire a vip. Try it out Ssh into master and restart kube-controller-manager: Watch the wgets, you'll notice radio silence after a bit. This is because the targetpool and forwarding rule get recreted, for 2 reasons: affinity mismatch So this check fails: Lbip mismatch: So this check fails: (lbip is retrieved here: )
the session affinity fix is trivial. The easiest change for the lb ip fix is to not actually check the ip, but simply backoff as long as the forwarding rule exists. This is "bad" because of the way we allocate a static-ip, assign it to the fwd rule, then de-allocate it. The alternative is to use to reconcile, but that's racy.
cherry pick
Change:
GetByKey(key string) (value interface{}, exists bool, err error) } <del> // DeltaType is the type of a change (addition, deletion, etc) type DeltaType string // Change type definition const ( Added   DeltaType = "Added" Updated DeltaType = "Updated" Deleted DeltaType = "Deleted" // Replaced is emitted when we encountered watch errors and had to do a // relist. We don't know if the replaced object has changed. // // NOTE: Previous versions of DeltaFIFO would use Sync for Replace events // as well. Hence, Replaced is only emitted when the option // EmitDeltaTypeReplaced is true. Replaced DeltaType = "Replaced" // Sync is for synthetic events during a periodic resync. Sync DeltaType = "Sync" ) // Delta is the type stored by a DeltaFIFO. It tells you what change // happened, and the object's state after* that change. // // [*] Unless the change is a deletion, and then you'll get the final //     state of the object before it was deleted. type Delta struct { Type   DeltaType Object interface{} } // Deltas is a list of one or more 'Delta's to an individual object. // The oldest delta is at index 0, the newest delta is the last one. type Deltas []Delta </del> // Oldest is a convenience function that returns the oldest delta, or // nil if there are no deltas. func (d Deltas) Oldest() *Delta {

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 reviewing for I noticed that introduced a second type of Delta that is specific to DeltaFIFO but did not update the relevant documentation at , which was introduced by concurrent PR . What you expected to happen: I expected the documentation on DeltaFIFO to be current. 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
BTW, I think it would be more reader-friendly if the definitions of Deltas and related types were closer to their mentions near the top of the file rather than near the end.
/help /triage accepted
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help /triage accepted </details
Hi, is someone working on this? If no, can I pick it up? Thanks.
: go ahead, and thanks!
Thanks! /assign