jiebi/CodeConvo huggingface dataset:
Change:
} } <del> // StatefulSetHasDesiredReplicas returns a conditon that checks the number of statefulset replicas </del> <ins> // StatefulSetHasDesiredReplicas returns a condition that checks the number of StatefulSet replicas </ins> func StatefulSetHasDesiredReplicas(ssClient appsclient.StatefulSetsGetter, ss *apps.StatefulSet) wait.ConditionFunc { <del> // TODO: Differentiate between 0 statefulset pods and a really quick scale down using generation. </del> <ins> // If we're given a StatefulSet where the status lags the spec, it either means that the // StatefulSet is stale, or that the StatefulSet manager hasn't noticed the update yet. // Polling status.Replicas is not safe in the latter case. desiredGeneration := ss.Generation </ins> return func() (bool, error) { ss, err := ssClient.StatefulSets(ss.Namespace).Get(ss.Name, metav1.GetOptions{}) if err != nil { return false, err } <del> return ss.Status.Replicas == ss.Spec.Replicas, nil </del> <ins> // There's a chance a concurrent update modifies the Spec.Replicas causing this check to // pass, or, after this check has passed, a modification causes the StatefulSet manager to // create more pods. This will not be an issue once we've implemented graceful delete for // StatefulSet, but till then concurrent stop operations on the same StatefulSet might have // unintended side effects. return ss.Status.ObservedGeneration != nil && *ss.Status.ObservedGeneration >= desiredGeneration && ss.Status.Replicas == ss.Spec.Replicas, nil </ins> } }

Discussion:
StatefulSet now as of 1.6. That means the TODO on can be fixed in 1.7. We could not fix it in 1.6 because that code is used by kubectl, which must work against servers that are one minor version ahead of or behind the client.
/cc
I am volunteered to take this job if no one start working on this.
I don't think anyone's working on it, so you are welcome to take it. Feel free to tag me as a reviewer. Thanks!
Change:
return false, err } _, err = vs.InstanceID(ctx, convertToK8sType(nodeName)) <del> if err == nil { return true, nil </del> <ins> if err != nil { if err == cloudprovider.InstanceNotFound { return false, nil } return false, err </ins> } <del> return false, err </del> <ins> return true, nil </ins> } // InstanceShutdownByProviderID returns true if the instance is in safe state to detach volumes

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: We have k8s cluster with version . And I noticed that if I deleted worker node VM from IAAS, then node stuck in state, I created statefulset before and the pod scheduled on that node was stuck in state, and no new pod was created to replace that. Node should be deleted if no instance is found Related log When I check the log of I could see following log keeps popping up. Looks like node_controller noticed that the VM is gone but it doesn't delete the node. Related code here will return if no instance is found. But it should check if it's VM is deleted not shutdown, then return And it should cherry pick this fix avoiding deleting shutdown node What you expected to happen: After VM is deleted, the node should be deleted, pods assigned to the node should be rescheduled to other available nodes How to reproduce it (as minimally and precisely as possible): k8s cluster. In our case we use PKS. workloads on node worker node VM from IAAS Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: vSphere Cloud Provider
/sig cloud-provider /sig vmware
Same issue as this one The issue and is cluster API repo. We should fix it inside node_controller in k/k
Hi this issue was found when testing windows cluster deployed using PKS. We do have a workaround by manually deleting node using kubectl. Still we wish the fix could go in ASAP. Could you ask someone from upstream to to review the PR that fix this issue? Thank you
, we will try to push this through for v1.20. 1.19 is approaching code thaw, so we can't push this through
Thanks Michael. I'll let my team know.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Change:
proxy := httputil.NewSingleHostReverseProxy(&url.URL{Scheme: h.Location.Scheme, Host: h.Location.Host}) proxy.Transport = h.Transport proxy.FlushInterval = h.FlushInterval <del> proxy.ServeHTTP(maybeWrapFlushHeadersWriter(w), newReq) } // maybeWrapFlushHeadersWriter wraps the given writer to force flushing headers prior to writing the response body. // if the given writer does not support http.Flusher, http.Hijacker, and http.CloseNotifier, the original writer is returned. // TODO(liggitt): drop this once https://github.com/golang/go/issues/31125 is fixed func maybeWrapFlushHeadersWriter(w http.ResponseWriter) http.ResponseWriter { flusher, isFlusher := w.(http.Flusher) hijacker, isHijacker := w.(http.Hijacker) closeNotifier, isCloseNotifier := w.(http.CloseNotifier) // flusher, hijacker, and closeNotifier are all used by the ReverseProxy implementation. // if the given writer can't support all three, return the original writer. if !isFlusher || !isHijacker || !isCloseNotifier { return w } return &flushHeadersWriter{w, flusher, hijacker, closeNotifier} } type flushHeadersWriter struct { http.ResponseWriter http.Flusher http.Hijacker http.CloseNotifier } func (w *flushHeadersWriter) WriteHeader(code int) { w.ResponseWriter.WriteHeader(code) w.Flusher.Flush() </del> <ins> proxy.ServeHTTP(w, newReq) </ins> } // tryUpgrade returns true if the request was handled.

