jiebi/CodeConvo huggingface dataset:
Change:
if fsVolume { // Filesystem volume case // Mount/remount a volume when a volume is attached <del> generatedOperations, err = oe.operationGenerator.GenerateMountVolumeFunc( </del> <ins> generatedOperations = oe.operationGenerator.GenerateMountVolumeFunc( </ins> waitForAttachTimeout, volumeToMount, actualStateOfWorld, isRemount) } else {

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!--What happened: In this test, volume mount failed because the driver-registrar took a minute to come up. However, it seems like volume mount operation is retrying without any sort of backoff. This message appears in 400+ times in less than a minute. What you expected to happen: Operation executor should not be retrying operations so frequently. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
I'll take a look at this. /assign
Problem is that reconciler depends on operation executor to do backoff. In the normal case operation executor returns a method that does the actual work. Any errors by that method result in exponential backoff. But in this case, the error is coming from the code creating the mount method which is not handled by the back off logic, and is called again and again by the reconciler resulting in log and event spam. This didn't use to be a problem because initialization errors were uncommon (plugins were built in), but with CSI the driver may not exist and these initialization errors are expected. I'll look in to cleaning this up.
Is this something that will affect users in 1.13 and needs CPing?
This will result in kubelet log spam and possibly kubernetes event spam. It happens when someone creates a pod referencing a CSI volume before the CSI driver for that volume is installed. Which happens frequently in E2E tests because they install/remove driver with every test. But should be rare in real world usage since most users are likely to install a driver first before using it.
If release team is worried about this, we could create a quick PR to suppress logging/event generation of this these errors. Otherwise we plan to address this more holistically for 1.14 and 1.13.1.
Change:
<ins> /* Copyright 2015 Google Inc. All rights reserved. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package main import ( "flag" "fmt" "io/ioutil" "os" "syscall" ) var ( fsTypePath           = "" fileModePath         = "" readFileContentPath  = "" readWriteNewFilePath = "" ) func init() { flag.StringVar(&fsTypePath, "fs_type", "", "Path to print the fs type for") flag.StringVar(&fileModePath, "file_mode", "", "Path to print the filemode of") flag.StringVar(&readFileContentPath, "file_content", "", "Path to read the file content from") flag.StringVar(&readWriteNewFilePath, "rw_new_file", "", "Path to write to and read from") } // This program performs some tests on the filesystem as dictated by the // flags passed by the user. func main() { flag.Parse() var ( err  error errs = []error{} ) err = fsType(fsTypePath) if err != nil { errs = append(errs, err) } err = readWriteNewFile(readWriteNewFilePath) if err != nil { errs = append(errs, err) } err = fileMode(fileModePath) if err != nil { errs = append(errs, err) } err = readFileContent(readFileContentPath) if err != nil { errs = append(errs, err) } if len(errs) != 0 { os.Exit(1) } os.Exit(0) } // Defined by Linux (sys/statfs.h) - the type number for tmpfs mounts. const linuxTmpfsMagic = 0x01021994 func fsType(path string) error { if path == "" { return nil } buf := syscall.Statfs_t{} if err := syscall.Statfs(path, &buf); err != nil { fmt.Printf("error from statfs(%q): %v", path, err) return err } if buf.Type == linuxTmpfsMagic { fmt.Printf("mount type of %q: tmpfsn", path) } else { fmt.Printf("mount type of %q: %vn", path, buf.Type) } return nil } func fileMode(path string) error { if path == "" { return nil } fileinfo, err := os.Lstat(path) if err != nil { fmt.Printf("error from Lstat(%q): %vn", path, err) return err } fmt.Printf("mode of file %q: %vn", path, fileinfo.Mode()) return nil } func readFileContent(path string) error { if path == "" { return nil } contentBytes, err := ioutil.ReadFile(path) if err != nil { fmt.Printf("error reading file content for %q: %vn", path, err) return err } fmt.Printf("content of file %q: %vn", path, string(contentBytes)) return nil } func readWriteNewFile(path string) error { if path == "" { return nil } content := "mount-tester new filen" err := ioutil.WriteFile(path, []byte(content), 0644) if err != nil { fmt.Printf("error writing new file %q: %vn", path, err) return err } return readFileContent(path) } </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:
Name:    "pv-recycler", Image:   "registry.k8s.io/debian-base:v2.0.0", Command: []string{"/bin/sh"}, <del> Args:    []string{"-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/*  && test -z "$(ls -A /scrub)" || exit 1"}, </del> <ins> Args:    []string{"-c", "test -e /scrub && find /scrub -mindepth 1 -delete && test -z "$(ls -A /scrub)" || exit 1"}, </ins> VolumeMounts: []v1.VolumeMount{ { Name:      "vol",

Discussion:
PV recycler pod fails to remove files if there are files in the directory. Error in the pod logs: Apparently one hits ARG_MAX due to too long command line. PV is recycled successfully Claim and NFS pv, create files. In my testing I have provided my template and replaced the with: and recycle was successful. Maybe I am missing something but the was able to clean up everything (files, folders) and we also need to exclude the folder name. already has the command, no changes to image needed. <details</details<detailsBare metal </details<details</details<details</details<details</details<detailsNFS Persistent Volume </details
/sig storage
I can prep a PR if we are happy with using command.
/triage accepted
/help wanted
Feel free to submit a PR.
updated the command in issue description as per
Change:
var CmdFakeGitServer = &cobra.Command{ Use:   "fake-gitserver", Short: "Fakes a git server", <del> Long: `When doing "git clone localhost:8000", you will clone an empty git repo named "8000" on local. You can also use "git clone localhost:8000 my-repo-name" to rename that repo.`, </del> <ins> Long: `When doing "git clone http://localhost:8000", you will clone an empty git repo named "localhost" on local. You can also use "git clone http://localhost:8000 my-repo-name" to rename that repo.`, </ins> Args: cobra.MaximumNArgs(0), Run:  main, }

Discussion:
What happened: Follow the "README", I hit below issue, the command there need a prefix "http" or "https". What you expected to happen: clone a fake repo successfully. How to reproduce it (as minimally and precisely as possible): follow the "README" here. create a pod create a service git clone localhost:8000 Anything else we need to know?: Environment: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ): all
/assign
/sig testing
/kind documentation
Change:
RouteTableName:               "rt", PrimaryAvailabilitySetName:   "as", MaximumLoadBalancerRuleCount: 250, <ins> VMType: vmTypeStandard, </ins> }, } az.DisksClient = newFakeDisksClient()

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: When using IMDS, kubelet reports even when vmtype is not set: What you expected to happen: azure cloud provider should assume stardard vmtype if it is not 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig azure
Added to v1.10 milestone since it is a critical bug fix. cc
Change:
ChainPrerouting  Chain = "PREROUTING" ChainOutput      Chain = "OUTPUT" ChainInput       Chain = "INPUT" <ins> ChainBrouting    Chain = "BROUTING" </ins> ) type operation string

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : The ebtables utility in is missing 3 useful features: method in its Interface table chain Why is this needed: The missing features are useful to allow for: rule deletion as there is a way to add (ensure) a rule but not removing it currently. manipulating the broute table and brouting chain The first feature would also align ebtables with iptables, as a DeleteRule method is available there.
/sig network
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Is there some feature/bugfix you're working on in kubernetes that needs this?
Yes, in kubernetes/dns (node-cache) actually. That PR is working, but it's only in my fork of kubernetes/dns at the moment as it depends on this. It solves this: Adding this code to ebtables would help me avoid re-inventing the wheel there.
... not sure if you've seen that ... but I have created a PR to solve this issue already:
Yes, I saw the PR first. So, kubernetes/kubernetes isn't really intended to be vendored into other repos and kubernetes/dns is being bad here. It's dubious to add methods to that kubernetes itself isn't using because someone else might just end up removing them later when they notice that they're not being used... OTOH the PR needs access to the internals of the ebtables code so you couldn't just add it to kubernetes/dns directly without forking all of ...
Thanks for your comments. I saw iptables used that way in node-cache and I thought it would be good for consistency to go down the same route with ebtables. To be honest I am not very keen on forking the entire package, for obvious reasons, but I can understand your reservations about this change.
/assign
Hi Did you manage to discuss this?
yes, sorry, didn't get a chance to get back to this on Friday. (I /lgtm'ed the PR) /remove-triage unresolved
Thanks!
Change:
pathOptions.EnvVar = "" buf := bytes.NewBuffer([]byte{}) <del> cmd := NewCmdConfigDeleteContext(buf, pathOptions) </del> <ins> errBuf := bytes.NewBuffer([]byte{}) cmd := NewCmdConfigDeleteContext(buf, errBuf, pathOptions) </ins> cmd.SetArgs([]string{test.contextToDelete}) if err := cmd.Execute(); err != nil { t.Fatalf("unexpected error executing command: %v", err)

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No, this is a bug report. What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: MacBook Pro Mid-2015 OS (e.g. from /etc/os-release): macOS Kernel (e.g. ): Install tools: Others: N/A What happened: When deleting the context that was my current context, I entered a state where I am seemingly unable to set my context. The shows none as the current: Also, when trying to take any actions that require a context the following error is presented: When viewing the full config () I can see that my selected context is still the one I deleted. What you expected to happen: I believe there are two expectations I had: should allow me to delete my current context, but not enter an inconsistent state in the process -or- should either provide a warning or disallow removing your current context How to reproduce it (as minimally and precisely as possible): I believe that you just need a configuration with multiple contexts. I had three before deleting the context that has me unable to set a new context.

list all contexts to find your current context () delete your current context list your current contexts again, and you'll see no contexts are created try to set your context with one of the ones that exist () listing your contexts again will show none being set Anything else we need to know: 3 contexts were configured before starting to delete one 2 of them were GKE clusters, automatically set up by the binary 1 is a context set up by the context I deleted was one of the contexts The issue was resolved by manually setting my context by editing .
I think this is the confusion of doesn't switch contexts, it lets you set fields on a context. is what switches contexts.
It's technically valid to have no current context, but I agree a warning message like "warning: this removed your active context, use to select a different one" would go a long way.
SGTM.
Change:
Limits: v1.ResourceList{ v1.ResourceCPU: *resource.NewMilliQuantity(nodeMaxAllocatable*5/10, "DecimalSI"), }, <ins> Requests: v1.ResourceList{ v1.ResourceCPU: *resource.NewMilliQuantity(nodeMaxAllocatable*5/10, "DecimalSI"), }, </ins> }, } WaitForSchedulerAfterAction(f, createPausePodAction(f, conf), ns, podName, false)

Discussion:
What happened: I am questioning validity of the test. Comments under of say: The test scenario described as it is sounds reasonable. The only nitpick I have is the very first sentence saying "". Pod's resource limits are ignored in predicates. They take effect in the scoring phase when priorities are computed. Also, priorities are computed only when there are at least two candidate nodes. So after revisiting the step number 5 it's impossible to make sure the additional pod does or does not get scheduled when setting the resource limits. There are either no candidate nodes or one. In which case the limits are ignored and the test passes in the first case and fails in the second. In case there are at least two candidate nodes, one of them will always get picked. In which case the additional pod gets scheduled (no matter what the resource limits field says). In the framework: resource limits are accessed through method [1] is used to perform pre-scoring [2] in the scoring phase score is computed through method [3] The test is alternating between passing and failing state. It passes when predicates give empty list of candidate nodes and failing when the list of candidate nodes is non-empty. Thus, making the pod resource limits ineffective. [1] [2] [3] What you expected to happen: Have another node schedule the additional pod validating that all saturated nodes (with scheduled) have lower score (0 in case of plugin). Or, invalidate the test by removing it. Can anyone check the test validity and confirm/disprove my statement about ineffectiveness of the resource limits? How to reproduce it (as minimally and precisely as possible): Make sure there is at least one node with non-zero free cpu resource before running the step 5. Anything else we need to know?: Environment: Kubernetes version (use ): master HEAD Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
cc
I have noticed you refactored the test in Can you still recall the original intent of the test? I can't grasp how the limits are actually taken into account.
I agree, I think the test is wrong, the scheduler doesn't make fit decisions on resource limits. In the test, should have set. do you mind fixing the test and update the test comment please?
On it /assign
Change:
// Expects the OpenStack Cinder CSI Driver to be installed and configured on all nodes. CSIMigrationOpenStackComplete featuregate.Feature = "CSIMigrationOpenStackComplete" <del> // owner: @MrHohn // alpha: v1.15 // beta:  v1.16 // GA: v1.17 // // Enables Finalizer Protection for Service LoadBalancers. ServiceLoadBalancerFinalizer featuregate.Feature = "ServiceLoadBalancerFinalizer" </del> // owner: @RobertKrawitz // alpha: v1.15 //

Discussion:
When should it be removed? /sig network /kind cleanup
It was GAed in 1.17 and should have been removed in 1.18. I will send a PR to remove it retrospectively. /assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
I know a new-contributor looking for good-first-issues. Do you mind if I cc him on this issue since it seems pretty straightforward ?
That sounds perfect, thanks!
cc
I am still planning on working on this, I am just having some dev environment issues I am hoping to resolve in the next few days. I'll update again when I get them resolved.
Hey, just a quick update. I have been fairly busy and am going on vacation next week. I AM still planning on working on this, however since I am obviously very slow if someone comes along and wants to work on this feel free. Just please comment that you will work on it so I know :).
Change:
Containers:                    p.ContainerSpecs(), }, } <ins> if framework.NodeOSDistroIs("windows") { thePod.Spec.NodeSelector = map[string]string{ "kubernetes.io/os": "windows", } } return thePod </ins> } // QualifiedServiceAddress returns the address that can be used to hit a service from

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Ive done preliminary testing with on calico powered clusters on some windows variants and found that the probing seems to work. Can we add wrapper to netpol suite so that we can run it on windows clusters ? Why is this needed: We need this because otherwise, CNIs such as EKS will give us This error is caused when, for example, pods that are landing on a windows node havent defined their target platform. Somehow i guess pods which are landing on linux nodes dont have this issue. Its also needed for the obvious reason that we probably want separate linux and windows test suites for policies, in general, even though we expect the logic to be identical (modulo hostports , which we dont currently test)
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 windows
/assign
grepping around, I can't figure out where those are supposed to go. Can you give me pointers?
(resolved in slack, matts digging into this)
ok, these are running now on eks, lots of failures. will dig
/assign
the netpol are not being applied for the ns: Instead of failing because should not be able to access , the connection succeeds.
Change:
"k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/intstr" "k8s.io/apimachinery/pkg/util/sets" <ins> "k8s.io/apimachinery/pkg/util/wait" </ins> utilfeature "k8s.io/apiserver/pkg/util/feature" "k8s.io/client-go/informers" "k8s.io/client-go/kubernetes/fake"

Discussion:
No response No response_ /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
/sig network /sig cloud-provider
Fun. Are these test executed with special arguments or similar when running in CI? This is locally on master for me on my laptop:
This is currently blocking 1.29 beta.0 release cut. Do you think this is a release blocker? If yes, then can you please give an estimated time for fix? Thanks!
No, I don't think this is a release blocker. The problem is the test, not the implementation. The PR I have up should de-flake the test and fix the issue.
Thanks a lot for confirming
This is now the top flaking test in " service": 11,
ping
The PR fixing this is still not approved by the corresponding SIG, yet (ref ).
/assign This controller is really more sig-network than cloud provider :)
we discussed this at the sig cloud provider meeting today, but will need more time to investigate.
seeing this frequently in and in downstream CI unit test runs
should we revert if we cannot fix the test that came in with it? are we sure that PR didn't introduce a bug?
unit tests must not be flaky ... we either need to prioritize fixing of the flake (either the open PR or an alternative), or back out the change that brought in the flaky test. looks low risk to me and consistent with needing to wait for an informer to sync before the test will be deterministic
Change:
staticResources:         staticResources, kubeClient:              kubeClient, kubeletClient:           kubeletClient, <ins> recorder:                recorder, </ins> registerRetryCount:      registerRetryCount, podEvictionTimeout:      podEvictionTimeout, deletingPodsRateLimiter: deletingPodsRateLimiter,

Discussion:
/cc
Is this from head? I've never seen this before, maybe changed anything recently. Anyway, the code in question will be deleted by
I saw this in the Travis run for an unrelated PR (Kubelet test refactoring). If it's going away, then that's ho we'll fix it :)
Yup. It'll go away. I'll assign it to myself - I'll run test few times after to make sure it's gone.
another example: https://travis-
Just hit this again: https://travis-
I was hoping we could finish getting rid of this code this week, which is why I had been ignoring this. But we ran out of time and Poland has a holiday on Monday, so I guess we need to fix this race. I'll take a look.
Thanks. This is becoming a real nuisance that is masking other failures.
To repro I assume I just type the commands from Travis, e.g. the shell stuff in https://travis- ?
Never mind, I got it. Though the first time I ran it all the tests passed.
I don't think the failure is deterministic, but yes.
This is super annoying, it happens way too much of the time...
Sigh, I was hoping we can get rid of the code this week. I think the problem comes from someone changes the event recording. I'll send a PR
It seems to be basically always failing now, except when some other flake fails first.
It would be fine with me if we just temporarily disabled event generation there.
If I'm reading the stack traces correctly, what's going on is that NewNodeController [] calls StartRecordingToSink() [] which calls StartEventWatcher() which calls eventHandler() which calls StartRecordingToSink() which calls sink.Create() which is Create() in , which appends to c.Fake.Actions. At the same time, the last line of the test tries to print "item.fakeNodeHandler.Actions" and these are presumably the same variable. I'm not sure why these are running at the same time, though.
+1 to Braians idea to temporary disable event generation.
Re-titled issue.
Re-titled issue.