jiebi/CodeConvo huggingface dataset:
Change:
Currently the local-up- script does not have support for the flag. This flag was recently here as a part of For development, testing, and full plumbing through of the feature the flag should be to local-up- to allow for usage of the feature when setting up a cluster via local-up-
/sig apimachinery
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig apimachinery 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
/sig api-machinery
/sig testing /triage accepted /assign

Discussion:
CLOUD_CONFIG=${CLOUD_CONFIG:-""} KUBELET_PROVIDER_ID=${KUBELET_PROVIDER_ID:-"$(hostname)"} FEATURE_GATES=${FEATURE_GATES:-"AllAlpha=false"} <ins> EMULATED_VERSION=${EMULATED_VERSION:+kube=$EMULATED_VERSION} </ins> CPUMANAGER_POLICY=${CPUMANAGER_POLICY:-""} CPUMANAGER_RECONCILE_PERIOD=${CPUMANAGER_RECONCILE_PERIOD:-""} CPUMANAGER_POLICY_OPTIONS=${CPUMANAGER_POLICY_OPTIONS:-""}

--etcd-servers="http://${ETCD_HOST}:${ETCD_PORT}"  --service-cluster-ip-range="${SERVICE_CLUSTER_IP_RANGE}"  --feature-gates="${FEATURE_GATES}"  <ins> --emulated-version="${EMULATED_VERSION}"  </ins> --external-hostname="${EXTERNAL_HOSTNAME}"  --requestheader-username-headers=X-Remote-User  --requestheader-group-headers=X-Remote-Group 

--enable-hostpath-provisioner="${ENABLE_HOSTPATH_PROVISIONER}"  --pvclaimbinder-sync-period="${CLAIM_BINDER_SYNC_PERIOD}"  --feature-gates="${FEATURE_GATES}"  <ins> --emulated-version="${EMULATED_VERSION}"  </ins> "${cloud_config_arg[@]}"  --authentication-kubeconfig "${CERT_DIR}"/controller.kubeconfig  --authorization-kubeconfig "${CERT_DIR}"/controller.kubeconfig 

--v="${LOG_LEVEL}"  --config="${TMP_DIR}"/kube-scheduler.yaml  --feature-gates="${FEATURE_GATES}"  <ins> --emulated-version="${EMULATED_VERSION}"  </ins> --authentication-kubeconfig "${CERT_DIR}"/scheduler.kubeconfig  --authorization-kubeconfig "${CERT_DIR}"/scheduler.kubeconfig  --master="https://${API_HOST}:${API_SECURE_PORT}" >"${SCHEDULER_LOG}" 2>&1 &
Change:
[x] two weeks soak end date : 2024-09-08 According to following APIsnoop query, there are two Node endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 2 endpoints. The e2e logs for this test are listed below. This query shows the following Node endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 2 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/sig node
/reopen Tracking the next steps to conformance
Reopened this issue. <detailsIn response to : /reopen Tracking the next steps to conformance Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen Tracking the final step
Reopened this issue. <detailsIn response to : /reopen Tracking the final step 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

Discussion:
be evicted if the taint is removed before toleration time ends. release: v1.16 file: test/e2e/node/taints.go <ins> - testname: Node, resource lifecycle codename: '[sig-node] Node Lifecycle should run through the lifecycle of a node [Conformance]' description: Creating and Reading a Node MUST succeed with required name retrieved. Patching a Node MUST succeed with its new label found. Listing Nodes with a labelSelector MUST succeed with only a single node found. Updating a Node MUST succeed with its new label found. Deleting the Node MUST succeed and its deletion MUST be confirmed. release: v1.32 file: test/e2e/node/node_lifecycle.go </ins> - testname: PodTemplate, delete a collection codename: '[sig-node] PodTemplates should delete a collection of pod templates [Conformance]' description: A set of Pod Templates is created with a label selector which MUST

