jiebi/CodeConvo huggingface dataset:
Change:
}, }, options: printers.GenerateOptions{Wide: true}, <del> // Columns: Name, Completions, Duration, Age, Containers, Images, Selectors </del> <ins> // Columns: Name, Status, Completions, Duration, Age, Containers, Images, Selectors </ins> expected: []metav1.TableRow{ { <del> Cells: []interface{}{"job1", "1/2", "", "0s", "fake-job-container1,fake-job-container2", "fake-job-image1,fake-job-image2", "job-label=job-label-value"}, </del> <ins> Cells: []interface{}{"job1", "Running", "1/2", "", "0s", "fake-job-container1,fake-job-container2", "fake-job-image1,fake-job-image2", "job-label=job-label-value"}, </ins> }, }, },

Discussion:
Suspend is a GA feature and it is big component of Kueue. It would be nice to display if jobs are suspended when doing . A new column that displays if the job is suspended would be helpful. Improve UX around suspend. Its a bit difficult to know why the job has not created pods unless you know about the suspend field.
/sig cli /wg batch /good-first-issue /help-wanted
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig cli /wg batch /good-first-issue /help-wanted 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
/cc Just something I noticed as I was testing some job in JobSet. It would be nice to see which jobs are suspended when doing . Hope its not a controversial change.
cc who worked on
Not controversial at all IMO /triage accepted
/assign
Any suggestions on where to place this column? I'm thinking between completions and durations. Or, should this be displayed only when the output is set to wide?
I would put it in the default view as well. Probably before completions
Addressed in the PR:
Change:
assert.Equal(t, secret1.Namespace, updatedSecret.Namespace) assert.True(t, secretsEqual(secret1, *updatedSecret), fmt.Sprintf("expected: %v, actual: %v", secret1, *updatedSecret)) <ins> // Wait for the secret to be updated in the informer store. err = WaitForSecretStoreUpdate( secretController.secretFederatedInformer.GetTargetStore(), cluster1.Name, types.NamespacedName{Namespace: secret1.Namespace, Name: secret1.Name}.String(), updatedSecret, wait.ForeverTestTimeout) assert.Nil(t, err, "secret should have been updated in the informer store") </ins> // Test update federated secret. secret1.Data = map[string][]byte{

Discussion:
https://k8s- Failed: TestSecretController {secret} Previous issues for this test:
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
This flake seems to have started after merged (just looking at the merge time line). Can you please take a look?
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
https://k8s- Failed: TestSecretController {secret}
Sorry just saw this, looking at it now
Sent for a fix
nice thanks
Change:
// Restore from the checkpoint path // NOTE: This MUST happen before creating the apiserver source // below, or the checkpoint would override the source of truth. <del> updatechannel := cfg.Channel(kubetypes.ApiserverSource) </del> <ins> var updatechannel chan<- interface{} </ins> if bootstrapCheckpointPath != "" { glog.Infof("Adding checkpoint path: %v", bootstrapCheckpointPath) <ins> updatechannel = cfg.Channel(kubetypes.ApiserverSource) </ins> err := cfg.Restore(bootstrapCheckpointPath, updatechannel) if err != nil { return nil, err

