jiebi/CodeConvo huggingface dataset:
Change:
glog.Errorf("Unable to extract field %s: %s", fileInfo.ResourceFieldRef.Resource, err.Error()) errlist = append(errlist, err) } else { <del> fileProjection.Data = []byte(sortLines(values)) </del> <ins> fileProjection.Data = []byte(values) </ins> } }

Discussion:
/kind bug What happened: When using the downward api to render a file via a volume mount from and annotation that has newlines in it, it appears that the file is rendered with the content sorted by line. A concrete example: Expected is that would contain But it does not The above is obviously contrived, this is creating a problem for my team when we are trying to use the downward api to render a yaml file (which obviously has newlines) Environment: Kubernetes version (use ): 1.9.7 Cloud provider or hardware configuration: aws OS (e.g. from /etc/os-release): centos
/sig apps Not sure about the sig here
/sig node /sig storage
Just tested it on 1.10.5 and this bug still happens.
thanks!
Change:
{ description: "ready sandboxes without containers for deleted pods should not be garbage collected.", sandboxes: []sandboxTemplate{ <del> makeGCSandbox(pods[2], 0, runtimeapi.PodSandboxState_SANDBOX_READY, false), </del> <ins> makeGCSandbox(pods[2], 0, runtimeapi.PodSandboxState_SANDBOX_READY, false, 0), </ins> }, containers: []containerTemplate{}, remain:     []int{0},

Discussion:
kubernetes pre-submit unit tests for pass some times and fails some times causing the flakiness. Here is one such failure https://k8s- Passing: Failing: cc
Yep, I'm checking with this
Sorry for introducing a flakiness. Sent out the fix in .
/assign
Dup of . /close

https://k8s- Failed: TestSandboxGC {kuberuntime}
https://k8s- Failed: TestSandboxGC {kuberuntime}
/assign
Should've been fixed by
Change:
if plugin, ok := inTreePlugins[driverName]; ok { return plugin.RepairVolumeHandle(volumeHandle, nodeID) } <del> return "", fmt.Errorf("could not find In-Tree driver name for CSI plugin %v", driverName) </del> <ins> return "", fmt.Errorf("could not find In-Tree driver name for CSI plugin %s", driverName) </ins> }

Discussion:
I noticed that kube-controller-manager is consuming visible amount of CPU in completely idle 5k node cluster (~7 cores/s) while for comparison kube-apiserver was using much less that time. I fetched pprof and noticed that we are burning significant in metrics.(attachDetachStateCollector).CollectWithStability:! Going further, most of the cpu is used for fmt.Errorf for formatting v1.Volume in line 160: which is never actually used by the caller We do not use significant cpu for preparing error messages that are then ignored. pprof cluster with some pods and volumes. No response_ <details26.1 </details<detailsgke, any? </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
A trivial fix would be actually to change GetInTreePluginNameFromSpec to write only PV/Volume names instead of entire specs in error message.
/assign In scheduler we use this function to check if we can translate the in-tree PV to CSI, I think we also only need the name of the pv. I'll create a pr for this one line change.
/sig storage Instrumentation ?
Change:
return } <ins> request := fmt.Sprintf("register?host=%s", getIP(hostPort).String()) log.Printf("Registering to master: %s/%s", hostPort, request) </ins> start := time.Now() for time.Since(start) < timeout { <del> response, err := dialHTTP("register", hostPort) </del> <ins> response, err := dialHTTP(request, hostPort) </ins> if err != nil { log.Printf("encountered error while registering to master: %v. Retrying in 1 second.", err) time.Sleep(sleep)

Discussion:
Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Check Anything else we need to know: /cc /cc /sig cli /sig network /sig api-machinery /sig windows /priority critical-urgent /milestone v1.17
The label(s) cannot be applied. These labels are supported: <detailsIn response to : Which jobs are failing: Since when has it been failing: Testgrid link: Example: /cc /cc /sig network /sig api-machinery] /sig windows /milestone v1.17 </details
The label(s) cannot be applied. These labels are supported: <detailsIn response to : Which jobs are failing: Since when has it been failing: Testgrid link: Check /cc /cc /sig network /sig api-machinery] /sig windows /milestone v1.17 </details
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
The following have been fixed: For the DNS + Services tests, the issue is caused by: Bug report here: Disabling EndpointSlice feature-gate on kube-proxy should be enough to get them green again.
/cc
is back to just the guestbook test being solid red (tracked in ) 17 should green up similarly (was just fast-forwarded this morning)
This seems resolved. can we close this?
/close
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
Change:
t.Errorf("Expected %v, but got %v", e, a) } <ins> // Test a simple id (using second ip). location, _, err = redirector.ResourceLocation(ctx, "foo-second-ip") if err != nil { t.Errorf("Unexpected error: %v", err) } if location == nil { t.Errorf("Unexpected nil: %v", location) } if e, a := "//[2001:db7::]:80", location.String(); e != a { t.Errorf("Expected %v, but got %v", e, a) } </ins> // Test a name + port. location, _, err = redirector.ResourceLocation(ctx, "foo:p") if err != nil {