f := framework.NewDefaultFramework("fake-node") f.NamespacePodSecurityLevel = admissionapi.LevelPrivileged <del> ginkgo.It("should run through the lifecycle of a node", func(ctx context.Context) { </del> <ins> /* Release: v1.32 Testname: Node, resource lifecycle Description: Creating and Reading a Node MUST succeed with required name retrieved. Patching a Node MUST succeed with its new label found. Listing Nodes with a labelSelector MUST succeed with only a single node found. Updating a Node MUST succeed with its new label found. Deleting the Node MUST succeed and its deletion MUST be confirmed. */ framework.ConformanceIt("should run through the lifecycle of a node", func(ctx context.Context) { </ins> // the scope of this test only covers the api-server nodeClient := f.ClientSet.CoreV1().Nodes()
Change:
[x] two weeks soak end date : 2024-09-08 According to following APIsnoop query, there are two Node endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 2 endpoints. The e2e logs for this test are listed below. This query shows the following Node endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 2 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/sig node
/reopen Tracking the next steps to conformance
Reopened this issue. <detailsIn response to : /reopen Tracking the next steps to conformance Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen Tracking the final step
Reopened this issue. <detailsIn response to : /reopen Tracking the final step 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

Discussion:
--- - createCoreV1NamespacedServiceAccountToken <del> - createCoreV1Node </del> - createStorageV1CSINode <del> - deleteCoreV1Node </del> - deleteStorageV1CollectionCSINode - deleteStorageV1CSINode - listStorageV1CSINode
Change:
This issue is about the function in . In this function, 's is evaluated in this line: and if is not , 's is set to : But remains empty string. should be set to . No response I imported public library <details</summary</details<details</details<details</details<details</details<details</details<details</details
/assign
/sig api-machinery
I am new to contributing to this repo can you please tell me what all things I should be familiar with to start contributing in kubernetes specifically this issue.
/cc /triage accepted

Discussion:
decision.Message = fmt.Sprintf("failed messageExpression: %s", err) } else if evalResult.EvalResult != celtypes.True { decision.Action = ActionDeny <ins> decision.Evaluation = EvalDeny </ins> if validation.Reason == nil { decision.Reason = metav1.StatusReasonInvalid } else {
Change:
TypedNewDelayingQueue in does not follow the naming convention in the same package. The naming pattern observed in suggests that TypedNewDelayingQueue should be renamed to NewTypedDelayingQueue. Because we have NewTypedDelayingQueueWithConfig, and other functions are named in such rules, I think this is an obvious conversion tooling error and/or cut and paste error. There is no reproduction steps. No response <detailskubernetes v1.31.0 </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
Added in /cc
/cc /triage accepted
I can change this but then that of course breaks everyone who uses the current name. Is that something we want to do?
Adding NewTypedDelayingQueue and deprecating TypedNewDelayingQueue keep backward compatibility if that is a way to go.

Discussion:
// NewDelayingQueue does not emit metrics. For use with a MetricsProvider, please use // NewDelayingQueueWithConfig instead and specify a name. // <del> // Deprecated: use TypedNewDelayingQueue instead. </del> <ins> // Deprecated: use NewTypedDelayingQueue instead. </ins> func NewDelayingQueue() DelayingInterface { return NewDelayingQueueWithConfig(DelayingQueueConfig{}) } <del> // TypedNewDelayingQueue constructs a new workqueue with delayed queuing ability. // TypedNewDelayingQueue does not emit metrics. For use with a MetricsProvider, please use // TypedNewDelayingQueueWithConfig instead and specify a name. func TypedNewDelayingQueue[T comparable]() TypedDelayingInterface[T] { </del> <ins> // NewTypedDelayingQueue constructs a new workqueue with delayed queuing ability. // NewTypedDelayingQueue does not emit metrics. For use with a MetricsProvider, please use // NewTypedDelayingQueueWithConfig instead and specify a name. func NewTypedDelayingQueue[T comparable]() TypedDelayingInterface[T] { </ins> return NewTypedDelayingQueueWithConfig(TypedDelayingQueueConfig[T]{}) } // NewDelayingQueueWithConfig constructs a new workqueue with options to // customize different properties. // <del> // Deprecated: use TypedNewDelayingQueueWithConfig instead. </del> <ins> // Deprecated: use NewTypedDelayingQueueWithConfig instead. </ins> func NewDelayingQueueWithConfig(config DelayingQueueConfig) DelayingInterface { return NewTypedDelayingQueueWithConfig[any](config) } <ins> // TypedNewDelayingQueue exists for backwards compatibility only. // // Deprecated: use NewTypedDelayingQueueWithConfig instead. func TypedNewDelayingQueue[T comparable](config TypedDelayingQueueConfig[T]) TypedDelayingInterface[T] { return NewTypedDelayingQueueWithConfig(config) } </ins> // NewTypedDelayingQueueWithConfig constructs a new workqueue with options to // customize different properties. func NewTypedDelayingQueueWithConfig[T comparable](config TypedDelayingQueueConfig[T]) TypedDelayingInterface[T] {
Change:
ci-crio-cgroupv1-node-e2e-flaky [It] [sig-node] Device Plugin [NodeFeature:DevicePlugin] [Serial] DevicePlugin [Serial] [Disruptive] Keeps device plugin assignments across node reboots (no pod restart, no device plugin re-registration) [Flaky] Since Under evaluation. cc /sig node
/triage accepted /priority important-soon
Tests are green again:

Discussion:
ginkgo.BeforeEach(func(ctx context.Context) { ginkgo.By("Wait for node to be ready") <del> gomega.Eventually(ctx, func(ctx context.Context) error { _, err := e2enode.TotalReady(ctx, f.ClientSet) if err != nil { return err } return nil }, time.Minute, time.Second).Should(gomega.Equal(1), "one node should be ready") </del> <ins> gomega.Eventually(ctx, e2enode.TotalReady). WithArguments(f.ClientSet). WithTimeout(time.Minute). Should(gomega.BeEquivalentTo(1)) </ins> // Before we run the device plugin test, we need to ensure // that the cluster is in a clean state and there are no
Change:
When OwnerReferencesPermissionEnforcement admission plugin is used the PVCs are not deleted and KCM logs show PVCs should have ownerReferences set and the PVCs should be garbage collected on scale down 3 of 6 of the following tests fail when OwnerReferencesPermissionEnforcement admission plugin is turned on No response <details</details<detailsNA </details<details</details<details</details<details</details<details</details
/sig apps /triage accepted

Discussion:
rbacv1helpers.NewRule("update").Groups(appsGroup).Resources("statefulsets/finalizers").RuleOrDie(), rbacv1helpers.NewRule("get", "create", "delete", "update", "patch").Groups(legacyGroup).Resources("pods").RuleOrDie(), rbacv1helpers.NewRule("get", "create", "delete", "update", "patch", "list", "watch").Groups(appsGroup).Resources("controllerrevisions").RuleOrDie(), <del> rbacv1helpers.NewRule("get", "create").Groups(legacyGroup).Resources("persistentvolumeclaims").RuleOrDie(), </del> <ins> rbacv1helpers.NewRule("get", "create", "list", "watch").Groups(legacyGroup).Resources("persistentvolumeclaims").RuleOrDie(), </ins> eventsRule(), }, } if utilfeature.DefaultFeatureGate.Enabled(features.StatefulSetAutoDeletePVC) { role.Rules = append(role.Rules, rbacv1helpers.NewRule("update", "delete").Groups(legacyGroup).Resources("persistentvolumeclaims").RuleOrDie()) <ins> role.Rules = append(role.Rules, rbacv1helpers.NewRule("update").Groups(legacyGroup).Resources("pods/finalizers").RuleOrDie()) </ins> } return role

verbs: - create - get <ins> - list - watch </ins> - apiGroups: - "" - events.k8s.io

verbs: - delete - update <ins> - apiGroups: - "" resources: - pods/finalizers verbs: - update </ins> - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:
Change:
KMS Plugins require communication via grpc UDS. Currently, the k8s grpc client sets the authority header to the socket path which is marked as invalid preventing successful socket communication. I expect a custom KMS provider plugin to be sent valid authority headers so that successful communication can be established between the k8s and grpc client/server. Create a grpc server according to the and attempt to establish socket communication. This issue has been resolved in for device plugins and CSI. The same solution will likely fix this issue as well. I will create a PR for this and link it here after. <details</details<detailsNone </details<details</details<details</details<details</details<details</details
/sig auth /triage accepted

Discussion:
s := &gRPCService{callTimeout: callTimeout} s.connection, err = grpc.Dial( addr, <ins> grpc.WithAuthority("localhost"), </ins> grpc.WithTransportCredentials(insecure.NewCredentials()), grpc.WithDefaultCallOptions(grpc.WaitForReady(true)), grpc.WithContextDialer(

"google.golang.org/grpc" "google.golang.org/grpc/codes" <ins> "google.golang.org/grpc/metadata" </ins> "google.golang.org/grpc/status" "k8s.io/apimachinery/pkg/util/wait"

// NewBase64Plugin is a constructor for Base64Plugin. func NewBase64Plugin(t testing.TB, socketPath string) *Base64Plugin { <del> server := grpc.NewServer() </del> <ins> server := grpc.NewServer( grpc.UnaryInterceptor( func(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) { if val := metadata.ValueFromIncomingContext(ctx, ":authority"); len(val) != 1 || val[0] != "localhost" { t.Errorf("wanted localhost authority, got: %v", val) } return handler(ctx, req) }, ), ) </ins> result := &Base64Plugin{ grpcServer: server, mu:         &sync.Mutex{},
Change:
pull-kubernetes-integration TestSuccessPolicy/jobwithsuccessPolicywithsucceededCount;jobhasSuccessCriteriaMetandCompleteconditionsevenifsomeindexesremainpending 2024-09-27 No response /sig apps
/assign
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Thank you for letting me know. I will try to investigate the root cause of the flaky case.
It seems that this failure is not related to the test case. It looks like test infrastructure limitations. What do you think?
Maybe it's a sign that we are putting too short of a deadline somewhere?
I think so too. Actually, we can see the same error in as well. So I would propose increasing timeout here: WDYT?
I don't think that would help:
That makes sense. In that case, can we output the log and retry the listing instead of disrupting polling there?
The root cause is disrupting the polling if the listing fails even once.
My proposal is the following:
I see, yeah. But I wonder if the passed to contains any additional timeout. Maybe not.
It seems that we received dedicated timeout as a last arg and then set the timeout to like this: So, I think that it looks better to retry the listing until reaching the polling deadline.
Throughout more investigation, it seems that the returns err immediately once the condition func returns err there:
I simulated the error situation in my local like this:
I opened the PR, PTAL:

Discussion:
if err := wait.PollUntilContextTimeout(ctx, waitInterval, timeout, true, func(ctx context.Context) (bool, error) { updatedJob, err := clientSet.BatchV1().Jobs(jobObj.Namespace).Get(ctx, jobObj.Name, metav1.GetOptions{}) if err != nil { <del> t.Fatalf("Failed to get updated Job: %v", err) </del> <ins> t.Logf("Failed to get updated Job: %v", err) return false, nil </ins> } actualCounts = podsByStatus{ Active:      int(updatedJob.Status.Active),
Change:
The module now logs two errors during module initialization. Simply loading the module will cause two errors to be printed to stderr if the code is not run as root, or is run on a node without nfacct support. This is due to being used when creating Prometheus metrics during module variable initialization, which calls if the nfacct client cannot be initialized. This regression was introduced by: K3s ships all the various Kubernetes components bundled in a single multicall binary, which means that our now logs these errors when it is run as a non-root user. No error logs on module init cc <details</detailsn/a n/a n/a n/a n/a area/proxy sig/network
/sig network
/triage accepted /assign
I was about to fix this, this initialization happens in the unit tests as well .
thanks for the quick response! Do you think you'll have a patch that we could use temporarily for k3s until v1.31.1 is out? We were considering just removing the call for our initial 1.31 release, unless you have a better suggestion.
can you confirm is fine?

Discussion:
"kubeproxy_iptables_ct_state_invalid_dropped_packets_total", "packets dropped by iptables to work around conntrack problems", nil, nil, metrics.ALPHA, "") <del> IPTablesCTStateInvalidDroppedNFAcctCounter   = "ct_state_invalid_dropped_pkts" iptablesCTStateInvalidDroppedMetricCollector = newNFAcctMetricCollector(IPTablesCTStateInvalidDroppedNFAcctCounter, iptablesCTStateInvalidDroppedPacketsDescription) </del> <ins> IPTablesCTStateInvalidDroppedNFAcctCounter = "ct_state_invalid_dropped_pkts" </ins> // IPTablesRestoreFailuresTotal is the number of iptables restore failures that the proxy has // seen.

"kubeproxy_iptables_localhost_nodeports_accepted_packets_total", "Number of packets accepted on nodeports of loopback interface", nil, nil, metrics.ALPHA, "") <del> LocalhostNodePortAcceptedNFAcctCounter     = "localhost_nps_accepted_pkts" localhostNodePortsAcceptedMetricsCollector = newNFAcctMetricCollector(LocalhostNodePortAcceptedNFAcctCounter, localhostNodePortsAcceptedPacketsDescription) </del> <ins> LocalhostNodePortAcceptedNFAcctCounter = "localhost_nps_accepted_pkts" </ins> ) var registerMetricsOnce sync.Once

switch mode { case kubeproxyconfig.ProxyModeIPTables: <ins> iptablesCTStateInvalidDroppedMetricCollector := newNFAcctMetricCollector(IPTablesCTStateInvalidDroppedNFAcctCounter, iptablesCTStateInvalidDroppedPacketsDescription) </ins> if iptablesCTStateInvalidDroppedMetricCollector != nil { legacyregistry.CustomMustRegister(iptablesCTStateInvalidDroppedMetricCollector) } <ins> localhostNodePortsAcceptedMetricsCollector := newNFAcctMetricCollector(LocalhostNodePortAcceptedNFAcctCounter, localhostNodePortsAcceptedPacketsDescription) </ins> if localhostNodePortsAcceptedMetricsCollector != nil { legacyregistry.CustomMustRegister(localhostNodePortsAcceptedMetricsCollector) }
Change:
Since I upgraded my kubernetes cluster from to , kubelet fails to restart on Windows. The error messages in the logs are: I expected kubelet to start even if the file exists, this was the behavior in the previous versions. a Windows Kubernetes Node again and watch it fail due to the file already existing. I think this Issue has to do with the commit where socket files are not removed anymore causing the start to fail because the file already exists. <details</detailsOn Premise / No Cloud Provider <details</detailsNo response <detailsContainerd Version: 1.7.20 </detailsNo response
/sig windows
/area kubelet
/cc
/sig node /triage accepted /priority critical-urgent
I was able to reproduce this
/assign Given the severity, assigning to you.
reverting fixes the issue
The reason for the issue is that kubernetes used go , whilst the release uses : / The fix for has been implemented in go (and its rc) and has not been backported to . Commit of fix: So updating kubernetes back to go fixes this issue and resolves the TODO in
/reopen The PR needs to be cherry-picked and released before we can actually close this.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/close Cherry pick was merged so this should be good now. This will be in v.1.31.1 when that goes out.
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
if filePath == m.checkpointFile() { continue } <del> stat, err := os.Stat(filePath) </del> <ins> // TODO: Until the bug - https://github.com/golang/go/issues/33357 is fixed, os.stat wouldn't return the // right mode(socket) on windows. Hence deleting the file, without checking whether // its a socket, on windows. stat, err := os.Lstat(filePath) </ins> if err != nil { klog.ErrorS(err, "Failed to stat file", "path", filePath) continue } <del> if stat.IsDir() || stat.Mode()&os.ModeSocket == 0 { </del> <ins> if stat.IsDir() { </ins> continue } err = os.RemoveAll(filePath)