Discussion:
/kind bug cc. What happened: Since - specifically , kubelet always calls , leading it to always register an apiserver source with the . This leads to to never return true in cases where the kubelet is not configured to communicate with an apiserver. The direct result of this is that when removing a manifest from the directory, kubelet never kills the containers. What you expected to happen: The containers get killed properly. How to reproduce it (as minimally and precisely as possible): Configure kubelet standalone without an apiserver, and with a static pod manifest path. Add a manifest, then remove it. Observe the containers stick around. Set logging to greater than level 6, and see a lot of . Environment: Kubernetes version (use ): 1.9.2 (1.8.7 works)
- Is there a run a static manifest that's not a master test case in the node-e2e suite?
I don't think there are standalone kubelet tests since it's hard to observe the pod status.
Change:
func NewForConfig(c *rest.Config) (*Clientset, error) { configShallowCopy := *c <ins> if configShallowCopy.UserAgent == "" { configShallowCopy.UserAgent = rest.DefaultKubernetesUserAgent() } </ins> // share the transport between all clients httpClient, err := rest.HTTPClientFor(&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:
} } <del> func TestValidateToleratingBadLabels(t *testing.T) { invalidSelector := getValidLabelSelector() invalidSelector.MatchExpressions = []metav1.LabelSelectorRequirement{{Key: "key", Operator: metav1.LabelSelectorOpNotIn, Values: []string{"bad value"}}} validPodTemplateSpec := getValidPodTemplateSpecForSelector(getValidLabelSelector()) job := &batch.Job{ ObjectMeta: getValidObjectMeta(0), Spec: batch.JobSpec{ Selector:       invalidSelector, ManualSelector: pointer.BoolPtr(true), Template:       validPodTemplateSpec, }, } job.ResourceVersion = "1" oldObj := job.DeepCopy() newObj := job.DeepCopy() context := genericapirequest.NewContext() errorList := Strategy.ValidateUpdate(context, newObj, oldObj) if len(errorList) > 0 { t.Errorf("Unexpected error list with no-op update of bad object: %v", errorList) } } func TestJobStrategyValidateUpdate(t *testing.T) { </del> <ins> func TestJobStrategy_ValidateUpdate(t *testing.T) { </ins> ctx := genericapirequest.NewDefaultContext() validSelector := &metav1.LabelSelector{ MatchLabels: map[string]string{"a": "b"},

Discussion:
The gets very long testing mulitple functions in such as , and . These checks should be performed in dedicated Test functions using table for different scenarios. Target functions and are being as part of The remaining checks should be migrated to these functions. Also, a test function should be to migrate the remaining tests.
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 apps
/assign
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
Any progress on this? I'm working on and I noticed that has relatively low coverage so I was going to work on getting the coverage up.
I created that is somewhat related to this.
no progess. go ahead please
/assign
Change:
if err != nil || len(externalDNS) == 0 { //TODO: It would be nice to be able to determine the reason for the failure, // but the AWS client masks all failures with the same error description. <del> glog.V(2).Info("Could not determine public DNS from AWS metadata.") </del> <ins> glog.V(4).Info("Could not determine public DNS from AWS metadata.") </ins> } else { addresses = append(addresses, v1.NodeAddress{Type: v1.NodeExternalDNS, Address: externalDNS}) }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig aws What happened: Every few seconds I get spam in my logs about "Could not determine public DNS from AWS metadata" from every node. This is really very spammy. What you expected to happen: No spam. How to reproduce it (as minimally and precisely as possible): Launch a private topology cluster with kops. Anything else we need to know?: There will never be a public-hostname in the metadata for private topology clusters. This line: Should be glog.V(4) i suspect, like line 1033 above it. Environment: Kubernetes version (use ): 1.7.4 Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Jessie Kernel (e.g. ): 4.4.78-k8s Install tools: kops Others:
fixed in . PTAL. Thanks!
Thanks On a side note the metadata should probably be cached to stop thrashing the API but I don't know enough to be sure.
/cc
Change:
legacyregistry.MustRegister(RunningContainerCount) legacyregistry.MustRegister(RunningPodCount) legacyregistry.MustRegister(ManagedEphemeralContainers) <ins> if utilfeature.DefaultFeatureGate.Enabled(features.KubeletPodResources) { legacyregistry.MustRegister(PodResourcesEndpointRequestsTotalCount) if utilfeature.DefaultFeatureGate.Enabled(features.KubeletPodResourcesGetAllocatable) { legacyregistry.MustRegister(PodResourcesEndpointRequestsListCount) legacyregistry.MustRegister(PodResourcesEndpointRequestsGetAllocatableCount) legacyregistry.MustRegister(PodResourcesEndpointErrorsListCount) legacyregistry.MustRegister(PodResourcesEndpointErrorsGetAllocatableCount) } } </ins> legacyregistry.MustRegister(StartedPodsTotal) legacyregistry.MustRegister(StartedPodsErrorsTotal) legacyregistry.MustRegister(StartedContainersTotal)

Discussion:
In commit we podresources-related metrics, to make sure the feature was monitoring-friendly. Because of a implementation bug, the metrics have been , they are updated correctly, but they are never registered, so they don't show up when doing like the podresources related metrics should be reported in the endpoint in the kubelet the kubelet, even the simplistic environment of the tests is sufficient sure to enable the and feature gates (on by default in kube = 1.25 at least) the podresources endpoint issuing and calls. The actual output is not relevant the metrics: The bug was introduced in the original commit <details</details<detailsNot relevant. </details<detailsNot relevant </details<detailsNot relevant </details<detailsNot relevant </details<detailsNot relevant </details
/sig node /assign
/cc /triage-accepted
/triage accepted /cc
Change:
.nf File Path passed as a flag on the command line. This file is rechecked every 20 seconds (configurable with a flag). HTTP endpoint HTTP endpoint passed as a parameter on the command line. This endpoint is checked every 20 seconds (also configurable with a flag). <del> etcd server The Kubelet will reach out and do a watch on an etcd server. The etcd path that is watched is /registry/hosts/$(hostname -f). As this is a watch, changes are noticed and acted upon very quickly. </del> <ins> etcd server The Kubelet will reach out and do a watch on an etcd server. The etcd path that is watched is /registry/hosts/$(uname -n). As this is a watch, changes are noticed and acted upon very quickly. </ins> HTTP server The kubelet can also listen for HTTP and respond to a simple API (underspec'd currently) to submit a new manifest. .fi

Discussion:
Actually appending fqdn suffix already causes issue for non-resolvable node names based on today: Today when NodeController "registers" nodes in SyncCloud by getting bare instance names () from GCE, and recreating the fqdn and append it to instance names().
Change:
container_memory_working_set_bytes{container="container_a",namespace="namespace_b",pod="pod_b"} 1000 1624396278302 # HELP container_start_time_seconds [STABLE] Start time of the container since unix epoch in seconds # TYPE container_start_time_seconds gauge <del> container_start_time_seconds{container="container_a",namespace="namespace_a",pod="pod_a"} 1.6243962483020916e+09 1624396248302 container_start_time_seconds{container="container_a",namespace="namespace_b",pod="pod_b"} 1.6243956783020916e+09 1624395678302 </del> <ins> container_start_time_seconds{container="container_a",namespace="namespace_a",pod="pod_a"} 1.6243962483020916e+09 container_start_time_seconds{container="container_a",namespace="namespace_b",pod="pod_b"} 1.6243956783020916e+09 </ins> # HELP scrape_error [ALPHA] 1 if there was an error while getting container metrics, 0 otherwise # TYPE scrape_error gauge scrape_error 0

Discussion:
When scrape kubelet resource metrics provided by /metrics/resource, got response like this The metric containerstarttimeseconds's timestamp should not equals to container start time As above No response v1.24.7 Volc Engine No response No response No response No response_
I would like to take this up, after triage/accepted I just wanted to know then what time should be needed to be set there? /assign
the metric should not have a timestamp
If not timestamp, then what value and data type should I assign for the containerstarttime_seconds metric?
check
no need to change the value and data type, just remove the timestamp for the metric datapoint
Sure got it, raising a PR for the same!
If you have already done it, then why the PR is blocked and why I am redoing it again? Just curious to know!
Why do you think it's blocked and why are you redoing it before figuring this out?
/sig node
/triage accepted /priority important-longterm
/assign (since you sent a PR)
Change:
--name "${KUBE_DATA_CONTAINER_NAME}" --hostname "${HOSTNAME}" "${KUBE_BUILD_IMAGE}" <del> chown -R $(id -u).$(id -g) </del> <ins> chown -R ${USER_ID}.${GROUP_ID} </ins> "${REMOTE_ROOT}" /usr/local/go/pkg/ )

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one):BUG REPORT Kubernetes version (use ):Client Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.2850+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-01-06T09:06:04Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.2753+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-01-04T08:46:56Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} What happened: How to reproduce it (as minimally and precisely as possible): the owner of file is not right
Do you need to be building as root?
I get an annoying message when building as normal user: So I run as root. There will return a error if the outpt build directory is not owned by root when running as root. I think we could use to fix it.
I hope to get some of your suggestions
did you previously build as ? you might need to before a build as a normal user works again.
Change:
"k8s.io/kubernetes/pkg/api" "k8s.io/kubernetes/pkg/api/latest" "k8s.io/kubernetes/pkg/runtime" <ins> // This installs the legacy v1 API _ "k8s.io/kubernetes/pkg/api/install" </ins> ) // TODO:

Discussion:
I follow to create a nginx example. And I got stuck at the beginning.
I'll send a fix which will supersede .
that would be great! thanks, I just got lost handling other 1.1 stuff and forgot about that pr
Sent , PTAL. Thank you.
Change:
"x-kubernetes-patch-strategy": "merge" }, "generateName": { <del> "description": "GenerateName is an optional prefix, used by the server, to generate a unique name ONLY IF the Name field has not been provided. If this field is used, the name returned to the client will be different than the name passed. This value will also be combined with a unique suffix. The provided value has the same validation rules as the Name field, and may be truncated by the length of the suffix required to make the value unique on the server.nnIf this field is specified and the generated name exists, the server will NOT return a 409 - instead, it will either return 201 Created or 500 with Reason ServerTimeout indicating a unique name could not be found in the time allotted, and the client should retry (optionally after the time indicated in the Retry-After header).nnApplied only if Name is not specified. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#idempotency", </del> <ins> "description": "GenerateName is an optional prefix, used by the server, to generate a unique name ONLY IF the Name field has not been provided. If this field is used, the name returned to the client will be different than the name passed. This value will also be combined with a unique suffix. The provided value has the same validation rules as the Name field, and may be truncated by the length of the suffix required to make the value unique on the server.nnIf this field is specified and the generated name exists, the server will return a 409.nnApplied only if Name is not specified. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#idempotency", </ins> "type": "string" }, "generation": {

Discussion:
The error code of is 409. Is this an expected behavior? The doc seems to say no: NOT return a 409 - instead, it will either return 201 Created or 500 with Reason ServerTimeout indicating a unique name could not be found in the time allotted, and the client should retry (optionally after the time indicated in the Retry-After header). seems to create which error code is 409. The error code of isn't 409. Or, the doc doesn't say "If this field is specified and the generated name exists, the server will NOT return a 409". Create a large number of Pods with generateName, and cause name conflicts. Just question: if the API is correct in returning 409 for a GenerateName-conflict, how do we determine that error? We want to retry when GenerateName conflict returns in most cases because the retry may solve this conflict. latest master (maybe after ) <details</details<details</details<details</details<details</details<details</details
Sorry if not an appropriate SIG. /sig api-machinery
/assign
It seems related to . If it's expected behavior, the document isn't correct..?
is a mistake. /unassign
Hi do you think this is a good first issue to tackle? If so, I would like to try contributing here.
/assign /triage accepted
Forgive me to ping other people who might know. /cc /cc /cc
I suspect we just failed to update the documentation.
Thanks Okay. I'll create the PR for that. /kind documentation /assign
Change:
close(pk.podKillingCh) } <del> // KillPod sends pod killing request to the killer func (pk *podKillerWithChannel) KillPod(pair *kubecontainer.PodPair) { pk.podKillingCh <- pair } </del> // PerformPodKillingWork launches a goroutine to kill a pod received from the channel if // another goroutine isn't already in action. func (pk *podKillerWithChannel) PerformPodKillingWork() { for podPair := range pk.podKillingCh { <del> if pk.checkAndMarkPodPendingTerminationByPod(podPair) { // Pod is already being killed continue } </del> runningPod := podPair.RunningPod apiPod := podPair.APIPod

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: Right after calling , returns false even the pod is not killed yet. What you expected to happen: In kubelet, after is complete, the pod should be pending termination or be killed. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Related to 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:
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 /assign
Change:
"k8s.io/mount-utils" utilpath "k8s.io/utils/path" <del> libcontaineruserns "github.com/opencontainers/runc/libcontainer/userns" </del> v1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/api/resource" "k8s.io/apimachinery/pkg/types"

Discussion:
is no longer compilable on macOS in the master branch. It was compilable with Kubernetes v1.29.0 and v1.30.0-alpha.0. It should be compilable. No response <detailsmaster () (This is just the latest commit, not the commit that introduced the regression) </details<detailsN/A </details<detailsmacOS 14.2.1 (Intel) </details<detailsN/A </details<detailsN/A </details<detailsN/A </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 testing
Regression in: