jiebi/CodeConvo huggingface dataset:
Change:
// Accept calls the Visit method on visitor that corresponds to elem's Kind func (elem GroupKindElement) Accept(visitor KindVisitor) error { <del> if elem.GroupMatch("apps", "extensions") && elem.Kind == "DaemonSet" { </del> <ins> switch { case elem.GroupMatch("apps", "extensions") && elem.Kind == "DaemonSet": </ins> visitor.VisitDaemonSet(elem) <del> return nil } if elem.GroupMatch("apps", "extensions") && elem.Kind == "Deployment" { </del> <ins> case elem.GroupMatch("apps", "extensions") && elem.Kind == "Deployment": </ins> visitor.VisitDeployment(elem) <del> return nil } if elem.GroupMatch("batch") && elem.Kind == "Job" { </del> <ins> case elem.GroupMatch("batch") && elem.Kind == "Job": </ins> visitor.VisitJob(elem) <del> return nil } if elem.GroupMatch("", "core") && elem.Kind == "Pod" { </del> <ins> case elem.GroupMatch("", "core") && elem.Kind == "Pod": </ins> visitor.VisitPod(elem) <del> return nil } if elem.GroupMatch("extensions") && elem.Kind == "ReplicaSet" { </del> <ins> case elem.GroupMatch("extensions") && elem.Kind == "ReplicaSet": </ins> visitor.VisitReplicaSet(elem) <del> return nil } if elem.GroupMatch("", "core") && elem.Kind == "ReplicationController" { </del> <ins> case elem.GroupMatch("", "core") && elem.Kind == "ReplicationController": </ins> visitor.VisitReplicationController(elem) <del> return nil } if elem.GroupMatch("apps") && elem.Kind == "StatefulSet" { </del> <ins> case elem.GroupMatch("apps") && elem.Kind == "StatefulSet": </ins> visitor.VisitStatefulSet(elem) <del> return nil </del> <ins> default: return fmt.Errorf("no visitor method exists for %v", elem) </ins> } <del> return fmt.Errorf("no visitor method exists for %v", elem) </del> <ins> return nil </ins> } // GroupMatch returns true if and only if elem's group matches one