Discussion:
Hi, I have a issue with a dualstack cluster for my Kubernetes Dashboard deployment. I opened a ticket here (), but I am informed that it is not related to Kubernetes Dashboard. What is the problem? Errors in kube-api: The service is created with the correct ipFamily (=IPv6). My endpoint is fully in IPv6. Indeed, my pod has one IP in IPv4 and another in IPv6. Do you have also the issue? Kubernetes version: 1.18 OS: RHEL7
/sig network /sig api-machinery
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
I think the following should fix the error you saw:
/remove-sig api-machinery
Change:
}, []string{"result"}) <ins> CacheSize = metrics.NewGaugeVec( &metrics.GaugeOpts{ Subsystem:      SchedulerSubsystem, Name:           "scheduler_cache_size", Help:           "Number of nodes, pods, and assumed (bound) pods in the scheduler cache.", StabilityLevel: metrics.ALPHA, }, []string{"type"}) </ins> metricsList = []metrics.Registerable{ scheduleAttempts, SchedulingLatency,

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add a metric to track scheduler cache size. metric name Description -- -- schedulercachesize Number of elements in scheduler cache. Why is this needed: Gives better observability of scheduler cache. For, the number of "assumedpods" gives us an idea of how many pods are "assumed" and therefore being "bound". We can compare this with number of to make sure assume-bind works as expected. /sig scheduling
Is anyone already working on these metrics? If not I'd like to help out /assign
Thanks . Feel free to work on this one. Just a reminder, we may need feedback/approval from sig-instrumentation.
Change:
"$ref": "#/definitions/intstr.IntOrString" }, "maxUnavailable": { <del> "description": "The maximum number of pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). Absolute number is calculated from percentage by rounding up. This can not be 0 if MaxSurge is 0. By default, a fixed value of 1 is used. Example: when this is set to 30%, the old RC can be scaled down to 70% of desired pods immediately when the rolling update starts. Once new pods are ready, old RC can be scaled down further, followed by scaling up the new RC, ensuring that the total number of pods available at all times during the update is at least 70% of desired pods.", </del> <ins> "description": "The maximum number of pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). Absolute number is calculated from percentage by rounding down. This can not be 0 if MaxSurge is 0. By default, a fixed value of 1 is used. Example: when this is set to 30%, the old RC can be scaled down to 70% of desired pods immediately when the rolling update starts. Once new pods are ready, old RC can be scaled down further, followed by scaling up the new RC, ensuring that the total number of pods available at all times during the update is at least 70% of desired pods.", </ins> "$ref": "#/definitions/intstr.IntOrString" } }