Discussion:
The workaround in should be removed (but the test kept to prevent regressions) once we upgrade to go 1.12.2 and pick up /assign
Thanks Liggitt
/sig api-machinery
removed in
Change:
t.Fatalf("expected one pod to be unmanaged pod but found %d", len(unmanagedPods)) } ps.VerifyNoStatusError(t, pdbName) <ins> verifyUnsupportedControllerEventEmitted(t, dc) </ins> } // Verify that we count the scale of a ReplicaSet even when it has no Deployment.

Discussion:
When using PDBs with or (percentage), it is not supported to reference pods via a PDB selector, that do not have a supported controller owner reference: Deployment, ReplicationController, ReplicaSet, and StatefulSet controllers or a resource implementing subresource This is also documented Nevertheless, there are still people who create PDBs a pods without controllers that ignore this. For example PDBs that set , want to block eviction, and node drain (it works for them but the PDB status is invalid). Unfortunately there is no feedback for the user to receive when this happens. The KCM logs is the only place that informs the user when unmanaged pods are found. Which I think is insufficient. There should be some way to inform users about this. Since it cannot be know on admission we probably have to do it when reconciling the PDB and unmanaged pods are found. Options: an event when this is detected - probably needs to be throttled in some way a condition in a PDB status that would be set and admins could monitor these to detect misbehaving PDBs create a PDB create unmanaged pod observe incorrect status because this configuration is unsupported No response <detailsNA </details<detailsNA </details<detailsNA </details<details</details<details</details<details</details
/sig apps
/triage accepted This was discussed during today's sig-apps, we've agreed to add a warning event right next to the log statement from the original description
I'll take this on.
/assign
/reopen I did some more testing for the unsupported controllers and found out that these are covered by the event, so I posted a followup to reflect that The new event should cover only the naked pods
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:
// Write creates or overwrites the contents of the version.txt file with the given EtcdVersionPair. func (v *VersionFile) Write(vp *EtcdVersionPair) error { <del> data := []byte(fmt.Sprintf("%s/%s", vp.version, vp.storageVersion)) return ioutil.WriteFile(v.path, data, 0666) </del> <ins> // We do write + rename instead of just write to protect from version.txt // corruption under full disk condition. // See https://github.com/kubernetes/kubernetes/issues/98989. err := ioutil.WriteFile(v.nextPath(), []byte(vp.String()), 0666) if err != nil { return fmt.Errorf("failed to write new version file %s: %v", v.nextPath(), err) } return os.Rename(v.nextPath(), v.path) </ins> } func exists(path string) (bool, error) {

