jiebi/CodeConvo huggingface dataset:
Change:
return coreDNSConfigMap, corefile, currentCoreDNSversion, nil } <del> func patchCoreDNSDeployment(client clientset.Interface, coreDNSCorefileName string) error { </del> <ins> func setCorefile(client clientset.Interface, coreDNSCorefileName string) error { </ins> dnsDeployment, err := client.AppsV1().Deployments(metav1.NamespaceSystem).Get(context.TODO(), kubeadmconstants.CoreDNSDeploymentName, metav1.GetOptions{}) if err != nil { return err } <del> patch := fmt.Sprintf(`{"spec":{"template":{"spec":{"volumes":[{"name": "config-volume", "configMap":{"name": "coredns", "items":[{"key": "%s", "path": "%s"}]}}]}}}}`, coreDNSCorefileName, coreDNSCorefileName) </del> <ins> patch := fmt.Sprintf(`{"spec":{"template":{"spec":{"volumes":[{"name": "config-volume", "configMap":{"name": "coredns", "items":[{"key": "%s", "path": "Corefile"}]}}]}}}}`, coreDNSCorefileName) </ins> if _, err := client.AppsV1().Deployments(dnsDeployment.ObjectMeta.Namespace).Patch(context.TODO(), dnsDeployment.Name, types.StrategicMergePatchType, []byte(patch), metav1.PatchOptions{}); err != nil { return errors.Wrap(err, "unable to patch the CoreDNS deployment")

Discussion:
What happened: Coredns failed to start in 1.17 deployment when it tried to retain a backed up Corefile with error message: Caddyfile via flag: open /etc/coredns/Corefile: no such file or directory What you expected to happen: Coredns starts normally with the backed-up Corefile How to reproduce it (as minimally and precisely as possible): Deploy a k8s 1.17 cluster and trigger coredns Corefile migration and make it fail. In our case, this was triggered in a three master -setup with 'old' method of running 'kubeadm init' for each master. Also the core-dns docker image used was tagged with '1.6.7-1', apparently causing the corefile migration version check to fail Anything else we need to know?: This seems to be caused by Both 'key' and 'path' are set to 'Corefile-backup' when this function is called. Should the 'path' always stay as 'Corefile' because that is where the container expects to find the config file? Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-02-16T17:51:57Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-02-16T17:47:13Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Custom deployment in Openstack environment OS (e.g: ): NAME="SLES" VERSION="15-SP1" VERSIONID="15.1" PRETTYNAME="SUSE Linux Enterprise Server 15 SP1" Kernel (e.g. ): 12.14-197.29-default Install tools: kubeadm Network plugin and version (if this is a network-related bug): Others:
/sig cluster-lifecycle
/assign
/area kubeadm
Change:
return allErrs } <ins> // Validates that a Quantity is positive func ValidatePositiveQuantityValue(value resource.Quantity, fldPath *field.Path) field.ErrorList { allErrs := field.ErrorList{} if value.Cmp(resource.Quantity{}) <= 0 { allErrs = append(allErrs, field.Invalid(fldPath, value.String(), isNotPositiveErrorMsg)) } return allErrs } </ins> func ValidateImmutableField(newVal, oldVal interface{}, fldPath *field.Path) field.ErrorList { return genericvalidation.ValidateImmutableField(newVal, oldVal, fldPath) }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG REPORT /kind bug What happened: If someone requests a zero (0) capacity PVC and an administrator creates a zero (0) capacity PV, Kubernetes will happily bind them together. Unfortunately, any use of this PVC/PV combination by a pod will fail. It fails because the zero capacity PV cannot be formatted or mounted successfully. Note: The same issue happens for dynamically provisioned PVs. What you expected to happen: I expect that Kubernetes would not allow creation of invalid PVC and PV objects, aka zero (0) capacity PVs and PVCs. How to reproduce it (as minimally and precisely as possible): Create a pod that requests a zero capacity PVC, using dynamic PV provisioning is simpler than creating your own zero (0) capacity PV. The pod will fail to reach a running state, since the related PV fails to be formatted and mounted successfully. Here is the error that I received for a test I performed requesting a zero capacity PVC using ceph rbd: Anything else we need to know?: Here is a related item with a specific fix for external ceph rbd provisioner: Environment: Nothing specific to environment
/sig storage
/assign
Change:
eventBroadcaster := record.NewBroadcaster() eventBroadcaster.StartLogging(glog.Infof) eventBroadcaster.StartRecordingToSink(&v1core.EventSinkImpl{Interface: v1core.New(kubeClient.Core().RESTClient()).Events("")}) <del> recorder := eventBroadcaster.NewRecorder(scheme.Scheme, v1.EventSource{Component: "statefulset"}) </del> <ins> recorder := eventBroadcaster.NewRecorder(scheme.Scheme, v1.EventSource{Component: "statefulset-controller"}) </ins> ssc := &StatefulSetController{ kubeClient: kubeClient,

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: kubect create -f to create statefulset, and describe the statefulset, output the event likes <preEvents: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m 1 statefulset Normal SuccessfulCreate create Claim www-web-0 Pod web-0 in StatefulSet web success 1m 1m 1 statefulset Normal SuccessfulCreate create Pod web-0 in StatefulSet web successful </preWhat you expected to happen: the From of event change to 'statefulset-controller' in output, let know the source of event more obvious, likes the event when create job and other resource(replicaset,replication). <preEvents: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 3m 3m 1 job-controller Normal SuccessfulCreate Created pod: pi-7gd2m </preHow to reproduce it (as minimally and precisely as possible): create a statefulset and describe it to see the event Anything else we need to know?: Environment: Kubernetes version (use ):kubernetes 1.7 Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
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
/assign
/area controller-manager
/sig node
Change:
// NodeSystemInfo is a set of ids/uuids to uniquely identify the node. type NodeSystemInfo struct { // MachineID is the machine-id reported by the node <del> MachineID string `json:"machineID"` </del> <ins> MachineID string `json:"machineID" description:"machine-id reported by the node"` </ins> // SystemUUID is the system-uuid reported by the node <del> SystemUUID string `json:"systemUUID"` </del> <ins> SystemUUID string `json:"systemUUID" description:"system-uuid reported by the node"` </ins> // BootID is the boot-id reported by the node BootID string `json:"bootID" description:"boot id is the boot-id reported by the node"` // Kernel version reported by the node

Discussion:
PR had a few errors in its API objects, where the "description" field errors in its JSON declarations were missing. But, the "verify-" presubmit check didn't flag them. This should be investigated and fixed.
Could you please take a look at this?
Change:
<ins> all: push TAG = 0.1 mt: mt.go CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -ldflags '-w' ./mt.go image: mt sudo docker build -t kubernetes/mounttest:$(TAG) . push: image sudo docker push kubernetes/mounttest:$(TAG) clean: rm -f mt </ins>

Discussion:
I'd like to commit without e2e support so others can unblock. We need to come back to get e2e on this. I could use help, and it seems like an easy test...
Sorry for my incorrect PR. Now I have amend it.
Change:
<del> apiVersion: v1 kind: ReplicationController metadata: name: cauldron namespace: default labels: app: cauldron spec: replicas: 1 selector: app: cauldron template: metadata: labels: app: cauldron spec: containers: - name: cauldron image: kubernetes/cauldron:1.0 imagePullPolicy: Always args: ["--up_to=-1"] </del>

Discussion:
We've deleted all repos from Docker Hub and will be retiring the org/user (ref: ) Apparently the repo is referenced for docker push and pull in It's unclear to me whether we have broken anything, or if this is dead code. I would use to find out if this is referenced anywhere (aside from sundry vendor dirs) If dead code: remove it If used: move to test/e2e/images and follow the same pattern there used to push to /sig testing /area test /wg k8s-infra /priority important-soon /help /good-first-issue I believe this is a pretty straightforward issue and am happy to review whatever PR's are made for it
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : We've deleted all repos from Docker Hub and will be retiring the org/user (ref: ) /area test /wg k8s-infra /priority important-soon /good-first-issue I believe this is a pretty straightforward issue and am happy to review whatever PR's are made for it 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
Change:
"k8s.io/apiserver/pkg/authentication/request/union" "k8s.io/apiserver/pkg/authentication/request/x509" "k8s.io/apiserver/pkg/authentication/token/tokenfile" <del> "k8s.io/apiserver/pkg/authentication/user" </del> "k8s.io/apiserver/plugin/pkg/authenticator/password/keystone" "k8s.io/apiserver/plugin/pkg/authenticator/password/passwordfile" "k8s.io/apiserver/plugin/pkg/authenticator/request/basicauth"

Discussion:
When an auth proxy tries to proxy an anonymous request, the user.Info ends up with the group system:authenticated, which is wrong.
Change:
// Doesn't check whether the hosts have changed, since host updating is handled // separately. <del> func (gce *GCECloud) targetPoolNeedsUpdate(name, region string, affinityType v1.ServiceAffinity) (exists bool, needsUpdate bool, err error) { </del> <ins> func (gce *GCECloud) targetPoolNeedsRecreation(name, region string, affinityType v1.ServiceAffinity) (exists bool, needsRecreation bool, err error) { </ins> tp, err := gce.GetTargetPool(name, region) if err != nil { if isHTTPErrorCode(err, http.StatusNotFound) {

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig network /area cloudprovider What happened: The cloud provider interface that should . The GCE provider does this for but not for . Every other in-tree provider implements by fully updating the load balancer including updated backend nodes: , , , And the following out-of-tree providers do as well and Oracle (not oss yet). What you expected to happen: I expect that all cloud providers implement by creating or fully updating the load balancer if it already exists. Related discussion: /cc
/assign Make sense to make implementation in GCE consistent with others for the ease of up-coming service controller enhancement. This sounds like a 1.10 task.
is this task blocking you on another attempt at refactoring the service controller sync logic?
yup
Change:
local go_version IFS=" " read -ra go_version <<< "$(GOFLAGS='' go version)" local minimum_go_version <del> # TODO: Update to go1.23 as soon we are ready to merge this </del> minimum_go_version=go1.22 if [[ "${minimum_go_version}" != $(echo -e "${minimum_go_version}n${go_version[2]}" | sort -s -t. -k 1,1 -k 2,2n -k 3,3n | head -n1) && "${go_version[2]}" != "devel" ]]; then kube::log::usage_from_stdin <<EOF

Discussion:
sgtm, add an issue labeled as release-blocking and in the milestone to either promote to 1.23.0 or revert this to 1.22.x before our 1.31 release Originally posted by in Kubernetes is being built and tested with go1.23rc2 at HEAD () to let it bake in the CI and help iron out issues, if any, with this version of Go. However, for the 1.31 release, the version of Go should be a non-rc, released version. The release timeline of go1.23.0 is ~same as the release timeline of K8s 1.31.0 (see ). If go1.23.0 is not out by then, we should revert to go1.22.x before cutting K8s 1.31.0. /sig release architecture /area code-organization /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
/triage accepted /cc
/milestone v1.31
cc
xposting relevant slack thread:
Also unlike in the past, missing shipping 1.23.0 in 1.31.0 is not a big deal, we have much more room to switch to 1.23.0 in a patch release after all the compat changes with the go team. So we should not fear reverting if the timelines don't line up.
(though go1.23 adds the thing that makes it workable to default to old go version compat settings, so we'll have to eke out another 5 months on 1.21/1.22 for until we can adopt 1.23 on release branches in ~Jan if we miss 1.31, but that's how it looks like it will have to happen)
Change:
} if o.Local || cmdutil.GetDryRunFlag(o.Cmd) { <del> return o.PrintObject(o.Cmd, o.Local, o.Mapper, info.Object, o.Out) </del> <ins> if err := o.PrintObject(o.Cmd, o.Local, o.Mapper, info.Object, o.Out); err != nil { return err } continue </ins> } obj, err := resource.NewHelper(info.Client, info.Mapping).Patch(info.Namespace, info.Name, types.StrategicMergePatchType, patch.Patch)

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: my yaml: exec kubectl set resources command,just update first object: 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cli
/kind bug
/assign
Change:
expectNoError(err) expectNoError(expectedServicesExist(c)) // TODO: Wait for all pods and services to be running. <del> kubeMasterHttpClient, ok := c.Client.(*http.Client) if !ok { Failf("failed to get master http client") } proxyUrl := fmt.Sprintf("%s/api/v1/proxy/namespaces/%s/services/%s:api/", getMasterHost(), api.NamespaceSystem, influxdbService) config := &influxdb.ClientConfig{ Host: proxyUrl, // TODO(vishh): Infer username and pw from the Pod spec. Username:   influxdbUser, Password:   influxdbPW, Database:   influxdbDatabaseName, HttpClient: kubeMasterHttpClient, IsSecure:   true, } influxdbClient, err := influxdb.NewClient(config) </del> <ins> influxdbClient, err := getInfluxdbClient(c) </ins> expectNoError(err, "failed to create influxdb client") expectedNodes, err := getAllNodesInCluster(c)

Discussion:
Jenkins project: kubernetes-e2e-gce-autoscaling failed last couple of runs: Initial Resources [Skipped][Autoscaling Suite] should set initial resources based on historical data Expected <int64: to be ~ <int:
couple failing instances:
Re-opening. This flaked again:
status?
The test is disabled and there is no plan to enable it within next few weeks, so closing the issue and I'll back to it some time in the future.
Change:
// Prepare resources allocated by the Dynammic Resource Allocation feature for the pod if utilfeature.DefaultFeatureGate.Enabled(features.DynamicResourceAllocation) { <del> if m.runtimeHelper.PrepareDynamicResources(pod) != nil { </del> <ins> if err := m.runtimeHelper.PrepareDynamicResources(pod); err != nil { ref, referr := ref.GetReference(legacyscheme.Scheme, pod) if referr != nil { klog.ErrorS(referr, "Couldn't make a ref to pod", "pod", klog.KObj(pod)) return } m.recorder.Eventf(ref, v1.EventTypeWarning, events.FailedPrepareDynamicResources, "Failed to prepare dynamic resources: %v", err) klog.ErrorS(err, "Failed to prepare dynamic resources", "pod", klog.KObj(pod)) </ins> return } }

Discussion:
When API fails there is no way to understand what happens because error is not reported. Error should be either logged or, better event should be recorded, so user would see it in the output. this patch to the kubernetes sources: a pod: the pod details: is not mentioning why pod is in pending state. No response <details</details<detailslocal </details<details</details<details</details<details</details<details</details
/sig node
/assign /cc
Logging is not enough, users don't have access to kubelet logs. Let's generate an event. I don't know whether we should have a well-defined condition for this. Thoughts anyone?
+1 on a condition.
From
In I am proposing as new pod condition.
/triage accepted /priority important-soon Is it a bug or a feature? Will it be tracked as a part of the enhancement work? If so we can close this one
/cc
/cc
Can you explain why do you prefer a condition over an event?
Depends on expectations :sweatsmile: The : . I expected this to be done already as part of the initial implementation, which would make this a bug. But one can also argue that this particular part had been deferred until later, which makes this a feature. We are using separate issues to track individual aspects of the enhancement work, so let's keep this open. Let's focus on adding the event in this issue and discuss the condition in
Change:
reconcilerLoopPeriod, maxWaitForUnmountDuration, dsw, asw, ad, nsu) // Act <del> go reconciler.Run(wait.NeverStop) </del> <ins> ch := make(chan struct{}) go reconciler.Run(ch) defer close(ch) </ins> // Assert waitForNewAttacherCallCount(t, 0 /* expectedCallCount */, fakePlugin)

Discussion:
Looks like similar issue with
That's the PV controller this is the attach controller, thus separate issues.
Change:
framework.ExpectNoError(err) }) <del> ginkgo.It("should manage the lifecycle of a ControllerRevision", func() { </del> <ins> /* Release: v1.25 Testname: ControllerRevision, resource lifecycle Description: Creating a DaemonSet MUST succeed. Listing all ControllerRevisions with a label selector MUST find only one. After patching the ControllerRevision with a new label, the label MUST be found. Creating a new ControllerRevision for the DaemonSet MUST succeed. Listing the ControllerRevisions by label selector MUST find only two. Deleting a ControllerRevision MUST succeed. Listing the ControllerRevisions by label selector MUST find only one. After updating the ControllerRevision with a new label, the label MUST be found. Patching the DaemonSet MUST succeed. Listing the ControllerRevisions by label selector MUST find only two. Deleting a collection of ControllerRevision via a label selector MUST succeed. Listing the ControllerRevisions by label selector MUST find only one. The current ControllerRevision revision MUST be 3. */ framework.ConformanceIt("should manage the lifecycle of a ControllerRevision", func() { </ins> csAppsV1 := f.ClientSet.AppsV1() dsLabel := map[string]string{"daemonset-name": dsName}

Discussion:
[X] Test approval issue: [X] Test PR: 8 Jul 2022 [x] Two weeks soak end date: 22 Jul 2022 [x] Test promotion PR: According to this APIsnoop query, there are still some remaining Controller Revision endpoints which are untested. listAppsV1ControllerRevisionForAllNamespacesreadAppsV1NamespacedControllerRevisionpatchAppsV1NamespacedControllerRevisioncreateAppsV1NamespacedControllerRevisiondeleteAppsV1NamespacedControllerRevisionreplaceAppsV1NamespacedControllerRevisiondeleteAppsV1CollectionNamespacedControllerRevision Using a number of existing e2e test practices a new has been created for 7 ControllerRevision endpoints. The e2e logs for this test are listed below. This query shows the following 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 7 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
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
Change:
} //Replace will create a resource if it doesn't exist already, so ignore not found error ignoreNotFound := true <ins> timeout := cmdutil.GetFlagDuration(cmd, "timeout") </ins> // By default use a reaper to delete all related resources. if cmdutil.GetFlagBool(cmd, "cascade") { glog.Warningf(""cascade" is set, kubectl will delete and re-create all resources managed by this resource (e.g. Pods created by a ReplicationController). Consider using "kubectl rolling-update" if you want to update a ReplicationController together with its Pods.") <del> err = ReapResult(r, f, out, cmdutil.GetFlagBool(cmd, "cascade"), ignoreNotFound, cmdutil.GetFlagDuration(cmd, "timeout"), cmdutil.GetFlagInt(cmd, "grace-period"), shortOutput, mapper, false) </del> <ins> err = ReapResult(r, f, out, cmdutil.GetFlagBool(cmd, "cascade"), ignoreNotFound, timeout, cmdutil.GetFlagInt(cmd, "grace-period"), shortOutput, mapper, false) </ins> } else { err = DeleteResult(r, out, ignoreNotFound, shortOutput, mapper) }

Discussion:
When replacing an existing pod, the command fails as it tries to create a pod with a name that is still used by terminating pod. How does the option works? deletes a pod (e.g. mypod) creates a new pod with the same name (mypod) What happens? As the command tries to recreate the pod, it fails as the is in state. Thus it can not be created. The problem is the does not wait for a pod to be deleted. Reproducer: run mypod --image=yapei/hello-openshift --generator=run-pod/v1 get pod mypod -o yaml replace -f --force The last command ends with:
option introduce by
With set to positive value, what should be the default behaviour of the command? When set to , should the command hang for and then create the pod? Or is there a way to create a callback (inside a scheduler?) that creates the pod once the current one is deleted?
You could watch for the resource to be deleted and create after you see the deletion happen
have you ever tried to set , I think this will do a non graceful deletion. should make sure the old resource is deleted before it creates a new resource, if not, that's a bug.
Though the help says the is to be used only with , it returns the error above.
Then I think there are two issues we need to track: 1. option should be ignored or just returns error if users are not using option. 2. should always make sure the old resource has been deleted before create the new resource.