jiebi/CodeConvo huggingface dataset:
Change:
framework.NewFrameworkExtensions = append(framework.NewFrameworkExtensions, func(f *framework.Framework) { ginkgo.AfterEach(func() { <ins> if f.ClientSet == nil { // Test didn't reach f.BeforeEach, most // likely because the test got // skipped. Nothing to check... return } </ins> e2enode.AllNodesReady(f.ClientSet, 3*time.Minute) }) },

Discussion:
After merged, build logs for e2e tests have started showing stack traces that look like: It seems like the used in this is nil I have a suspicion this is happening for storage tests that skip No new stack traces in build logs Run e2e tests against the in-development version of kubernetes I identified when this started happening by looking for an increase in build-log size is the first build where this started happening, which happens to be the first build after merged, which is the PR that introduced this new way of invoking <details</details<details</details<details</details<details</details<details</details<details</details
/sig testing /triage accepted /assign To put this on your radar
/cc
Correct. This happens because of the ordering in Tests gets skipped before is called. This avoids the expensive namespace creation/deletion for tests that don't need to run. The for then gets executed although the framework didn't get initialized. My preferred solution is to document that the framework instance might not be initialized in an AfterEach callback and add a nil check to .
See Only was affected. The other framework extensions use DeferCleanup, which only runs when needed.
Change:
// propagateControllers on an unified hierarchy enables all the supported controllers for the specified cgroup func propagateControllers(path string) error { <del> if err := os.MkdirAll(path, 0755); err != nil { </del> <ins> if err := os.MkdirAll(filepath.Join(cmutil.CgroupRoot, path), 0755); err != nil { </ins> return fmt.Errorf("failed to create cgroup %q : %v", path, err) }

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: is created on a cgroup2 host What you expected to happen: Such directory should not be created How to reproduce it (as minimally and precisely as possible): Boot Ubuntu 20.04 with Install moby/moby with containerd/containerd and opencontainers/runc Install kubernetes-sigs/kind . This version uses as the base image. Run with Run Run to drop into the shell of the node The following directories are unexpectedly created. (No process seems to belong to these groups actually) Environment: (See above)
cc
/sig node
Change:
framework.Failf("Error cleanup pod `%s/%s`: %v", metav1.NamespaceSystem, "critical-pod", err) } }() <del> runPausePodWithTimeout(ctx, f, pausePodConfig{ </del> <ins> runPausePod(ctx, f, pausePodConfig{ </ins> Name:              "critical-pod", Namespace:         metav1.NamespaceSystem, PriorityClassName: scheduling.SystemClusterCritical,

Discussion:
master-blocking kind-ipv6-master-parallel RuntimeClass should run a Pod requesting a RuntimeClass with scheduling without taints AdmissionWebhook [Privileged:ClusterAdmin] should honor timeout [Conformance] 01-27-2023 16:08 PST https://k8s- { failed [FAILED] timed out while waiting for pod runtimeclass-3517/without-label to be running In [It] at: @ 01/28/23 22:33:45.607 } No response kind 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
It looks like that “Kubernetes e2e suite: . Would we want to reopen this issue? I will keep a close eye on to see if it continues to flake.
Reopen to monitor failures cc
/sig node /cc
/retitle [It] [sig-node] RuntimeClass should run a Pod requesting a RuntimeClass with scheduling without taint
Example failure:
Failure The pod was created at , from the kubelet logs: so the pod started at , but it was deleted at because the 1 minute timeout was hit. It looks like the container startup took a while based on containerd logs: there is a gap there of and between and
It is hitting this timeout - That uses which is 1 min which seems to be too short. We should probably use or which is 5min or 2min, because the whole pod needs to start and it seems like 1min is too short in this case.
Change:
srcs = [ ":package-srcs", "//hack/boilerplate:all-srcs", <ins> "//hack/conformance:all-srcs", </ins> "//hack/e2e-internal:all-srcs", "//hack/lib:all-srcs", "//hack/make-rules:all-srcs",

Discussion:
There are a number of conformance test requirements and guidelines: We should try to automate enforcement to the degree we can, via a "linting" tool, and/or test framework checks. For instance, conformance tests shouldn't invoke framework.ProviderIs or framework.SkipUnlessProviderIs. Those could actually check whether they are invoked by a conformance test, and then die. cc /area conformance
/sig testing
/cc
Change:
// adds a watcher to the bucket, if the deadline is before the start, it will be // added to the first one. func (t *watcherBookmarkTimeBuckets) addWatcher(w *cacheWatcher) bool { <del> nextTime, ok := w.nextBookmarkTime(t.clock.Now()) if !ok { return false } </del> <ins> nextTime := w.nextBookmarkTime(t.clock.Now()) </ins> bucketID := nextTime.Unix() t.lock.Lock() defer t.lock.Unlock()

Discussion:
Currently, (best-effort) watch bookmarks are sent just right before the given watch is supposed to timeout: In we're adjusting how the size of watch cache is determined and make it dynamic and more duration-oriented (rather than based on some magic constants) - we're targeting to always keep 5 minutes of history in watch cache. With that change, we should get back to our bookmark policy: change it to (additionally to right before timeout) also send bookmarks every N seconds (setting N to slightly less than expected watch cache history period, so slightly less than X minutes we will use there) scale-test this change (to see if it doesn't introduce non-negligible overhead) if so permanently introduce this change /sig scalability api-machinery
/cc
/cc
/cc
I'm reverting as it broke bookmarks. I'm going to fix and re-submit for review hopefully later this week.
Change:
name = "all-srcs", srcs = [ ":package-srcs", <ins> "//pkg/kubelet/server/metrics:all-srcs", </ins> "//pkg/kubelet/server/portforward:all-srcs", "//pkg/kubelet/server/remotecommand:all-srcs", "//pkg/kubelet/server/stats:all-srcs",

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) add metrics into kubelet to monitor ; 2) add throttling to . Why is this needed: Kubelet provides lots of its functionalities through its http server, and currently there is no server-side monitoring and throttling mechanisms. Adding metrics into kubelet to monitor its http server will improve its observability and debuggability; adding throttling will prevent kubelet being overloaded from serving too many http requests.
/sig node
Change:
NodeCIDRMaskSizes:    []int{24, 98, 24}, }, }, <ins> { description: "no double counting", fakeNodeHandler: &testutil.FakeNodeHandler{ Existing: []*v1.Node{ { ObjectMeta: metav1.ObjectMeta{ Name: "node0", }, Spec: v1.NodeSpec{ PodCIDRs: []string{"10.10.0.0/24"}, }, }, { ObjectMeta: metav1.ObjectMeta{ Name: "node1", }, Spec: v1.NodeSpec{ PodCIDRs: []string{"10.10.2.0/24"}, }, }, { ObjectMeta: metav1.ObjectMeta{ Name: "node2", }, }, }, Clientset: fake.NewSimpleClientset(), }, allocatorParams: CIDRAllocatorParams{ ClusterCIDRs: func() []*net.IPNet { _, clusterCIDR, _ := net.ParseCIDR("10.10.0.0/22") return []*net.IPNet{clusterCIDR} }(), ServiceCIDR:          nil, SecondaryServiceCIDR: nil, NodeCIDRMaskSizes:    []int{24}, }, expectedAllocatedCIDR: map[int]string{ 0: "10.10.1.0/24", }, }, </ins> } // test function testFunc := func(tc testCase) { <ins> fakeNodeInformer := getFakeNodeInformer(tc.fakeNodeHandler) nodeList, _ := tc.fakeNodeHandler.List(context.TODO(), metav1.ListOptions{}) </ins> // Initialize the range allocator. <del> allocator, err := NewCIDRRangeAllocator(tc.fakeNodeHandler, getFakeNodeInformer(tc.fakeNodeHandler), tc.allocatorParams, nil) </del> <ins> allocator, err := NewCIDRRangeAllocator(tc.fakeNodeHandler, fakeNodeInformer, tc.allocatorParams, nodeList) </ins> if err != nil { t.Errorf("%v: failed to create CIDRRangeAllocator with error %v", tc.description, err) return

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: With a /22 pod network and a /24 assigned to each node, a third node cannot get a pod CIDR if kube-controller-manager has ever been restarted. What you expected to happen: Once a third or fourth node joins, it gets a /24. How to reproduce it (as minimally and precisely as possible): 150% usage on the IPAM controller is not a good sign. Anything else we need to know?: During the creation of the rangeAllocator, Occupy() is called twice on the pod networks. The first time is before subscribing to the node informer. The second time is during the node informer callbacks because on subscribing it calls Add for all existing nodes. I will submit a proposed fix shortly. Environment: Kubernetes version (use ): 1.19.2
/sig network
/triage accepted thanks for finding the bug I 've introduced :)
Change:
dq := NewDelayQueue() delay := 2 * time.Second <del> dq.Add(&testjob{d: delay}) </del> before := time.Now() <ins> dq.Add(&testjob{d: delay}) </ins> x := dq.Pop() now := time.Now()

Discussion:
Failure:
Assigning to per
do you have reason to think this is still happening? if not, want to close it?
[FLAKE-PING] This flaky-test issue would love to have more attention...
[FLAKE-PING] This flaky-test issue would love to have more attention...
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
Test passed with the latest code, suggest to close it firstly; if happened again, please assign it to me directly :). Head: OS: Test command: Test output:
- this is flake, not permanent failure (as almost all issues with "kind/flake"; running a test once most probably will not fail and that's expected
thanks for your input. The log is gone, let me check the code to see if any clue :).
Here maybe the root case after reviewing the code: the do the following steps: into current time () item from current time () the wait period () The problem is that: the timer start at "Step 1" in in , if there's any delay between "Step 1" & "Step 2", the wait period will be shorter than expected. The proposed PR is to record time before adding item. If any comments, please let me know. Thanks klaus
Change:
return false } <ins> // hasNonLocalProjectedTokenPath return true if spec.Volumes have any entry with non-local projected token path func hasNonLocalProjectedTokenPath(spec *api.PodSpec) bool { for _, volume := range spec.Volumes { if volume.Projected != nil { for _, source := range volume.Projected.Sources { if source.ServiceAccountToken == nil { continue } errs := apivalidation.ValidateLocalNonReservedPath(source.ServiceAccountToken.Path, nil) if len(errs) != 0 { return true } } } } return false } </ins> // GetValidationOptionsFromPodSpecAndMeta returns validation options based on pod specs and metadata func GetValidationOptionsFromPodSpecAndMeta(podSpec, oldPodSpec *api.PodSpec, podMeta, oldPodMeta *metav1.ObjectMeta) apivalidation.PodValidationOptions { // default pod validation options based on feature gate

Discussion:
Originally posted by in
Hello, I'm new here. Can I try solving this? it seems like a good first issue
sure, context is the change is needed here: We have to tolerate existing pods / pod specs that fail this validation, so we should only do this additional validation on create or if the existing object passes this validation. To do this: an field to , initialize that field to false, and then conditionally override it to if is non-nil and has a projected token volume path that fails (will have to export the function to check this) , if is false, call the validation on the path:
Hi, I'd like to work on this if there is no one is proceeding on. /assign
Change:
_ "k8s.io/code-generator/cmd/informer-gen" _ "k8s.io/code-generator/cmd/lister-gen" _ "k8s.io/code-generator/cmd/register-gen" <ins> _ "k8s.io/kube-openapi/cmd/openapi-gen" </ins> )

Discussion:
We're trying to upgrade to () and found the issue on executing (). The problem is that on () missed dependency that not allow to install () No error To reproduce the same what happening on , just execute this command on code-generator folder: I think it's happens after this commit <details</details<details</details<details</details<details</details<details</details<details</details
/cc
/assign
/sig api-machinery
I was able to reproduce, but just because I had an older version of kube-openapi in my GOPATH. Using the prefix in the command fixed it. I think line needs to be
Yeah, with works for me too.
Either that or we pin to a more recent commit, for example . For some reason if you ommit the version it is using a from Feb 27.
thanks for investigating. Question, if we use would this not cause problems in the future if we try to build a release branch from the past? Maybe this is not a big deal. OTOH if we hardcode a tag, it may create maintenance costs. I'm wondering if there is a better way, say to version and use the corresponding tag, say ?
Using tags would be a way to have more reproducible builds, they still need to be tagged from time to time tho. That is still better than using or micro managing commit revisions.
Thanks and for the research. Is either of you thinking on submitting a fix for this? Thanks!
I can do it.
Thanks! /assign mbobrovskyi
Yes, please don't use Generally instead we'd control the version of a tool in the hack/tools module and install it from there (see e.g.
This allows us to also gain for the package while not polluting the main module with dev-only dependencies.
Not sure if we need to make another Because it's not just a dev-only dependency. I propose to add it to of code-generator.
This is about semversioning
/triage accepted
Change:
} function expand-default-subnetwork() { <del> gcloud compute networks switch-mode "${NETWORK}"  --mode custom  </del> <ins> gcloud compute networks update "${NETWORK}"  --switch-to-custom-subnet-mode  </ins> --project "${NETWORK_PROJECT}"  --quiet || true gcloud compute networks subnets expand-ip-range "${NETWORK}" 

Discussion:
/kind bug What happened: Warning printed by : What you expected to happen: No warning. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: This is my first e2e cluster. Logs with more context below. Environment: Kubernetes version (use ): master Cloud provider or hardware configuration**: GCE OS (e.g. from /etc/os-release): Description: Ubuntu 14.04 LTS
This is probably an issue in the scripts.
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. Prevent issues from auto-closing with an comment. 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 has started failing in tests: https://k8s-
/shrug /milestone v1.10 /assign /assign /priority failing-test /priority critical-urgent /sig network /sig testing
I think this might be only in the staging gcloud release; at least doesn't mention this being removed.
and yeah, gce-canary is also using staging gcloud /shrug
/assign I'll fix kubetest, is patching k8s
/approved-for-milestone
/status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release.

</details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
/status in-review
should we close this issue since the PR merged?
waiting for , and that need to be cherrypicked into older releases
still need to cherrypick into previous releases
agreed, but isn't blocking 1.10 any more /milestone clear
cherrypick is done, closing /close
Change:
} httpClient := &http.Client{} parsedNodeIP := net.ParseIP(nodeIP) <ins> protocol := utilipt.ProtocolIpv4 if parsedNodeIP != nil && parsedNodeIP.To4() == nil { glog.V(0).Infof("IPv6 node IP (%s), assume IPv6 operation", nodeIP) protocol = utilipt.ProtocolIpv6 } </ins> klet := &Kubelet{ hostname:                       hostname,

Discussion:
/kind bug What happened: Kubelet uses "iptables" instead of "ip6tables" in an ipv6-only cluster. This causes failed traffic for services (and probably a lot of other problems). For instance the chain is created in but is missing in ; When a is assigned the fails; What you expected to happen: All components should use in a ipv6-only cluster. should work in an ipv6-only cluster. How to reproduce it (as minimally and precisely as possible): Start a ipv6-only cluster Check iptables Optional; try a service type: LoadBalancer Anything else we need to know?: is hard-coded in finc in "" Environment: Kubernetes version (use ):Cloud provider or hardware configuration: kvm VMs on Ubuntu 16.04 OS (e.g. from /etc/os-release): Own BusyBox system Kernel (e.g. ):Install tools: None Others:
/sig network
/area ipv6
Thanks for reporting this problem. I'll take a look.
is a link to the code with the hard-coded ipv4 protocol.
Thanks, I will send a pr to fix this issue.
/assign
I see this issue too. Also there is some related discussion with issue .
I just pulled the latest from master, and gave a try with IPv6 cluster, but I still see the error, when using kube-proxy + IPVS: E0829 16:51:56. 1 ] Failed to execute iptables-restore: exit status 2 (ip6tables-restore v1.4.21: The protocol family of set KUBE-LOOP-BACK is IPv4, which is not applicable. Were you able to try this with kube-proxy+IPVS?
Sorry, I didn't try ipv6 cluster with ipvs proxier. Those two issue are related, but not exactly the same issue. Seems we already have conclusion in , nobody working on that?
Change:
http.StatusSwitchingProtocols, ), ).Log() <ins> // monitor http requests var serverType string if s.auth == nil { serverType = "readonly" } else { serverType = "readwrite" } method, path, host := req.Method, trimURLPath(req.URL.Path), req.URL.Host longRunning := strconv.FormatBool(isLongRunningRequest(path)) servermetrics.HTTPRequests.WithLabelValues(method, path, host, serverType, longRunning).Inc() servermetrics.HTTPInflightRequests.WithLabelValues(method, path, host, serverType, longRunning).Inc() defer servermetrics.HTTPInflightRequests.WithLabelValues(method, path, host, serverType, longRunning).Dec() startTime := time.Now() defer servermetrics.HTTPRequestsDuration.WithLabelValues(method, path, host, serverType, longRunning).Observe(servermetrics.SinceInSeconds(startTime)) </ins> s.restfulCont.ServeHTTP(w, req) }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) add metrics into kubelet to monitor ; 2) add throttling to . Why is this needed: Kubelet provides lots of its functionalities through its http server, and currently there is no server-side monitoring and throttling mechanisms. Adding metrics into kubelet to monitor its http server will improve its observability and debuggability; adding throttling will prevent kubelet being overloaded from serving too many http requests.
/sig node
Change:
Attach          bool `json:"attach"` SELinuxRelabel  bool `json:"selinuxRelabel"` SupportsMetrics bool `json:"supportsMetrics"` <ins> FSGroup         bool `json:"fsGroup"` </ins> } func defaultCapabilities() *DriverCapabilities {

Discussion:
What happened: For some filesystems recursively applying an SELinux label through chcon or the GID permission is expensive (30 mins in some cases). There is better strategies for the recursive change and the call should be available through FLEX API. What you expected to happen: FLEX has a shell script call to label or set GID for a volume. Notes-- The fix should be backwards compatible.. If the shell call to perform the permission change is absent, then we fall back on the original method.
Change:
CPUDetails: CPUDetails, }, nil } <ins> // getUniqueCoreID computes coreId as the lowest cpuID // for a given Threads []int slice. This will assure that coreID's are // platform unique (opposite to what cAdvisor reports - socket unique) func getUniqueCoreID(threads []int) (coreID int, err error) { err = nil if len(threads) == 0 { return 0, fmt.Errorf("no cpus provided") } if len(threads) != cpuset.NewCPUSet(threads...).Size() { return 0, fmt.Errorf("cpus provided are not unique") } tmpThreads := make([]int, len(threads)) copy(tmpThreads, threads) sort.Ints(tmpThreads) return tmpThreads[0], err } </ins>

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: CPU Manager uses topology from cAdvisor which uses which is different from in terms of coreID's. assigns coreID's in unique manner (platform-wise) whereas has coreID's from CPU registers which are unique only on socket level. This causes some unexpected cpu assignment on platforms with more than one socket. All tests written all "false positive" Example output: From What you expected to happen: Fix either by changing the way CPU manger sees topology (use ) or redesign CPU Manager to handle coreID's as socket only unique How to reproduce it (as minimally and precisely as possible): kubelet on dual socket node G pod that requests 2 cores pod gets 2 cores on different sockets
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 node