Discussion:
file was found 'empty'. It blocked running etcd in a fail loop with Before this issue: Data disk (etcd) run out of space due to . .txt be not corrupted. It should be updated: only when needed (infrequently) safely (rename swap or writing on pre-allocated space) migrator script that runs etcd in case of the file not being found. Use whole space of etcd data disk and restart migrator+etcd when concurrent process is disk hungry. Requires changes of this logic: This logic (file write) should not trigger if the minor version matches: The write itself: should be defensive: Please notice that truncates file before writingKubernetes version: 1.18 Cloud provider or hardware configuration: GCE
/sig api-machinery
/assign /triage accepted
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale /lifecycle frozen
Change:
numVolumes++ allErrs = append(allErrs, validateAzureFile(pv.Spec.AzureFile, specPath.Child("azureFile"))...) } <ins> if pv.Spec.VsphereVolume != nil { if numVolumes > 0 { allErrs = append(allErrs, field.Forbidden(specPath.Child("vsphereVolume"), "may not specify more than 1 volume type")) } else { numVolumes++ allErrs = append(allErrs, validateVsphereVolumeSource(pv.Spec.VsphereVolume, specPath.Child("vsphereVolume"))...) } } </ins> if numVolumes == 0 { allErrs = append(allErrs, field.Required(specPath, "must specify a volume type")) }

Discussion:
vSphere volume spec fails with the following error, as its not been in api/validation. "spec.volumes[0]: Required value: must specify a volume type" Fixed in PR
Change:
"errors" "net" "reflect" <ins> "strings" </ins> "sync" "time"

Discussion:
NodeController is unable to register the value of , because it contains mixed case from the OS (in this case OSX). I'm not positive that all Linux systems are guaranteed to lowercase hostname -f, but it's likely that automated processes may end up collecting hostnames from sources that preserve case and passing that to the kubelet or master. I believe we should lowercase names detected from hostname -f and the values the node controller users - it's a minor thing, but internally we can guarantee that we treat node names as insensitive and in their canonical interior form.
cc
I'll take a look tmr.
Change:
cmd.Flags().Set("output", defaultOutputFormat) options.Merge.Default(true) <del> cmd.Flags().Var(&options.Merge, "merge", "merge together the full hierarchy of kubeconfig files") </del> <ins> f := cmd.Flags().VarPF(&options.Merge, "merge", "", "merge together the full hierarchy of kubeconfig files") f.NoOptDefVal = "true" </ins> cmd.Flags().BoolVar(&options.RawByteData, "raw", false, "display raw byte data") cmd.Flags().BoolVar(&options.Flatten, "flatten", false, "flatten the resulting kubeconfig file into self contained output (useful for creating portable kubeconfig files)") cmd.Flags().BoolVar(&options.Minify, "minify", false, "remove all information not used by current-context from the output")

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:
buildBackOffDuration = time.Minute syncLoopFrequency    = 10 * time.Second maxBackOffTolerance  = time.Duration(1.3 * float64(kubelet.MaxContainerBackOff)) <ins> podRetryPeriod       = 1 * time.Second podRetryTimeout      = 1 * time.Minute </ins> ) // testHostIP tests that a pod gets a host IP

Discussion:
[x] Original approval issue: 09 July 2020 [x] Two weeks soak end date: 24 July 2020 This issue is created to allow edit by /wip /hold According to this APIsnoop query, there are still an endpoint which is untested. a set of 3 Pods with a static label within a Namespace. that all 3 Pods with the label in the Namespace are created. the set of Namespaced Pods with a label via DeleteCollection. that all Pods with the label have been deleted. Discover useragents: List endpoints hit by the test: Display endpoint coverage change: Two other endpoints tested here have tests in progress to conformance already. If a test with these calls gets merged, test coverage will go up by 1 points This test is also created with the goal of conformance promotion.
/sig testing /sig architecture /area conformance
During Conformance Meeting: Is there a way to write this test so it is resource agnostic? If we are just changing the resource... can be parameterize the resource-type
/assign
GitHub didn't allow me to assign the following users: heyste. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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
Test to be created using "Polling" and not "Watch tooling"
/reopen Merged Issue open, waiting for Promotion PR
Reopened this issue. <detailsIn response to : /reopen Merged Issue open, waiting for Promotion PR 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 node
The test appears to be flaking, need to reach out to #sig-node for some feedback.
Can you point us to the link of the flaky tests? Thanks!
The Promotion The testgrid Thank you!
Change:
EXTRA_DOCKER_OPTS="${EXTRA_DOCKER_OPTS:-}" VOLUME_PLUGIN_DIR="${VOLUME_PLUGIN_DIR:-/home/kubernetes/flexvolume}" <del> REMOUNT_VOLUME_PLUGIN_DIR="${REMOUNT_VOLUME_PLUGIN_DIR:-true}" </del> SERVICE_CLUSTER_IP_RANGE="${SERVICE_CLUSTER_IP_RANGE:-10.0.0.0/16}"  # formerly PORTAL_NET ALLOCATE_NODE_CIDRS=true

