jiebi/CodeConvo huggingface dataset:
Change:
// if there are any problems. dockerRoot := "/var/lib/docker" <del> // cgroup driver is only detectable in docker 1.12+ </del> <ins> // cgroup driver is only detectable in docker 1.11+ </ins> // when the execution driver is not detectable, we provide the cgroupfs form. // if your docker engine is configured to use the systemd cgroup driver, and you // want to use pod level cgroups, you must be on docker 1.12+ to ensure cgroup-parent

Discussion:
Kubernetes version (use ): v1.5.0-alpha.1.2189+-dirty docker: 1.12.3 Environment: fedora24 docker-engine-1.12.3-1.fc24.x86_64 What happened: if docker Cgroup Driver=cgroupfs, and set --cgroup-driver=systemd in kubelet, then enable --experimental-cgroups-per-qos=true; The container cgroup some is not correct. How to reproduce it (as minimally and precisely as possible): Anything else do we need to know: 1) docker Cgroup Driver=cgroupfs and --cgroup-driver=cgroupfs in kubelet works well 2) docker Cgroup Driver=systemd and --cgroup-driver=systemd in kubelet works well
help check, thanks.
In Kubernetes 1.6, we can work to detect this case and return an error. IMHO its a configuration error to have docker running with a cgroupfs driver paired with the kubelet running the systemd cgroup driver. /cc
We can also document the compatibility matrix for now.
Change:
// wait as required for all 3 pods to be running ginkgo.By("waiting for all 3 pods to be running") <del> err := e2epod.WaitForPodsRunningReady(f.ClientSet, f.Namespace.Name, 3, 0, framework.PodStartTimeout, nil) </del> <ins> err := e2epod.WaitForPodsRunningReady(f.ClientSet, f.Namespace.Name, 3, 0, f.Timeouts.PodStart, nil) </ins> framework.ExpectNoError(err, "3 pods not found running.") // delete Collection of pods with a label in the current namespace