Discussion:
What happened: There are many if cases in kind visitor. What you expected to happen: Use switch instand of more three if cases.
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
I sent a PR to solve the issue and the PR is wait for merging.
Change:
``` --client-certificate="": path to client-certificate for the user entry in kubeconfig --client-key="": path to client-key for the user entry in kubeconfig <del> --embed-certs=false: embed client cert/key for the user entry in kubeconfig </del> <ins> --embed-certs[=false]: embed client cert/key for the user entry in kubeconfig </ins> --password="": password for the user entry in kubeconfig --token="": token for the user entry in kubeconfig --username="": username for the user entry in kubeconfig

Discussion:
It acts like a boolean flag but requires an argument, unlike boolean flag is pretty much every environment. We need to find a better way to express the things that this is expressing. Maybe a add a tristate to the pflag lib that behaves the same way but doesn't demand an argument?
cc
The handles "true", "false", "unset" and has a default value. I seem to recall you were looking at changing it, but we needed to preserve the value. The complain here is that you have to do instead of just . /cc
fixing is really easy....
Change:
if mockReplenish.namespace != oldService.Namespace { t.Errorf("Unexpected namespace %v", mockReplenish.namespace) } <ins> mockReplenish = &testReplenishment{} options = ReplenishmentControllerOptions{ GroupKind:         api.Kind("Service"), ReplenishmentFunc: mockReplenish.Replenish, ResyncPeriod:      controller.NoResyncPeriodFunc, } oldService = &api.Service{ ObjectMeta: api.ObjectMeta{Namespace: "test", Name: "mysvc"}, Spec: api.ServiceSpec{ Type: api.ServiceTypeNodePort, Ports: []api.ServicePort{{ Port:       80, TargetPort: intstr.FromInt(80), }}, }, } newService = &api.Service{ ObjectMeta: api.ObjectMeta{Namespace: "test", Name: "mysvc"}, Spec: api.ServiceSpec{ Type: api.ServiceTypeNodePort, Ports: []api.ServicePort{{ Port:       81, TargetPort: intstr.FromInt(81), }}}, } updateFunc = ServiceReplenishmentUpdateFunc(&options) updateFunc(oldService, newService) if mockReplenish.groupKind == api.Kind("Service") { t.Errorf("Unexpected group kind %v", mockReplenish.groupKind) } if mockReplenish.namespace == oldService.Namespace { t.Errorf("Unexpected namespace %v", mockReplenish.namespace) } </ins> }

Discussion:
master-informing: capz-windows-containerd-master capz-e2e.[It] Conformance Tests conformance-tests ! 2023-03-10 04:56:51 +0000 UTC No response /sig testing
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : ### Which jobs are failing? ### Since when has it been failing? /sig testing 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 windows /triage accepted
no major change between passing test on 3/9 17:55 PST and failing test on 3/9 20:56 PST
containerd logs have error about failing to unpack azure-cloud-manager on both nodes:
kubelet logs confirm this:
looks to be related to bumping capz to 1.8 which uses the cloud-provider oot image: caused by upgrading to 1.8 capz in combination with using OOT
This looks to be affecting our release jobs as well:
looks like the image being built is linux only () and is being pulled by windows. When setting up the snapshot in containerd it is failing (as it is missing files required by windows)
For the passing test the image is multi-arch manifest, so the windows image pulls properly (azure-cloud-node-manager:)
There is a missing env in the see
Change:
apiserver_dropped_requests_total{request_kind="mutating"} 1 # HELP apiserver_request_total [STABLE] Counter of apiserver requests broken out for each verb, dry run value, group, version, resource, scope, component, and HTTP response code. # TYPE apiserver_request_total counter <del> apiserver_request_total{code="429",component="apiserver",dry_run="All",group="batch",resource="jobs",scope="cluster",subresource="status",verb="PATCH",version="v1"} 1 </del> <ins> apiserver_request_total{code="429",component="apiserver",dry_run="All",group="batch",resource="jobs",scope="resource",subresource="status",verb="PATCH",version="v1"} 1 </ins> `, }, }

Discussion:
I've observed, that some metrics has and labels. (create) requests are "single resource", therefor they should be classified as . Def: customresourcehandler uses , which is based on the RequstInfo only: the RequestInfo is based only on the requests: method and url example: e.g: Since this RequestInfo has Name and Namespace empty, it is classified as . In a similar way it could be explained why: There's a mismatch in scope classification between built-in and custom resources: The key difference - the check if either "name" was provided OR it is a : Where the metrics.CleanScope ONLY checks, if name is not-empty. Tested: = v1.20 There were other scope related issues <1.20 and the distinction is not obvious. <details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/triage accepted
Change:
MASTER_NAME="${INSTANCE_PREFIX}-master" MASTER_TAG="${INSTANCE_PREFIX}-master" MINION_TAG="${INSTANCE_PREFIX}-minion" <del> CLUSTER_IP_RANGE="10.245.0.0/16" MINION_IP_RANGES=($(eval echo "10.245.{1..${NUM_MINIONS}}.0/24")) </del> <ins> CLUSTER_IP_RANGE="${KUBE_GCE_CLUSTER_CLASS_B:-10.245}.0.0/16" MINION_IP_RANGES=($(eval echo "${KUBE_GCE_CLUSTER_CLASS_B:-10.245}.{1..${NUM_MINIONS}}.0/24")) </ins> MASTER_IP_RANGE="${MASTER_IP_RANGE:-10.246.0.0/24}" MINION_SCOPES=("storage-ro" "compute-rw") # Increase the sleep interval value if concerned about API rate limits. 3, in seconds, is the default. POLL_SLEEP_INTERVAL=3