Discussion:
/kind bug https://k8s- This is likely caused by a missing REMOUNTVOLUMEPLUGIN_DIR flag in kube-env construction. /assign /sig storage
xref /priority failing-test /priority critical-urgent any update on this one?
/status approved-for-milestone
I'm aware of the solution, but I'm trying to understand how to limit the scope of the change to just COS images, instead of all VM distros.
xref
Fix submitted, awaiting review:
PR approved; awaiting 1.10 milestone marker
/status in-progress
You must be a member of the github team to add status labels.
/status in-progress
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action Required: This issue has not been updated since Mar 11. Please provide an update. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
"strings" "testing" <ins> metainternalversion "k8s.io/apimachinery/pkg/apis/meta/internalversion" "k8s.io/apimachinery/pkg/fields" "k8s.io/apimachinery/pkg/labels" </ins> "net/http" "net/url" "time"

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: tried to get listing of all componentstatuses using a labelSelector query selector. I am hitting the apiServer directly. GET /api/v1/componentstatuses What you expected to happen: GET /api/v1/componentstatuses with labelSelector should limit responses to only componentstatuses with the specified label How to reproduce it (as minimally and precisely as possible): run GET /api/v1/componentstatuses with and without a labelSelector against the apiServer. Anything else we need to know?: specifically my label selector is in the form . and i can confirm everything works as expected when i hit GET /api/v1/pods Environment: Kubernetes version (use ): Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.6+IKS", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-05-09T13:26:51Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: IBM OS (e.g: ): Mac Kernel (e.g. ): Darwin Kernel Version 18.5.0 Install tools: Using javascript npm request to talk to api server Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
i assume its because you cant add a label to componentstatus, but they still shouldnt return if i specify a labelSelector
that's indeed a bug i presume. but what use-case makes you label-querying componentstatus?
we have a bot to periodically run a query that finds all known endpoints on the ApiServer. Then for each of the found endpoints, find all resources with our label defined. sort of an inventory tracking system.
in a similar vein, the endpoint doesnt seem to respect
/priority backlog /help
This request has been marked as needing help from a contributor. 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 : /priority backlog /help 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
I will take a look at this unless no objections
thank you, yours!
a PR for the ComponentStatus API, could you pls kindly take a look? I will look into the metrics API probably over the weekend. Thanks
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Change:
dc.sync(ctx, pdbName) ps.VerifyDisruptionAllowed(t, pdbName, 0) <ins> verifyUnsupportedControllerEventEmitted(t, dc) </ins> } // Verify that an integer MaxUnavailable will recompute allowed disruptions when the scale of

Discussion:
When using PDBs with or (percentage), it is not supported to reference pods via a PDB selector, that do not have a supported controller owner reference: Deployment, ReplicationController, ReplicaSet, and StatefulSet controllers or a resource implementing subresource This is also documented Nevertheless, there are still people who create PDBs a pods without controllers that ignore this. For example PDBs that set , want to block eviction, and node drain (it works for them but the PDB status is invalid). Unfortunately there is no feedback for the user to receive when this happens. The KCM logs is the only place that informs the user when unmanaged pods are found. Which I think is insufficient. There should be some way to inform users about this. Since it cannot be know on admission we probably have to do it when reconciling the PDB and unmanaged pods are found. Options: an event when this is detected - probably needs to be throttled in some way a condition in a PDB status that would be set and admins could monitor these to detect misbehaving PDBs create a PDB create unmanaged pod observe incorrect status because this configuration is unsupported No response <detailsNA </details<detailsNA </details<detailsNA </details<details</details<details</details<details</details
/sig apps
/triage accepted This was discussed during today's sig-apps, we've agreed to add a warning event right next to the log statement from the original description
I'll take this on.
/assign
/reopen I did some more testing for the unsupported controllers and found out that these are covered by the event, so I posted a followup to reflect that The new event should cover only the naked pods
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