Discussion:
API documentation says is rounded up, but it is actually rounded down: The code shows it is rounded down, not up: and
Yes, the documentation is obsolete. We changed maxUnavailable to round down so that we wouldn't accidentally infer 100% unavailability for non-100 percentages. For example, maxSurge=25% and maxUanavailable=25% with a Deployment of 1 replica meant that we could scale down 1 before thus leading in 100% maxUnavailable (implicit).
Change:
# KUBE_RACE="-race" make -C "${KUBE_ROOT}" test  WHAT="${WHAT:-$(kube::test::find_integration_test_dirs | paste -sd' ' -)}"  <del> KUBE_GOFLAGS="${KUBE_GOFLAGS:-}"  </del> <ins> GOFLAGS="${GOFLAGS:-}"  </ins> KUBE_TEST_ARGS="${KUBE_TEST_ARGS:-} ${SHORT:--short=true} --vmodule=garbage*collector*=6 --alsologtostderr=true"  KUBE_RACE=""  KUBE_TIMEOUT="${KUBE_TIMEOUT}" 

Discussion:
We should just use GOFLAGS
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig contributor-experience
/assign
Change:
logger.V(4).Info(log("calling NodePrepareResources rpc"), "request", req) defer logger.V(4).Info(log("done calling NodePrepareResources rpc"), "response", resp, "err", err) <del> if r.nodeClientCreator == nil { return nil, errors.New("failed to call NodePrepareResources. nodeClientCreator is nil") } nodeClient, nodeClientOld, closer, err := r.nodeClientCreator(r.addr) </del> <ins> conn, err := r.plugin.getOrCreateGRPCConn() </ins> if err != nil { return nil, err } <del> defer closer.Close() </del> <ins> nodeClient := drapb.NewNodeClient(conn) nodeClientOld := drapbv1alpha2.NewNodeClient(conn) </ins> ctx, cancel := context.WithTimeout(ctx, PluginClientTimeout) defer cancel()

Discussion:
See comment for details:
/sig node
/area kubelet
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
/triage accepted
Change:
} eventBroadcaster := newBroadcaster(&testEvents, 0, map[eventKey]*eventsv1.Event{}) recorder := eventBroadcaster.NewRecorder(scheme.Scheme, "eventTest") <del> eventBroadcaster.StartRecordingToSink(stopCh) </del> <ins> broadcaster := eventBroadcaster.(*eventBroadcasterImpl) // Don't call StartRecordingToSink, as we don't need neither refreshing event // series nor finishing them in this tests and additional events updated would // race with our expected ones. broadcaster.startRecordingEvents(stopCh) </ins> recorder.Eventf(regarding, related, isomorphicEvent.Type, isomorphicEvent.Reason, isomorphicEvent.Action, isomorphicEvent.Note, []interface{}{1}) // read from the chan as this was needed only to populate the cache <-createEvent