Discussion:
pull-kubernetes-e2e-kind-ipv6 Pods should delete a collection of pods According to testgrid, March 18th Timeout in No response /sig node
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
Looking at The test is here - It creates 3 pods which go into Failed phase and then expects them to within . Looking at failure in the build-log, there were three pods created, , , . did not get deleted from the API-server within the 1 minute timeout causing the test to fail. From the build-log, the test starts checking for all the pods to be deleted at: So the test expected all the pods to be deleted at 1 minute + 18:35:03 = 18:36:03 Looking at the logs of which landed on : DELETE was sent at landed on DELETE was sent at which is ~20 sec after when the test with the 1 minute timeout expected which caused the test to fail.
I suggest we bump the timeout a bit since everything seems to be working, it's just taking a bit longer than the timeout is currently set to. This also may be affected by recent which slightly increases how long it takes for pod to be marked as terminal by kubelet.
Change:
func InjectHtml(client clientset.Interface, config VolumeTestConfig, volume v1.VolumeSource, content string) { By(fmt.Sprint("starting ", config.Prefix, " injector")) podClient := client.CoreV1().Pods(config.Namespace) <ins> podName := fmt.Sprintf("%s-injector-%s", config.Prefix, rand.String(4)) volMountName := fmt.Sprintf("%s-volume-%s", config.Prefix, rand.String(4)) </ins> injectPod := &v1.Pod{ TypeMeta: metav1.TypeMeta{

Discussion:
Failing Job: These tests started flaking recently (they were consistently green for a long time): Mounted volume expand[Slow] Should verify mounted devices can be resized Volume expand [Slow] Verify if editing PVC allows resize Subpath [Volume type: gcePDPVC] should support restarting containers using file as subpath [Slow] Subpath [Volume type: gcePDPVC] should fail for new directories when readOnly specified in the volumeSource Subpath [Volume type: gcePDPVC] should fail if subpath with backstepping is outside the volume [Slow] Volumes PD should be mountable with ext4 Affected runs: https://k8s- https://k8s- https://k8s- /kind bug /sig storage /priority important-soon /milestone v1.12 /cc - Could you PTAL or delegate? Thanks.
Volume expansion tests have been fixed by
/assign can you investigate the remaining failures?
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. If the label is not applied within 4 days, the issue will be moved out of the v1.12 milestone. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : 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
Reopening this issue, as a bunch of storage-related e2es started flaking in our large-scale jobs recently: https://k8s- https://k8s- /reopen
I think the latest failures are caused by gce API rate limiting: /assign
It seems to only be failing on scalability test suites. I wonder if it's due to some different cidr configuration
/sig scalability
/kind failing-test
/status approved-for-milestone Friendly ping. This is affecting release-blocking scalability job.
hey what needs to be done here? by whom?
Could you comment on what needs to be done here and by whom?
can you guys take a look at the API quota issue?

This is happening consistently in the scale test environment
as Code Freeze is today, this needs to be of priority . Please triage! cc
It looks like the latest run on 9/1 has passed.
Marking closed as the fixes have been merged and the test runs are now passing /close
Closing this issue. <detailsIn response to : Marking closed as the fixes have been merged and the test runs are now passing /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:
func TestPidListerFailure(t *testing.T) { _, err := getPids("/does/not/exist") <del> assert.True(t, cgroups.IsNotFound(err), "expected getPids to return not exists error. Got %v", err) </del> <ins> assert.True(t, cgroups.IsNotFound(err) || os.IsNotExist(err), "expected getPids to return not exists error. Got %v", err) </ins> }

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: What you expected to happen: The test should pass How to reproduce it (as minimally and precisely as possible): I think the key here is being on a linux host with cgroupsv2 enabled. 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
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
Change:
RuntimeConfig              util.ConfigurationMap KubeletConfig              client.KubeletConfig ClusterName                string <ins> SyncPodStatus              bool </ins> } // NewAPIServer creates a new APIServer object with default parameters

Discussion:
Split off as a smaller more specific work item. Apiserver should have a flag that makes it not attempt to GET from kubelets. This would be used in conjunction with . After we have converted the top N Getting-started-guides to the new style, we can rip out the kubelet client from the apiserver altogether.
This is tightly related to so I'll take it.
Change:
// A Set is used here since we end up calculating endpoint topology multiple times for the same Service // if it has multiple ports but each Service should only be counted once. serviceNoLocalEndpointsExternal sets.Set[string] <ins> // lbNoNodeAccessIPPortProtocolEntries represents the set of loadBalancers IP + Port + Protocol that should not be accessible from K8s nodes // We cannot directly restrict LB access from node using LoadBalancerSourceRanges, we need to install // additional iptables rules. // (ref: https://github.com/kubernetes/kubernetes/issues/119656) lbNoNodeAccessIPPortProtocolEntries []*utilipset.Entry </ins> } // Proxier implements proxy.Provider

Discussion:
When using loadBalancerSourceRanges to allow access only from CIDRs outside the cluster segment, access from the K8s nodes (or pods with hostNetwork:true) should be rejected, but for proxy-mode=ipvs it works. /sig network /area kube-proxy /area ipvs Access from K8s nodes should be rejected in the same way as for proxy-mode=iptables Define a service with loadBalancerSourceRanges that allows access from a cidr outside the cluster, e.g. The K8s nodes have addresses on 192.168.1.0/24 and fd00::c0a8:100/120. Make sure a loadBalancerIP is assigned (in this example 10.0.0.0/32) and try to access it from a K8s node: Same for both ipv4 and ipv6. This is related to since a fix requires that the passed to the is correct. Please see v1.27.4 and master None Linux 6.4.4 None N/A N/A
wanted to work on this
Great! But please coordinate with I hope that one get accepted, and then ~the s (both families) passed to the proxiers should be usable.~ No, they are not, please see
Discussed this one in the SIG Network meeting today: we agree this is something we'd like to implement, however we weren't sure exactly how to do it with ipvs during the meeting. Whoever takes this on needs to come up with and communicate a clear plan of how it will be accomplished. /triage accepted
My comment is not feasible. For proxy-mode=ipvs the src and dst is both loadBalancerIP. So the nodeIP will not help :disappointed:
I did a small experimented with kind + metallb. I created a loadbalancer service backed by . loadBalancerIP: 172.18.255.200 podIP: 10.244.1.3 conntrack picks the src and dst both as loadBalancerIP. Tried to create an iptables rules matching source and destination with loadbalancerIP to drop packets but it didn't work. After some exploration I found and with the following rules I was able to prevent access to lbIP from k8s nodes / host network.

The solution looks hacky though, we only need this rule if source ranges are defined for the service and node ip is not covered by any of them. Will try to program this in the ipvs proxier.
Good find! :+1: I had missed the ipvs extension. I started to check nodeIP and the (flawed) option to experiment with setting a nodeIP as "src" for some routes to dodge the lbip-both-as-src-and-dst problem, and an old "vision" I have to not assign clusterIPs to at all, but have one rule to replace them all, like: It can be done, and in a cluster with 1000's of clusterIP's it would simplify
Change:
addProfilingFlags(flags) <del> kubeConfigFlags := genericclioptions.NewConfigFlags() </del> <ins> kubeConfigFlags := genericclioptions.NewConfigFlags(true) </ins> kubeConfigFlags.AddFlags(flags) matchVersionKubeConfigFlags := cmdutil.NewMatchVersionFlags(kubeConfigFlags) matchVersionKubeConfigFlags.AddFlags(cmds.PersistentFlags())

Discussion:
/kind bug What happened: takes ~11 seconds when there are thousands of CRDs and is around 28KiB. logs the following message once per resource: Removing unnecessary entries from reduces the runtime by around ten seconds. What you expected to happen: only parses once, and therefore doesn't run unnecessarily slowly. How to reproduce it (as minimally and precisely as possible): shows the config being loaded multiple times (assuming you have multiple pods in the current cluster). Alternatively, add 10-15 clusters to and create ~3000 of a cheap resource (eg custom resources or empty config maps). Run on this resource and observe that it is unnecessarily slow. Anything else we need to know?: I've created a CPU profile using the latest CI build of kubectl, which shows ~12 seconds being spent in . Environment: Kubernetes version (use ): v1.12.1 (also Cloud provider or hardware configuration: GKE or minikube --vm-driver=none OS (e.g. from /etc/os-release): Debian Buster-like Kernel (e.g. ): 4.17.0
/sig cli
/assign
Same problem here. I have less resources but more contexts in my kubeconfig file. With 90 pods and ~300 contexts in the kubeconfig it also takes ~10 seconds for a simple kubectl get pods Note: I tried it with kubectl: 1.11.0, 1.12. With kubectl 1.10.5 the kubeconfig was loaded only once.
I'm unable to reproduce this as of the latest master. My kubeconfig is only loaded 4 times, no matter how many resources are loaded.
When I try a kubectl v1.13.0-alpha.3 against unfortunately a 1.9.11 Kubernetes Cluster I still have the problem: `
Maybe the bug is Linux-only? Presumably the kubeconfig location is different on different platforms, so maybe it has a different code path. I can repro on latest master:
I filed to fixed this. You can try to help validate it. Thanks.
Works for me, thanks!
Change:
} } <ins> func verifyUnorderedCalls(t *testing.T, fakeDocker *dockertools.FakeDockerClient, calls []string) { err := fakeDocker.AssertUnorderedCalls(calls) if err != nil { t.Error(err) } } </ins> func verifyStringArrayEquals(t *testing.T, actual, expected []string) { invalid := len(actual) != len(expected) if !invalid {

Discussion:
Seeing random failures.
Looks like lately refactory makes docker API requests are not deterministic. Will look into it.
Any update? It seems to be failing a lot.
I just looked into this and found that is the only test that there are two pods in the which is fed to I think podworker was syncing the two pods in parallel, this causes non-deterministic behaviour I have tried , no errors. , error happens continuously. I can try to fix this :)
Yes, that is what I believe here, but never have time working on it. Thanks for looking into this, and re-assign it to you.
I saw your old PR for this, I think we still need to keep the parallel sync here. Just need to create a for this case :)
Change:
Start the server: ```sh <del> cluster/kubectl.sh proxy -www=$PWD/www </del> <ins> cluster/kubectl.sh proxy --www=$PWD/www </ins> ``` The UI should now be running on [localhost](http://localhost:8001/static/index.html#/groups//selector)

Discussion:
I have been following the instructions here: to try to explore the kube UI. by executing: I get the following which shows it successfully started: When I try to access the page I get a 404:
could you try running ? I believe is a typo of
Also, try accessing instead.
thanks
Change:
{Min: 1, Max: 3}, {Min: 4, Max: 4}, }, <ins> expectedError: "group 5 must be in the ranges: [{1 3} {4 4}]", </ins> }, "in range 1": { groups: []int64{2}, ranges: []extensions.GroupIDRange{ {Min: 1, Max: 3}, }, <del> pass: true, </del> }, "in range boundary min": { groups: []int64{1}, ranges: []extensions.GroupIDRange{ {Min: 1, Max: 3}, }, <del> pass: true, </del> }, "in range boundary max": { groups: []int64{3}, ranges: []extensions.GroupIDRange{ {Min: 1, Max: 3}, }, <del> pass: true, </del> }, "singular range": { groups: []int64{4}, ranges: []extensions.GroupIDRange{ {Min: 4, Max: 4}, }, <del> pass: true, </del> }, }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: This is request for improvements. What happened: When PodSecurityPolicy provider validates or fields of a pod, it shows an error like "999 is not an allowed group" if the group doesn't belong to the range(s). What you expected to happen: It should include to the error message also the allowed values -- the ranges against what we were validating this group. This will simplify user experience and debugging. How to reproduce it (as minimally and precisely as possible): run kubernetes cluster with PSP support create a PSP that allows fsGroup/SupplementalGroups in some ranges grant to a user access to this PSP try to create a pod that has fsGroup/SupplementalGroups outside of the allowed ranges Anything else we need to know?: In order to improve the current behavior, we need to modify function here: Reported-by: /kind help
This looks like a good first issue! My suggestion would be something like . I would also suggest to merge overlaying ranges in the log message, like as , to keep the log as concise as possible. I will look into it.
Maybe something like ? Thank you!
We can use the same approach that strategy uses:
Sure, that is probably the most consistent solution.
/remove-help
Change:
} func TestDelNode(t *testing.T) { <ins> defer func() { now = time.Now }() var tick int64 now = func() time.Time { t := time.Unix(tick, 0) tick++ return t } </ins> evictor := NewRateLimitedTimedQueue(flowcontrol.NewFakeAlwaysRateLimiter()) evictor.Add("first") evictor.Add("second")

Discussion:
Running show failures at times: The expected queue is while got , see code here: I would give an idea that these cases have something similar, so referring and /cc
cc
I think so as well.
The debugging I to the test is obviously not correct - I'll fix that separately.
I wonder if on very short intervals we're not getting a goroutine schedule swap, which causes this race to manifest (based on comments in the other thread).
Does heap insertion guarantee order if the heap value is equivalent? I don't think so.
This seems like it is that now() is not monotonically increasing, so we violate the add ordering condition. Since we already have a lock in most cases, we may want to either wrap now() to make it monotonic inc, or have the queue check for equality in the heap and add one nanosecond until there is no matching heap item. On Apr 29, 2016, at 7:12 PM, Marek Grabowski wrote: cc — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub
Thanks for clarification, so it looks like we need to give some time break between doing , I'll see whether that helps.
I believe this is a bug in rate limited queue, so we definitely need to fix it (esp. since it's happening in the real world)
you wrote Would you be a good person to pick an owner for this bug? Giving P1 since we think happens in real world and I don't understand severity.
and I are probably the two who have touched it, I think as well but may be misremembering. It should be a straightforward fix to make now monotonic, I don't know when I can get to it
Me neither. If it's P1 I most likely won't have time before v1.3.
I think override the function call in as you did would resolve this issue, what do you think, if you agree with this, I am gonna to try that.
It would fix it, although I think this is broken in the core code, not just in the test. We suspect real workloads have been impacted by this.
Opened to determine whether we actually need to fix the RLQ
Assigning to per
Change:
} func NewResourceExpirationEvaluator(currentVersion apimachineryversion.Info) (ResourceExpirationEvaluator, error) { <del> ret := &resourceExpirationEvaluator{ // TODO https://github.com/kubernetes/kubernetes/issues/101951 set this back to false after beta is tagged. strictRemovedHandlingInAlpha: true, } </del> <ins> ret := &resourceExpirationEvaluator{} </ins> if len(currentVersion.Major) > 0 { currentMajor64, err := strconv.ParseInt(currentVersion.Major, 10, 32) if err != nil {

Discussion:
once the we hit a beta release, we can reset the default value for strict handling to false to prep for 1.23. /assign /kind bug /priority important-soon /milestone v1.22
/triage accepted
Hi Bug Triage from SIG Release here .. Checking to see if this issue is going to make it to v1.22 milestone bearing in mind code freeze is 07/08/2021. Feel free to reach out if there are any questions/concerns.
Hi, Bug Triage here, removing this issue from 1.22, as there hasn't been activity on that issue for 16 days. /milestone clear
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:
setInitCommand(input.pod, fmt.Sprintf("ln -s ../ %s", input.subPathDir)) // Pod should fail <del> testPodFailSubpath(input.f, input.pod) </del> <ins> testPodFailSubpath(input.f, input.pod, false) </ins> }) It("should support creating multiple subpath from same volumes [Slow]", func() {

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: The read only sig-storage tests validate that Pods can come up when readOnly is set. But it doesn't actually validate that the container cannot write to the volume. What you expected to happen: Tests should validate that the container cannot write to readonly volumes. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/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 : /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
can this issue be closed after your last PR or is there more to work on? If yes I'd like to know what's left because I'm looking for something to work on
I think we should actually reinstate the test case I removed and enhance it to handle the two scenarios I mentioned. It would also be good to see if we have other readOnly test cases that could be enhanced as well
Thanks ! I have a few questions: 1) how do I run the tests in locally? and 2) how can I assert writing to volume has failed? Thank you in advance!!