jiebi/CodeConvo huggingface dataset:
Change:
"fmt" "math" "strings" <ins> "sync" </ins> "time"

Discussion:
What happened: I two CSI plugins to my Kubernetes cluster via a single call to . When I did this, the annotation was improperly set on 2 out of 3 nodes. Only one of the plugins appeared: What you expected to happen: Both and plugins should have appeared in the annotation. How to reproduce it (as minimally and precisely as possible): Apply two or more CSI plugins via a single call to . Anything else we need to know?: Kubelet logs indicate that it registered both plugins at the same time: The CSINode object looks complete: Only the node's annotation did not include Restarting kubelet fixed the issue. It looks like a race condition when InstallCSIDriver is called concurrently for multiple drivers. The code here: could lead to each thread observing the annotation as being empty, and then setting its own annotation that includes only itself. Environment: Kubernetes version (use ): v1.17.11 Cloud provider or hardware configuration: AWS OS (e.g: ): Ubuntu 20.04.1 LTS Kernel (e.g. ): Linux ip-172-31-17-163 5.4.0-1021-aws -Ubuntu SMP Fri Jul 24 09:42:29 UTC 2020 x8664 x8664 x86_64 GNU/Linux Install tools: juju
/sig storage
/assign
I can reproduce this issue with commands below ! The correct csi nodeid would be like this
Change:
framework.ExpectNoError(err) for _, pod := range pods.Items { _, found := nodeToCapacityMap[pod.Spec.NodeName] <del> if found && pod.Status.Phase == api.PodRunning { </del> <ins> if found && pod.Status.Phase != api.PodSucceeded && pod.Status.Phase != api.PodFailed { </ins> framework.Logf("Pod %v requesting resource cpu=%vm on Node %v", pod.Name, getRequestedCPU(pod), pod.Spec.NodeName) nodeToCapacityMap[pod.Spec.NodeName] -= getRequestedCPU(pod) }

Discussion:
https://k8s- Failed: [] SchedulerPredicates [Serial] validates resource limits of pods that are allowed to run [Conformance] {Kubernetes e2e suite}
- FYI
https://k8s- Failed: [] SchedulerPredicates [Serial] validates resource limits of pods that are allowed to run [Conformance] {Kubernetes e2e suite}
First failure is a dupe of . For second I need to wait for master logs.
Change:
--storage-backend=${STORAGE_BACKEND} --service-cluster-ip-range="${SERVICE_CLUSTER_IP_RANGE}" EOF <ins> if [ -z "${CUSTOM_ADMISSION_PLUGINS:-}"]; then cat >> "${RESOURCE_DIRECTORY}/apiserver_flags" <<EOF --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota EOF else cat >> "${RESOURCE_DIRECTORY}/apiserver_flags" <<EOF --admission-control=${CUSTOM_ADMISSION_PLUGINS} EOF fi </ins> sed -i'' -e "s/"//g" "${RESOURCE_DIRECTORY}/apiserver_flags" cat > "${RESOURCE_DIRECTORY}/scheduler_flags" <<EOF

Discussion:
Until is fixed (which won't happen before code-freeze is finished), kubemark-scale will be failing/timing-out and this is "working-as-intended" until then. It should be possible to switch off secrets in kubemark to make other problems debuggable. For now we would like to: switch off secrets in kubemark-scale leave them in all other kubemark suites
can you add a release-blocking or non-blocking label to this issue?
Is kubemark scale useful/realistic if it disables things that are required in actual deployments?
We use it for development, and we need a way to switch off particular parts.
- it's just a short term fix that would allow to fix/debug different problems at the same time (we already know that secrets are causing problems and we will be fixing it).
To clarify - I'm not going to leave that forever - as soon as we will have some fix for secrets in, we will enable it back in 5000-node kubemark. Currently because of secrets those tests doesn't bring any value.
Also - this one is already done.
Change:
configuration *atomic.Value lister        admissionregistrationlisters.ValidatingWebhookConfigurationLister hasSynced     func() bool <ins> // initialConfigurationSynced stores a boolean value, which tracks if // the existing webhook configs have been synced (honored) by the // manager at startup-- the informer has synced and either has no items // or has finished executing updateConfiguration() once. initialConfigurationSynced *atomic.Value </ins> } var _ generic.Source = &validatingWebhookConfigurationManager{}

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: pull-kubernetes-bazel-test Which test(s) are flaking: Testgrid link: Example pass: Example fail: Reason for failure: Unknown Anything else we need to know: Looks like it's an apiserver test, but I'm not too sure. links to appreciated: <!-- Please see the deflaking doc () for more guidance! --/kind flake
Looks like is flaky too. Example fail:
/sig api-machinery
Thanks for the report. Please report individual failing tests/packages so the responsible sigs can be assigned. The cm/devicemanager issue is tracked in
/assign
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
I don't see individual issues yet, but I do see open PRs targeting this issue /remove-lifecycle rotten
closing in favor of specific issues: /close
Closing this issue. <detailsIn response to : closing in favor of specific issues: 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:
// TODO consider printing more information about cluster } <del> func printService(out io.Writer, name, link string, warn bool) { </del> <ins> func printService(out io.Writer, name, link string) { </ins> ct.ChangeColor(ct.Green, false, ct.None, false) fmt.Fprint(out, name) ct.ResetColor()

Discussion:
Right now at the end of I get We should update the output to point to the appropriate v1beta3 URL endpoints instead.
/cc
Ref and . cc
And as a minor nit, not all of those URLs need a trailing slash hack e.g. I don't think it is required for Elasticsearch. I think most recently worked on this code?
Thanks for fixing this
Change:
} func TestNormalizeDesiredReplicasWithBehavior(t *testing.T) { <ins> now := time.Now() </ins> type TestCase struct { name                                string key                                 string

Discussion:
When configuring new behaviors section in HPA I two scenarios that I think are incorrect. First one: stabilizationWindowSeconds set up to 5 minutes for both scale up and scale down min replica count 2 Application consumes big amount of resources during warm-up 0 minute: current replica count: 2 1 minute: desired replica count: 3 - no scale up stabilization window worked 2 minute: desired replica count: 1 (!) - scale up to 3 (max number from previous recommendations during stabilization window period) ! Second one Stabilization window for scale up 0 Stabilization window for scale down 5 minutes min replica count 2 behavior set to scale up new pod in 2 minutes scaleUp: policies: type: Pods value: 1 periodSeconds: 120 What happens: 0 minute: 2 replicas 1 minute : performance spike scale up to 3 (desired value 4) 2 minute : no spike no scale up 3 minute: no spike scale up to 4(!) - supposedly desired value 1 and supposedly worked this way because of scale down window set to 5 minutes picking max value from that 5 minutes window that was 4 replicas Expected behaviors 1 Scenario no scale up for 5 minutes 2 Scenario correct measurement and no scale up when there is no need for it Environment: Kubernetes version (use ): client 1.19.3 Server 1.19.0 Cloud provider or hardware configuration: Azure aks
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
/sig autoscaling
/assign josephburnett
The HPA controller keeps a flat history of recommendations for stabilization. ! When downscale stabilizing the maximum recommendation is selected. Purple is pre-stabilized recommendation. Green is final recommendation. Blue is max recommendation within window. ! When upscale stabilization the minimum recommendation is selected. ! However when both up and down scale stabilization is configured, the interpretation of the history changes depending on the direction of movement.

Red is the undesired, actuated recommendation. ! What we want is to keep the stabilized recommendation within the envelope of the minimum and maximum over configured stabilization windows. We should only move when the envelope forces a move. ! We first stabilize up and down, and check if the current value fits within it. If it does (or the range is "inverted"), we do nothing. If it does not, we emit the "nearest possible" value, which will be lower or upper bound, depending on where the current size is in relation to the range. (thanks and for the paragraph above)
Change:
flags.StringVar(&TestContext.KubernetesAnywherePath, "kubernetes-anywhere-path", "/workspace/k8s.io/kubernetes-anywhere", "Which directory kubernetes-anywhere is installed to.") flags.BoolVar(&TestContext.ListImages, "list-images", false, "If true, will show list of images used for runnning tests.") <ins> flags.StringVar(&TestContext.KubectlPath, "kubectl-path", "kubectl", "The kubectl binary to use. For development, you might use 'cluster/kubectl.sh' here.") </ins> } // RegisterClusterFlags registers flags specific to the cluster e2e test suite.

Discussion:
Which jobs are failing: ci-kubernetes-node-kubelet-orphans Which test(s) are failing: [sig-storage] EmptyDir volumes pod should support shared volumes between containers Since when has it been failing: Testgrid link: Reason for failure:
/sig testing
/assign
Thank for comment
Tests are now passing, /close
Closing this issue. <detailsIn response to : Tests are now passing, 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:
framework.ExpectEqual(*podStats.CPU.UsageCoreNanoSeconds > 0, true, "Pod stats should not report 0 cpu usage") framework.ExpectEqual(*podStats.Memory.WorkingSetBytes > 0, true, "Pod stats should not report 0 bytes for memory working set ") <ins> framework.ExpectEqual(podStats.Network != nil, true, "Pod stats should report network stats") framework.ExpectEqual(podStats.Network.Name != "", true, "Pod stats should report network name") framework.ExpectEqual(*podStats.Network.TxBytes > 0, true, "Pod stats should report network Tx stats") framework.ExpectEqual(len(podStats.Network.Interfaces) > 0, true, "Pod Stats should report individual interfaces stats") </ins> for _, containerStats := range podStats.Containers { framework.ExpectEqual(containerStats.Logs != nil, true, "Pod stats should have container log stats") framework.ExpectEqual(*containerStats.Logs.AvailableBytes > 0, true, "container log stats should not report 0 bytes for AvailableBytes")

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 --When curling the endpoint for stats we don't see network stats. Network stats to be included when calling the summary. This works with dockershim for windows. This happens because Windows containerd uses hcsv2 to create containers and we query for the networks stats using hcsv1: This will be address eventually with move to CRI only metrics KEP: but is still several releases away. 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 windows /assign
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs 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 or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Change:
} } <del> func doTestPlugin(t *testing.T, spec *volume.Spec) { </del> <ins> func doTestPlugin(t *testing.T, spec *volume.Spec, expectedDevice string) { </ins> tmpDir, err := utiltesting.MkTmpdir("nfs_test") if err != nil { t.Fatalf("error creating temp dir: %v", err)

Discussion:
In bare-metal IPv6 environment, any pod consuming storage resource is not able to run. The storage should be consumable, and the pod should become in status. Running the in a bare-metal IPv6 configurations. I have replaced the cloud-based storage resource with a mounted to a folder on my localhost. Steps alongside logs are below :- $kubectl get svc $kubectl describe svc nfs-server $kubectl describe pv nfs $kubectl get pod -w $kubectl get pod -w $kubectl describe pod nfs-busybox-6r96h I have built the master branch to make sure it was not fixed up to this moment.
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
/sig storage
/sig storage /tirage accepted /assign
Change:
for feature, flag := range test.FeatureGates { defer featuregatetesting.SetFeatureGateDuringTest(b, utilfeature.DefaultFeatureGate, feature, flag)() } <del> perfScheduling(test, b) </del> <ins> dataItems.DataItems = append(dataItems.DataItems, perfScheduling(test, b)...) </ins> }) } <ins> if err := dataItems2JSONFile(dataItems, b.Name()); err != nil { klog.Fatalf("%v: unable to write measured data: %v", b.Name(), err) } </ins> } <del> func perfScheduling(test testCase, b *testing.B) { </del> <ins> func perfScheduling(test testCase, b *testing.B) []DataItem { </ins> var nodeStrategy testutils.PrepareNodeStrategy = &testutils.TrivialNodePrepareStrategy{} if test.Nodes.NodeAllocatableStrategy != nil { nodeStrategy = test.Nodes.NodeAllocatableStrategy

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We should allow collecting both default scheduler metrics (Prometheus) and custom metrics easily. At a high level, these collectors should produce a json formatted result which will then be consumed by perf-dash to present in the dashboard. Prometheus metrics We should provide a metrics collector that collects and summarizes default scheduler metrics defined in . To begin with, we can manually pick a list of interesting metrics. Longer term, we could allow configuring the metric list in test definition. already had a PoC . As a reference, is how clusterloader collects scheduler latency metrics. Custom metrics The most important metric is scheduling throughput. is how clusterloader calculates the throughput. We can start with just calculating the average throughput without the percentiles. We may want other custom metrics that are either common to all tests or specific to certain tests. We should allow these custom collectors to be easily and ideally configurable. Why is this needed: Give more insights into scheduler performance. Part of /sig scheduling /assign
/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:
- k8s.io/kubernetes/pkg/apis/core/helper - k8s.io/kubernetes/pkg/apis/core/install - k8s.io/kubernetes/pkg/apis/core/v1 <ins> - k8s.io/kubernetes/pkg/apis/discovery - k8s.io/kubernetes/pkg/apis/discovery/install - k8s.io/kubernetes/pkg/apis/discovery/v1alpha1 - k8s.io/kubernetes/pkg/apis/discovery/v1beta1 </ins> - k8s.io/kubernetes/pkg/apis/events - k8s.io/kubernetes/pkg/apis/events/install - k8s.io/kubernetes/pkg/apis/events/v1beta1 - k8s.io/kubernetes/pkg/apis/extensions - k8s.io/kubernetes/pkg/apis/extensions/install - k8s.io/kubernetes/pkg/apis/extensions/v1beta1 <ins> - k8s.io/kubernetes/pkg/apis/flowcontrol - k8s.io/kubernetes/pkg/apis/flowcontrol/install - k8s.io/kubernetes/pkg/apis/flowcontrol/v1alpha1 - k8s.io/kubernetes/pkg/apis/flowcontrol/v1beta1 - k8s.io/kubernetes/pkg/apis/imagepolicy - k8s.io/kubernetes/pkg/apis/imagepolicy/install - k8s.io/kubernetes/pkg/apis/imagepolicy/v1alpha1 </ins> - k8s.io/kubernetes/pkg/apis/networking <ins> - k8s.io/kubernetes/pkg/apis/node - k8s.io/kubernetes/pkg/apis/node/install - k8s.io/kubernetes/pkg/apis/node/v1 - k8s.io/kubernetes/pkg/apis/node/v1alpha1 - k8s.io/kubernetes/pkg/apis/node/v1beta1 </ins> - k8s.io/kubernetes/pkg/apis/policy - k8s.io/kubernetes/pkg/apis/policy/install - k8s.io/kubernetes/pkg/apis/policy/v1beta1

Discussion:
What happened: Tried to convert a v1beta1 Ingress object to v1, and received the following error: What you expected to happen: The conversion to work. How to reproduce it (as minimally and precisely as possible): Then run: /sig cli /assign
Can i work on this issue?
/assign
/triage accepted
Change:
// - The second one runs grep 'hello world' on /mnt/test. // If both succeed, Kubernetes actually allocated something that is // persistent across pods. <del> By("checking the created volume is writable") runInPodWithVolume(client, claim.Namespace, claim.Name, "echo 'hello world' > /mnt/test/data") </del> <ins> By("checking the created volume is writable and has the PV's mount options") command := "echo 'hello world' > /mnt/test/data" // We give the first pod the secondary responsibility of checking the volume has // been mounted with the PV's mount options, if the PV was provisioned with any for _, option := range pv.Spec.MountOptions { // Get entry, get mount options at 6th word, replace brackets with commas command += fmt.Sprintf(" && ( mount | grep 'on /mnt/test' | awk '{print $6}' | sed 's/^(/,/; s/)$/,/' | grep -q ,%s, )", option) } runInPodWithVolume(client, claim.Namespace, claim.Name, command) </ins> By("checking the created volume is readable and retains data") runInPodWithVolume(client, claim.Namespace, claim.Name, "grep 'hello world' /mnt/test/data")

Discussion:
for 1.8. /assign
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
/sig storage
Looking at the PR description, it seems that adds tests for ReclaimPolicy only. What about MountOptions?
those are coming also, I'll re-rename issue/point to another one
Since the feature is in 1.8, we need tests in 1.8. Adding this to 1.8 milestone.
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/storage: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/cleanup: Adding tests, refactoring, fixing old bugs. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
This issue is a 1.8 blocker. The PRs for to fix it, and , are approved/LGTM'd and awaiting merge. This issue can be closed as soon as those merge.
Change:
config.CurrentContext = o.contextName <del> if err := clientcmd.ModifyConfig(o.configAccess, *config, true); err != nil { return err } return nil </del> <ins> return clientcmd.ModifyConfig(o.configAccess, *config, true) </ins> } func (o *useContextOptions) complete(cmd *cobra.Command) error { endingArgs := cmd.Flags().Args() if len(endingArgs) != 1 { <del> cmd.Help() return fmt.Errorf("Unexpected args: %v", endingArgs) </del> <ins> return helpErrorf(cmd, "Unexpected args: %v", endingArgs) </ins> } o.contextName = endingArgs[0]

Discussion:
The '-context' does not seem to add any value
add priority and team please.
Blocked on
/sig cli
Change:
} if version == 0 { if !e.UpdateStrategy.AllowCreateOnUpdate() { <del> return nil, kubeerr.NewAlreadyExists(e.EndpointName, name) </del> <ins> return nil, kubeerr.NewNotFound(e.EndpointName, name) </ins> } creating = true if err := rest.BeforeCreate(e.CreateStrategy, ctx, obj); err != nil {

Discussion:
The use of AtomicUpdate by genericetcd doesn't handle conflicting writes by rejecting that to a user. It should. Eventually, we may want to hide write conflicts to /pods when status has changed, and to spec when /pods/status changes, but that requires us to have two version counters and that's not worth the effort. Fix incoming.
Also we need a unit/integration test for this.
Change:
runTopologyManagerNodeAlignmentSuiteTests(f, sd, reservedSystemCPUs, policy, numaNodes, coreCount) } <del> // restore kubelet config setOldKubeletConfig(f, oldCfg) // Delete state file to allow repeated runs deleteStateFile() </del> }) ginkgo.It("run the Topology Manager pod scope alignment test suite", func() {

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: ci-kubernetes-node-kubelet-serial node-kubelet-serial job Which test(s) are failing: Hard to tell, but everything at one point or another. Since when has it been failing: A month or two, by recollection. would indicate several years... ci-kubernetes-node-kubelet-serial | failing_days | 992 Testgrid link: Reason for failure: Hard to tell, some is timeout, but I think timeouts due to test failures. Anything else we need to know: Nothing consistent about the failures that I can tell besides timeouts. This is the only place these serial tests are running.
/sig node
/cc
I will take a look at what happens with the serial lane.
So the kubelet failed to restart because of I think it can be related to the topology manager scope PR, I will dig into the code tomorrow. FYI
It actually looks like it was introduced by: With the same issue reported here: And Alexey has a fix for it here (I haven't reviewed it):
Thanks for the update.
Some of these failures are definitely due to , which is causing tests to fail since pods aren't terminating in time. See e.g.
/assign
Under the latest run, I saw that the kubelet failed to restart because of The problem that one of the topology manager tests failed in the middle and did not remove the state file, I can not guarantee that it a single problem, but let's start from it.