jiebi/CodeConvo huggingface dataset:
Change:
}, gvk: example2v1.SchemeGroupVersion.WithKind("ReplicaSet"), expectedObj: &example2v1.ReplicaSet{ <ins> TypeMeta: metav1.TypeMeta{ APIVersion: "example2.apiserver.k8s.io/v1", Kind:       "ReplicaSet", }, </ins> ObjectMeta: metav1.ObjectMeta{ Name: "rs1", Labels: map[string]string{

Discussion:
The admission webhook review requests seem not to include a GVK in the raw object. It's included elsewhere in the review request, so it's generally not an issue, except that the unstructured codec requires GVKs to be present (it's not a technical requirement AFAICT, just a check done in the codec logic). This means that trying to use or on an Unstructured fails. A workaround in the mean time is to use , but it would be nice if this just worked properly (fixes to the review request logic and the unstructured codec logic. <details</summary</details<details</summary</detailsserving CA and certs (at and ) webhook with CA bundle `kubectl create -f that the output object doesn't have GVK in the field Environment: Kubernetes version (use ): master-ish () /sig api-machinery
when encoded to the wire, apiVersion and kind must always be included. do you have a gist handy of what the webhook receives for a built-in type (like a pod) and a for a custom resource?
Looks like custom objects (held in unstructured objects) would include GVK, but in-tree types would not. It might be as simple as explicitly setting the GVK in ConvertToGVK: and we need to update the webhook test to ensure objects in requests always have an apiVersion/kind
fixed in
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
Change:
existingPods                  []*v1.Pod pod                           *v1.Pod initTokens                    int <ins> enablePreFilter               bool </ins> unresolvable                  bool preemptedPodIndexes           map[int]struct{} enablePodDisruptionConditions bool

Discussion:
In k8s 1.27, scheduler introduced a new "short circuit" semantics in PreFilter to bypass a Pod quickly. A change introduced here is it relies on that plugin to be stored in , which makes sense as what it was explained . However, the info, although is populated upon each plugin's PreFilter invocation, is not injected into when some PreFilter returns unschedulable: So think about this workflow: pluginA returns Skip in its PreFilter pluginB return Unschedulable in its PreFilter note: pluginA is not included in due to aforementioned bug a Pod is claimed as unschedulable (failed by pluginB) during PostFilter, it's supposed to bypass pluginA's PreEnqueueExtension's AddPod/RemovePod, but it doesn't calling a "skipped" Plugin's AddPod/RemovePod during preemption, sometimes will abort the whole preemption as the logic tries to read info from cycleState, and some plugin's "skip" version doesn't fill cycleState properly, e.g., InterPodAffinity (skip immediately w/o write preFilterStateKey). Short circuiting using Skip is fine, but should injected properly at all cases. Described in the workflow above. It's firstly captured in an out-of-tree PostFilter plugin: , but can also happen in in-tree plugins. No response v1.27 <details</details<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
/kind regression /sig scheduling
cc
Among in-tree plugins, 3 plugins employ non-nil and may return Skip in their PreFilter() implementation w/o writing to cycleState, while return error immediately if is missing in their Add/RemovePod() functions.

So technically, as long as a scheduling flow hit the following criteria, it would hit the bug (preemption doesn't function): plugin 1/2/3 return Skip in PreFilter arbitrary PreFilter plugin after the "skipped" plugin returns Unschedulable in its PreFilter
/cc
/cc
Cherry-pick PRs: 1.28: 1.27:
Change:
// ControlPlaneComponent holds settings common to control plane component of the cluster type ControlPlaneComponent struct { // ExtraArgs is an extra set of flags to pass to the control plane component. <ins> // A key in this map is the flag name as it appears on the // command line except without leading dash(es). </ins> // TODO: This is temporary and ideally we would like to switch all components to // use ComponentConfig + ConfigMaps. // +optional

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 --I was reading the doc about NodeRegistration, with an interest in specifying some . I noticed that the doc (e.g., ) does not tell me exactly how to identify each arg: exactly as on the command line (including leading dash(es)), as on the command line but without leading dash(es), or camelCase. I expected the doc to enable me to write some with confidence. 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:
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 cluster-lifecycle
FWIW the answer is flag names as on the command name but without any leading dashes. This also applies to controllerManager.extraArgs, scheduler.extraArgs, etc. which hopefully should all cover this similarly (if not now, after fixing ...)

<!-- 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 --I was reading about how to use kubeadm and noticed a typo in the API documentation. speaks of the "node subnet" where I think "pod subnet" is intended. 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:
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 cluster-lifecycle
/area kubeadm
Change:
devicePluginUpdateTimeout := 1 * time.Minute ginkgo.It("will report a Healthy and then Unhealthy single device in the pod status", func(ctx context.Context) { <ins> e2eskipper.SkipUnlessFeatureGateEnabled(features.ResourceHealthStatus) </ins> // randomizing so tests can run in parallel resourceName := fmt.Sprintf("test.device/%s", f.UniqueName) devices := []kubeletdevicepluginv1beta1.Device{{ID: "testdevice", Health: kubeletdevicepluginv1beta1.Healthy}}

Discussion:
In multi test grid: /kind failing-test /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
/cc
/cc This is caused by that those test CI didn't enable ResourceHealthStatus. A fix in is to skip it if the FG is disabled.
Change:
expectedEvictPods:   false, description:         "Node created recently, with no status.", }, <ins> // Node created recently without FailureDomain labels which is added back later, with no status (happens only at cluster startup). { fakeNodeHandler: &testutil.FakeNodeHandler{ Existing: []*v1.Node{ { ObjectMeta: metav1.ObjectMeta{ Name:              "node0", CreationTimestamp: fakeNow, }, }, { ObjectMeta: metav1.ObjectMeta{ Name:              "node1", CreationTimestamp: metav1.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), }, Status: v1.NodeStatus{ Conditions: []v1.NodeCondition{ { Type:               v1.NodeReady, Status:             v1.ConditionTrue, LastHeartbeatTime:  metav1.Date(2015, 1, 1, 12, 0, 0, 0, time.UTC), LastTransitionTime: metav1.Date(2015, 1, 1, 12, 0, 0, 0, time.UTC), }, }, }, }, }, Clientset: fake.NewSimpleClientset(&v1.PodList{Items: []v1.Pod{*testutil.NewPod("pod0", "node0")}}), }, daemonSets:          nil, timeToPass:          0, newNodeStatus:       v1.NodeStatus{}, secondNodeNewStatus: healthyNodeNewStatus, expectedEvictPods:   false, description:         "Node created recently without FailureDomain labels which is added back later, with no status (happens only at cluster startup).", }, </ins> // Node created long time ago, and kubelet posted NotReady for a short period of time. { fakeNodeHandler: &testutil.FakeNodeHandler{

Discussion:
<!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.0-alpha.1.51+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-06-20T10:51:10Z", GoVersion:"go1.8", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.0-alpha.1.51+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-06-20T11:29:14Z", GoVersion:"go1.8", Compiler:"gc", Platform:"linux/amd64"} What happened: After adding label to a node, node controller panics. What you expected to happen: Everything should still work. How to reproduce it (as minimally and precisely as possible): Run and wait for the node controller to panic: Anything else we need to know: I've checked the code and it looks like the node controller expects the label to be present during node registration and it can not be later. Even if the label can not be latter it shouldn't panic.
/sig node
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
/assign let me try this :).
Change:
disks := []compute.DataDisk{} if vm.StorageProfile != nil && vm.StorageProfile.DataDisks != nil { <del> disks = *vm.StorageProfile.DataDisks </del> <ins> disks = make([]compute.DataDisk, len(*vm.StorageProfile.DataDisks)) copy(disks, *vm.StorageProfile.DataDisks) </ins> } if isManagedDisk { disks = append(disks,

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: In Azure disk attach/detach function, it uses slice() to store the disk list: And after changed, the original would also be changed, so original azure data disk list is corrupted after attach/detach disk example code as below: 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig azure /assign
Change:
func NewForConfig(c *$.Config|raw$) (*Clientset, error) { configShallowCopy := *c <ins> if configShallowCopy.UserAgent == "" { configShallowCopy.UserAgent = $.DefaultKubernetesUserAgent|raw$() } </ins> // share the transport between all clients httpClient, err := $.RESTHTTPClientFor|raw$(&configShallowCopy) if err != nil {

Discussion:
It looks like kubelet started using generic user agent like "Go-http-client/2.0" and makes it harder to attribute the request to kubelet. In the past we have used "kubelet" user-agent which was providing some value. Sample logs: Kubelet's requests are using customised user-agent Run kubelet Check kube-apiserver's logs: No response master tested on gce <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 node
The default user agent name is generated like below. I am using v1.23.4 and the user agent can show kubelet as the user agent.(not on gce)
/cc We should identify those and set the user-agent correctly , is right, it is very useful field ... but I see ~kubectl~ kubelet user-agents in the log linked
Interesting... in I see both kubelet user agent and "Go-http-client/2.0": Moreover, it looks like "kubelet" user agent is used only for events-related calls and other (like leases) are using "Go-http-client/2.0".
interesting , the user agent is to the request by wrapping the roundtripper, that is when the client is generated the clientset creation is here Speculating, I'm wondering if the updateTransport is mutating the transport and not adding the corresponding wrapper in ?
/assign I think that this was my fault, let me check it in more detail
I think that this was the problem
Change:
} // update our local observations based on the amount reported to have been reclaimed. // note: this is optimistic, other things could have been still consuming the pressured resource in the interim. <del> signal := resourceToSignal[resourceToReclaim] value, ok := observations[signal] if !ok { glog.Errorf("eviction manager: unable to find value associated with signal %v", signal) continue </del> <ins> for _, signal := range resourceClaimToSignal[resourceToReclaim] { value, ok := observations[signal] if !ok { glog.Errorf("eviction manager: unable to find value associated with signal %v", signal) continue } value.available.Add(*reclaimed) </ins> } <del> value.available.Add(*reclaimed) </del> // evaluate all current thresholds to see if with adjusted observations, we think we have met min reclaim goals if len(thresholdsMet(m.thresholdsMet, observations, true)) == 0 { return true

Discussion:
It is possible to have multiple signals that point to the same type of resource, e.g., both SignalNodeFsAvailable and SignalAllocatableNodeFsAvailable refer to the same resource NodeFs. Change the map from map[v1.ResourceName]evictionapi.Signal to map[v1.ResourceName][]evictionapi.Signal
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/kind cleanup /priority important/soon taking a guess at labels to satisfy the milestone munger
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node sig/storage: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/cleanup: Adding tests, refactoring, fixing old bugs. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
Looks like the PR for this is just awaiting merge
Change:
Suffix("containerLogs", ns, podStatus.Name, containerName). Do(). Raw() <del> fmt.Sprintf("pod logs:%vn", string(logs)) By(fmt.Sprintf("pod logs:%vn", string(logs))) if strings.Contains(string(logs), "Internal Error") { By(fmt.Sprintf("Failed to get logs from node %q pod %q container %q: %v", podStatus.Spec.NodeName, podStatus.Name, containerName, string(logs))) </del> <ins> if err == nil && strings.Contains(string(logs), "Internal Error") { err = fmt.Errorf("Fetched log contains "Internal Error": %q.", string(logs)) } if err != nil { By(fmt.Sprintf("Warning: Failed to get logs from node %q pod %q container %q. %v", podStatus.Spec.NodeName, podStatus.Name, containerName, err)) </ins> time.Sleep(5 * time.Second) continue } <ins> By(fmt.Sprintf("Succesfully fetched pod logs:%vn", string(logs))) </ins> break }

Discussion:
This happened on 5/6/2015 at 07:49 am on our continuous integration system, against upstream/master head at that time (i.e. last commit ). Needs to be repro'd and debugged. Docker Containers should be able to override the image's default command and arguments Failed to create pod: Pod "client-containers--f401-11e4-9118-" is forbidden: Post http://127.0.0.1:8080/api/v1beta3/namespaces: EOF
This test is still flaky. Containers should be able to override the image's default commmand (docker entrypoint) (Failed 2 times in the last 30 runs. Stability: 93 % Containers should be able to override the image's default arguments (docker cmd) (Failed 1 times in the last 30 runs. Stability: 96 %)
I will take a look at this now
Sample log from failure:
The indicates two things 1) that the test only tried once to fetch the logs, and 2) that either the call returned an empty log or an error (which it looks like the test does not check for). See
Change:
EnableLogsSupport:      true, MasterServiceNamespace: api.NamespaceDefault, ClusterName:            "kubernetes", <ins> SyncPodStatus:          true, </ins> RuntimeConfig: make(util.ConfigurationMap), KubeletConfig: client.KubeletConfig{

Discussion:
Split off as a smaller more specific work item. Apiserver should have a flag that makes it not attempt to GET from kubelets. This would be used in conjunction with . After we have converted the top N Getting-started-guides to the new style, we can rip out the kubelet client from the apiserver altogether.
This is tightly related to so I'll take it.
Change:
"time" v1 "k8s.io/api/core/v1" <ins> "k8s.io/apimachinery/pkg/util/sets" utilfeature "k8s.io/apiserver/pkg/util/feature" </ins> "k8s.io/client-go/tools/cache" "k8s.io/klog/v2" apipod "k8s.io/kubernetes/pkg/api/v1/pod" <ins> "k8s.io/kubernetes/pkg/features" </ins> "k8s.io/utils/clock" "k8s.io/utils/ptr" )

Discussion:
Today the function () only account for the regular containers finish time, presumably assuming that init containers have completed before before. However, with the sidecar (restartable init) containers, sidecar containers will always finish later than regular containers. And those needs to be accounted for the calculation. /kind bug The sidecar finish time will be accounted when calculating the job's finish time. Sidecar container with prolonged termination logic on a job will result in incorrect finish time reporting. /sig apps /priority backlog KEP:
/assign
/triage accepted
Change:
manifest_image_folder=`echo "$${registry_prefix}${IMAGE}" | sed "s|/|_|g" | sed "s/:/-/"`;  for arch in $(ALL_ARCH.windows);  do  for osversion in ${ALL_OSVERSIONS.windows}; do  <del> docker manifest annotate --os windows --arch $${arch} ${IMAGE}:${TAG} ${IMAGE}-windows-$${arch}-$${osversion}:${TAG};  </del> <ins> docker manifest annotate --os windows --arch $${arch} ${IMAGE}:${TAG} ${IMAGE}:${TAG}-windows-$${arch}-$${osversion};  </ins> BASEIMAGE=${BASE.windows}:$${osversion};  full_version=`docker manifest inspect ${BASE.windows}:$${osversion} | grep "os.version" | head -n 1 | awk '{print $$2}'` || true;  <del> sed -i -r "s/("os":"windows")/0,"os.version":$${full_version}/" "${HOME}/.docker/manifests/$${manifest_image_folder}-${TAG}/$${manifest_image_folder}-windows-$${arch}-$${osversion}-${TAG}";  </del> <ins> sed -i -r "s/("os":"windows")/0,"os.version":$${full_version}/" "${HOME}/.docker/manifests/$${manifest_image_folder}-${TAG}/$${manifest_image_folder}-${TAG}-windows-$${arch}-$${osversion}";  </ins> done;  done docker manifest push --purge ${IMAGE}:${TAG}

Discussion:
We could either: where appropriate - least amount of code change but cumbersome OS version in the tag instead of the repository /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
/sig windows
/kind bug
Change:
github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc h1:U9qPSI2PIWSS1VwoXQT9A3Wy9MM3WgvqSxFWenqJduM= github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= <del> github.com/emicklei/go-restful/v3 v3.8.0/go.mod h1:6n3XBCmQQb25CM2LCACGz8ukIrRry+4bhvbpWn3mrbc= </del> <ins> github.com/emicklei/go-restful/v3 v3.11.0 h1:rAQeMHw1c7zTmncogyy8VvRZwtkmkZ4FxERmMY4rD+g= github.com/emicklei/go-restful/v3 v3.11.0/go.mod h1:6n3XBCmQQb25CM2LCACGz8ukIrRry+4bhvbpWn3mrbc= </ins> github.com/fxamacker/cbor/v2 v2.7.0-beta h1:m5bO941uTVpSms26QjzEJxUZaC3S/h1pSJexBCu4wAA= github.com/fxamacker/cbor/v2 v2.7.0-beta/go.mod h1:pxXPTn3joSm21Gbwsv0w9OSA2y1HFR9qXEeXQVeNoDQ= github.com/go-logr/logr v1.4.1 h1:pKouT5E8xu9zeFC39JXRDukb6JFQPXM5p5I91188VAQ=

Discussion:
We're trying to upgrade to () and found the issue on executing (). The problem is that on () missed dependency that not allow to install () No error To reproduce the same what happening on , just execute this command on code-generator folder: I think it's happens after this commit <details</details<details</details<details</details<details</details<details</details<details</details
/cc
/assign
/sig api-machinery
I was able to reproduce, but just because I had an older version of kube-openapi in my GOPATH. Using the prefix in the command fixed it. I think line needs to be
Yeah, with works for me too.
Either that or we pin to a more recent commit, for example . For some reason if you ommit the version it is using a from Feb 27.
thanks for investigating. Question, if we use would this not cause problems in the future if we try to build a release branch from the past? Maybe this is not a big deal. OTOH if we hardcode a tag, it may create maintenance costs. I'm wondering if there is a better way, say to version and use the corresponding tag, say ?
Using tags would be a way to have more reproducible builds, they still need to be tagged from time to time tho. That is still better than using or micro managing commit revisions.
Thanks and for the research. Is either of you thinking on submitting a fix for this? Thanks!
I can do it.
Thanks! /assign mbobrovskyi
Yes, please don't use Generally instead we'd control the version of a tool in the hack/tools module and install it from there (see e.g.
This allows us to also gain for the package while not polluting the main module with dev-only dependencies.
Not sure if we need to make another Because it's not just a dev-only dependency. I propose to add it to of code-generator.
This is about semversioning
/triage accepted