Discussion:
Which jobs are flaking: periodic-kubernetes-bazel-test-master (xref ) Which test(s) are flaking: TestEventSeriesf Testgrid link: Reason for failure: Timeout: Anything else we need to know: To reproduce with stress: /cc
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
/assign
filed to address this issue.
contains the correct analysis of flakes (thanks a lot!), I commented on way of fixing it (which I'm not convinced about).
Change:
// where zone information is included on the nodes, it favors nodes // in zones with fewer existing matching pods. func (pl *DefaultPodTopologySpread) NormalizeScore(ctx context.Context, state *framework.CycleState, pod *v1.Pod, scores framework.NodeScoreList) *framework.Status { <ins> if skipDefaultPodTopologySpread(pod) { return nil } </ins> countsByZone := make(map[string]int64, 10) maxCountByZone := int64(0) maxCountByNodeName := int64(0)

Discussion:
Currently the scheduler by default spreads the pods of a deployment based on a hard-coded . We recently a pod object api (pod.Spec.TopologySpreadConstraints) that allows specifying spread behavior at the workload level. For pods that specify topology spread constraints, the default spreading behavior should not apply. /sig scheduling /cc
I can fix this behavior, can you assign it to me?
/assign sure, lets wait for feedback first.
sure, thanks
I agree. Having the default spreading run would just water down the score given by the constraints. Other than that, this would just be a temporary fix until is finalized
Change:
return spc.podsLister.Pods(set.Namespace).List(selector) } <del> func (spc *fakeStatefulPodControl) addTerminatedPod(set *apps.StatefulSet, ordinal int) ([]*v1.Pod, error) { </del> <ins> func (spc *fakeStatefulPodControl) addTerminatingPod(set *apps.StatefulSet, ordinal int) ([]*v1.Pod, error) { </ins> pod := newStatefulSetPod(set, ordinal) pod.Status.Phase = v1.PodRunning deleted := metav1.NewTime(time.Now())

Discussion:
/assign flakes in PR jobs more than once per day The can filter down to searching for results for a single test:
This test continues to flake PRs at least once per day:
https://k8s-
looking at it
Change:
// Enables a feature to make secrets and configmaps data immutable. ImmutableEphemeralVolumes featuregate.Feature = "ImmutableEphemeralVolumes" <del> // owner: @robscott // beta: v1.18 // ga: v1.19 // // Enables DefaultIngressClass admission controller. DefaultIngressClass featuregate.Feature = "DefaultIngressClass" </del> // owner: @bart0sh // alpha: v1.18 // beta: v1.19

Discussion:
When should it be removed? /sig network /kind cleanup
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
According to , it need to remove in 1.20. /assign
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
RegistryPullQPS:             -10, HairpinMode:                 "foo", NodeLeaseDurationSeconds:    -1, <del> CPUCFSQuotaPeriod:           metav1.Duration{Duration: 0}, </del> <ins> CPUCFSQuotaPeriod:           metav1.Duration{Duration: 100 * time.Millisecond}, </ins> } const numErrsErrorCase1 = 25 if allErrors := ValidateKubeletConfiguration(errorCase1); len(allErrors.(utilerrors.Aggregate).Errors()) != numErrsErrorCase1 {

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 --See for more context. What happened: When you set and , you'd expect container cfs quota period to be . However, unless you also set in the feature flags, the quota value will be silently ignored. What you expected to happen: At least a warning be logged if the feature is not enabled but is set. 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig node /assign karan
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig node 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:
# which are important for line counting. # Use trick from https://unix.stackexchange.com/a/383411 to avoid # newline truncation. <del> node=$(kubectl_retry get nodes --chunk-size=0 --no-headers; ret=$?; echo .; exit "$ret") && res="$?" || res="$?" </del> <ins> node=$(kubectl_retry get nodes --no-headers; ret=$?; echo .; exit "$ret") && res="$?" || res="$?" </ins> node="${node%.}" if [ "${res}" -ne "0" ]; then if [[ "${attempt}" -gt "${last_run:-$MAX_ATTEMPTS}" ]]; then

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: sig-scalability-gce/gce-scale-performance Which test(s) are failing: Up Since when has it been failing: since today Testgrid link: https://k8s- Reason for failure: Set-up scripts report only 500 nodes to be up, even though we see in api-server more nodes that registered
/sig scalability /assign
Looks like the pagination (controlled via --chunk-size) was enabled in kubectl. The default is 500 rows, which explains the behavior we see in the failing tests. I wasn't able to find the culprit PR, but found an easy fix. Will send a PR shortly
broke in , fixed in (with tests)
Ah, thanks, I thought could related, but it wasn't really obvious to me that it was the real culprit. Thanks for fixing, once gets merged we can revert
FYI, the temporary workaround seems to be working, the gce-scale-performance is running and not failing anymore on cluster creation -
Change:
importpath = "k8s.io/kubernetes/pkg/fieldpath", deps = [ "//staging/src/k8s.io/apimachinery/pkg/api/meta:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/validation:go_default_library", ], )

Discussion:
/kind bug What happened: When using the downward api to render a file via a volume mount from and annotation that has newlines in it, it appears that the file is rendered with the content sorted by line. A concrete example: Expected is that would contain But it does not The above is obviously contrived, this is creating a problem for my team when we are trying to use the downward api to render a yaml file (which obviously has newlines) Environment: Kubernetes version (use ): 1.9.7 Cloud provider or hardware configuration: aws OS (e.g. from /etc/os-release): centos
/sig apps Not sure about the sig here
/sig node /sig storage
Just tested it on 1.10.5 and this bug still happens.
thanks!
Change:
.PHONY:	build push <del> TAG = 1.0 </del> <ins> TAG = 1.1 </ins> build: sudo docker build -t kubernetes/fluentd-gcp:$(TAG) .

Discussion:
As Satnam mentioned in PR , our Fluentd pod tends to not collect the first chunk of logs from each container. I've noticed that it seems to miss different amounts of logs depending on how quickly the container generates them, so it may be a timing issue. cc
See
Change:
kind = ft.Kind() if !field.IsNil() { field = reflect.Indirect(field) <ins> // If the field is non-nil, it should be added to params // and the omitempty should be overwite to false omitempty = false </ins> } }

Discussion:
How works: : prints all lines. : prints the last line. : prints no lines. (Usually used with to follow new logs) How works: : prints all lines. : prints the last line. : prints all lines. <-------------- Diffierent. The reason is that the is ignored when converting the parameters Confirmed with What is the expected behavior? /cc
I've also noticed that even if or some arbitrarily low number is specified, it tries to read the whole logfile into memory. If it's a big file it can crash the worker node.
Do you mean the docker implementation? If I read their code correctly, docker read the whole log before tail into memory once tail is specified, which may cause problem if tail is a very large number. So in our own implementation, I've avoided that. ;) However, where do you see the ?
Tail should be *int in the API, is it not? On Oct 21, 2016, at 6:01 PM, Lantao Liu wrote: How docker logs works: docker logs --tail=-1 CONTAINERID: prints all lines. docker logs --tail=1 CONTAINERID: prints the last line. docker logs --tail=0 CONTAINERID: prints no lines. (Usually used with -f to follow new logs) How kubectl logs works: kubectl logs --tail=-1 PODNAME: prints all lines. kubectl logs --tail=1 PODNAME: prints the last line. kubectl logs --tail=0 PODNAME: prints all lines. <-------------- Diffierent. The reason is that the tail=0 is ignored when converting the parameters . Confirmed with /cc — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .
Agree tail=0 no logs is intended behavior On Oct 21, 2016, at 6:01 PM, Lantao Liu wrote: How docker logs works: docker logs --tail=-1 CONTAINERID: prints all lines. docker logs --tail=1 CONTAINERID: prints the last line. docker logs --tail=0 CONTAINERID: prints no lines. (Usually used with -f to follow new logs) How kubectl logs works: kubectl logs --tail=-1 PODNAME: prints all lines.

kubectl logs --tail=1 PODNAME: prints the last line. kubectl logs --tail=0 PODNAME: prints all lines. <-------------- Diffierent. The reason is that the tail=0 is ignored when converting the parameters . Confirmed with /cc — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .
Yeah, tail is . But if , kubelet will see .
I think the linked to is the problem.
The obvious workaround is to instead use: kubectl logs --tail=1
/sig cli
The line pasted by chao implies omitempty should not be false for tail.
I hate to bump, but 'bump'. Still an issue here. Can confirm works but does not.
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 This is still relevant.
Any good news?
Change:
function kube::release::package_full_tarball() { echo "+++ Building tarball: full" <del> local release_stage="${LOCAL_OUTPUT_ROOT}/release-stage/full/kubernetes" </del> <ins> local release_stage="${RELESAE_STAGE}/full/kubernetes" </ins> rm -rf "${release_stage}" mkdir -p "${release_stage}"

Discussion:
Sometimes it is nice to have non-tar'd binaries for releases. We should upload those along with the our packaged tarballs. This will help fix