Discussion:
This is an offshoot of . cc Here's a log from a single showing that it's getting it's context screwed over by the other clusters coming up at the same time, even those its local environment never changed: Here's the relevant part of the new script: ( is in a separate commit and allows the override of on the GCE so that this script can work.)
I think this can be resolved by having kube- set the context by exporting KUBECONFIG, so a subsequent run doesn't overwrite it.
After some digging with it's a bit trickier than I thought. If we want to be able to run kube-up in parallel from the same branch/working directory, needs to create a separate kubeconfig for each run. But we also want kube-up to set config such that you can immediately run against the created cluster. Probably best to defer until is resolved.
cc And the script is sitting in
Change:
} } <ins> if fieldPatchStrategy == replaceDirective { return false, nil } </ins> // Check the individual keys. return mapsHaveConflicts(leftType, rightType, fieldType) default:

Discussion:
Extracted from The RawExtension type allows an API object to inline arbitrary JSON. strategicpatch.CreateTwoWayMergePatch returns an error trying to map that inlined JSON to struct fields. It should be able to compute a patch for an object containing a field of that type.
cc
We need to decide what strategic merge patch should do in the following scenarios: unknown fields (can be encountered when the API or a user-defined object has a new field the compiled-in struct doesn't have yet) unmergeable fields (like RawExtension) cc
The current behavior is: unknown fields: trying to merge a unknown field will fail when lookup the metadata in the struct tags unmergeable fields: will be replaced as raw byte array Maybe we can use generic json merge for unmergeable fields?
Did that change since 1.5? In 1.5, we were getting an error during patch computation for objects with a RawExtension field
Sorry. This behavior is in 1.4.7. e.g . It will error in 1.5.
Yeah, the field gets replaced. Even in 1.4.7, an unknown field (like initcontainers in pods) or an object including a RawExtension (anything with a field of type or ) would error
My personal favor would be to instruct the patch to ignore such field, seems the cleanest approach to me. Similarly to how we allow annotating deletion and merging.
wouldn't it be confusing to submit a patch with stuff in that field, have the patch accepted, and have none of your submitted changes take effect? seems like the least surprising thing would be to treat struct fields like or as
How about both, iow. having as a default and as an opt-in. This would allow the resource author to decide how his resource should be treated. Eventually on we could return the ignored fields. Having said that we could start with right away. I think I could work on a patch implementing that if majority agrees (
I think is a good place to start when computing/applying patches for known struct fields like RawExtension. I'll open a separate issue for client-side handling of computing patches for unknown fields
Ignore the field sounds like a really good solution. WDYT of printing a warning to stdeer?
what does ignoring instead of replacing get us?
Sorry I was reading the comment on my phone between other things. Ignore my comment.
Change:
origCtx, store, _ := testSetup(t) ctx, cancel := context.WithCancel(origCtx) w := store.watcher.createWatchChan(ctx, "/abc", 0, false, false, newTestTransformer(), storage.Everything) <del> // make resutlChan and errChan blocking to ensure ordering. </del> <ins> // make resultChan and errChan blocking to ensure ordering. </ins> w.resultChan = make(chan watch.Event) w.errChan = make(chan error) // The event flow goes like:

Discussion:
While working on generalizing tests to somehow better define spec for storage interface (and share them across all implementation of storage.interface - in particular etcd3 and watchcache), I found an unexpected inconsistency in Delete operation in etcd3. What is happening is that it effectively returns the state of the object from just before the deletion: However, this is inconsistent with how our watch is working, which is returning the state of the object from just before the deletion, but it sets the RV to the moment of deletion (which Delete call isn't doing). This sounds like a bug to me, but given this is a long-standing behavior we may need to take additional care when fixing this. /kind bug /sig api-machinery /priority important-soon /cc
I opened as a fix for it.
/triage accepted
Change:
framework.AddOrUpdateLabelOnNode(cs, nodeName, k, v) framework.ExpectNodeHasLabel(cs, nodeName, k, v) defer framework.RemoveLabelOffNode(cs, nodeName, k) // make the nodes have balanced cpu,mem usage <del> createBalancedPodForNodes(f, cs, ns, nodeList.Items, podRequestedResource, 0.6) </del> <ins> err := createBalancedPodForNodes(f, cs, ns, nodeList.Items, podRequestedResource, 0.6) framework.ExpectNoError(err) </ins> By("Trying to launch the pod, now with podAffinity.") labelPodName := "pod-with-podaffinity" pod = createPausePod(f, pausePodConfig{

Discussion:
Chronically failing test. Perhaps covers deprecated behavior? /sig scalability /assign
shows up in
/sig scheduling is one of scheduling e2e test.
/assign I'll check this one.
According to the log, the balanced pods were not created by scheduler, the cpu/mem usage was unchanged.
This test failing every other run. Fix or disable? Blocking 1.7?
similar to , move to 1.8, but I'll still working on that.
Change:
return nil } <del> // List names of registered log formats </del> <ins> // List names of registered log formats (sorted) </ins> func (lfr *LogFormatRegistry) List() []string { formats := make([]string, 0, len(lfr.registry)) for f := range lfr.registry { formats = append(formats, f) } <ins> sort.Strings(formats) </ins> return formats }

Discussion:
What happened: 50% of builds have a different man page content What you expected to happen: It should be possible to get bit-identical build results - might need a patch similar to - knows these things. How to reproduce it (as minimally and precisely as possible): build kubernetes1.19 openSUSE package a few times and compare results. e.g. with Anything else we need to know?: Environment: OS: openSUSE-Tumbleweed While working on for , I found that when building the kubernetes1.19 package, there was sometimes such a difference between builds:
/sig release
/sig scheduling
Change:
} cfg := rest.CopyConfig(restConfig) <del> cfg.Host = u.Host </del> <ins> cfg.Host = u.Scheme + "://" + u.Host </ins> cfg.APIPath = u.Path return complete(cfg)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: In the case of an admission webhook that specifies a url, we only use the Host and Path fields of the parsed url, (url is defined as ) When a service based webhook is constructed, we do define a scheme for the config If the scheme is not specified when the REST client is constructed, then it defaults to http, unless CA, Cert, or config.Insecure is set What you expected to happen: Admission Webhooks should honor the scheme part of the url provided in their client config
/sig api-machinery
/assign
Change:
memoryCapacity := node.Status.Capacity["memory"] memoryLimit := memoryCapacity.Value() <del> matchResourceMetrics := gstruct.MatchAllKeys(gstruct.Keys{ </del> <ins> matchResourceMetrics := gomega.And(gstruct.MatchKeys(gstruct.IgnoreMissing, gstruct.Keys{ </ins> "scrape_error": gstruct.Ignore(), "node_cpu_usage_seconds_total": gstruct.MatchAllElements(nodeID, gstruct.Elements{ "": boundedSample(1, 1e6),

Discussion:
Node e2e features is failing after PR for graduating swap to beta is merged. After is merged. Test needs to be adjusted for the extra field for swap usage. No response /sig node
/cc
/assign
/triage accepted /priority critical-urgent
Change:
return finalURL.String() } <ins> // Similar to finalURL(), but if the request contains name of an object // (e.g. GET for a specific Pod) it will be substited with "<name>". func (r Request) finalURLTemplate() string { if len(r.resourceName) != 0 { r.resourceName = "<name>" } return r.finalURL() } </ins> // Watch attempts to begin watching the requested location. // Returns a watch.Interface, or an error. func (r *Request) Watch() (watch.Interface, error) {

Discussion:
Currently we do not measure latency for REST operations. This is important for any component that performs non-watch operations (scheduler, controllers, kubelet). This is also prerequisite to actually make sure that all API calls take less than 1 sec ( ).
The apiserver is already , including for REST operations. You can scrape the metrics by hitting the /metrics HTTP endpoint.
Sorry, I was not clear in the description. I'm more interested on the client side and with more details so that I can measure things like: how long it takes to write bindings in scheduler how long it takes to update status in kubelet I'd think about it as a counterpart for apiserver stats.
Change:
return nil, framework.NewStatus(framework.Unschedulable, msg) } } <del> state.SkipFilterPlugins = skipPlugins </del> return result, nil }

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:
fsckErrorsCorrected = 1 // 'fsck' found errors but exited without correcting them fsckErrorsUncorrected = 4 <ins> // Error thrown by exec cmd.Run() when process spawned by cmd.Start() completes before cmd.Wait() is called (see - k/k issue #103753) errNoChildProcesses = "wait: no child processes" </ins> ) // Mounter provides the default implementation of mount.Interface

Discussion:
While investigating some slowness in mounting/unmounting operations of PVs (in this case EFS volumes) for pods, we observed errors like these: fortunately it does recover quickly on Kubelet’s next retry: Looking through the Kubelet code I found out that the issue is not related to the umount calls themselves, but rather a race condition inside where we call umount. Because of the way golang’s function (called inside ) is implemented, it for the child process to finish after it is . Since there isn't any locking on the child process across those function calls, it's possible that the child process exits event before the Wait() call starts. In such case the wait call returns with a error (). This error is more likely to happen especially if the gap between the Start() and Wait() calls is more (which could for e,g happen if the goroutine had CPU cycles snatched away from it for some time in between those calls). A similar issue also exists in the . While this is a self-recovering issue (because of Kubelet retries), it does seem to increase the pod startup/cleanup latency upto a 1s. Open to suggestions for a fix. The simplest one occurring to me is to treat the error as a special one on which we don't actually return an error for the mount/unmount calls. /sig storage /sig scalability /assign
Another thing is when analyzing a distribution of such errors across different nodes, we observed a skew. The top 10% of the nodes were seeing more than 90% of these errors. And these are nodes that are running hotter (w.r.t the pod churn) compared to others: ! Given this, I'm wondering if those errors are higher on those nodes just because of statistical significance or other causes like more GC pauses happening on those nodes.
/triage accepted
^ I've opened this PR to fix the Mount/Unmount functions in the file. In general we might want to make a similar fix to other invocations of exec.Run() and exec.CombinedOutput() within our codebase. But that'll be a bigger change. Happy to open another issue for it.
Sorry for opening the PR against wrong repo, here's the right one -
Change:
# TODO(dawnchen): Check $CONTAINER_RUNTIME to decide which # cloud_config yaml file should be passed <ins> # TODO(mbforbes): Make $1 required. # TODO(mbforbes): Document required vars (for this and call chain). # $1 version </ins> function create-node-instance-template { <del> create-node-template "${NODE_INSTANCE_PREFIX}-template" "${scope_flags[*]}"  </del> <ins> local suffix="" if [[ -n ${1:-} ]]; then suffix="-${1}" fi create-node-template "${NODE_INSTANCE_PREFIX}-template${suffix}" "${scope_flags[*]}"  </ins> "kube-env=${KUBE_TEMP}/node-kube-env.yaml"  "user-data=${KUBE_ROOT}/cluster/gce/coreos/node.yaml" }

Discussion:
See issue as the roll-up for node upgrades. tl;dr: Update MIG template, then call a MIG rollingupdate. More details: When upgrading nodes, an in-place upgrade must worry about leftover state on the boot disk, VM configuration like IP tables, and the idempotency of salt. Getting a fresh VM instead would remove these concerns and provide a clean state for a new node. Furthermore, a versioned node spec () includes the tuple of (kubelet, kube-proxy, docker, kernel/OS). In the general case, changing docker or the kernel/OS means we have to stop the running pods. Once know we have to stop the pods, the simplest upgrade mechanism is to totally down the node and provision a new one. Provisioning a new node is also a great backup to have for node repairs. To be clear, though, this issue is entirely separate from node repairs; once we have the capability to grow the cluster by adding new nodes, this mechanism, and other repair mechanisms, will build on top of that capability. This was blocked by: nodes joining a running cluster (template-only metadata) References: The most relevant discussion regarding the worries of complications with state while doing in-place upgrades is .
FWIW, I think we need this as a fallback to repair completely borked nodes? That is, it may not be necessary for upgrades per se, but could end up being independently useful.
Thanks for the comment, I updated the description to be clear about what this issue is addressing. Having the ability to add new nodes to a cluster will both enable this upgrade path as well as give us a great "hammer" to use for repairs.
Working on this now.