jiebi/CodeConvo huggingface dataset:
Change:
Service: &apiregistrationv1.ServiceReference{ Namespace: namespace, Name:      "sample-api", <del> Port:      pointer.Int32Ptr(aggregatorServicePort), </del> <ins> Port:      pointer.Int32(aggregatorServicePort), </ins> }, Group:                "wardle.example.com", Version:              "v1alpha1",

Discussion:
[X] Test approval issue: [X] Test PR: [x] Two weeks soak end date: [X] Test promotion PR: According to this APIsnoop query, there are still some remaining APIService endpoints which are untested. Using a number of existing e2e test practices the has to cover the outstanding APIService endpoints. There has been some around how the current Conformance test is using RBAC, which is optional and not part of Conformance. Those calls will now only happen if is true. The e2e logs for this test are listed below.

This query shows the following APIService endpoints are hit within a short period of running this e2e test example endpoint | useragent ---------------------------------------------+
createApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] deleteApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] deleteApiregistrationV1CollectionAPIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] listApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] patchApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] patchApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] readApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] readApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] replaceApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] replaceApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] (10 rows) If a test with these calls gets merged, test coverage will go up by 4 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
Change:
*/ framework.ConformanceIt("should function for intra-pod communication: udp [NodeConformance]", func() { config := e2enetwork.NewCoreNetworkingTestConfig(f, false) <del> for _, endpointPod := range config.EndpointPods { config.DialFromTestContainer("udp", endpointPod.Status.PodIP, e2enetwork.EndpointUDPPort, config.MaxTries, 0, sets.NewString(endpointPod.Name)) } </del> <ins> checkNodeConnectivity(config, "udp", e2enetwork.EndpointUDPPort) </ins> }) /*

Discussion:
What would you like to be : Right now we poll one node at a time for intra-pod tests. We ultimately fail a test if any one node is unreachable. If we instead polled all nodes, multiple times, and collected the number of times a node was unreachable, this would tell us what % of nodes on the cluster were broken, rather then just telling us the first node that was broken. not break the testing contract (were still verifying intra-pod connectivity, just doing so in a way that gives us holistic cluster info) Why is this needed: I described why this would make triage alot easier, and in general make it easier to see why tests are failing, here ... i'll collect a little more data on this to justify the decision .... as this is a conformance test so the bar for modification is higher (even if the test itself isnt changing) then regular tests.
/sig network
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
Namespace:       ns, ResourceVersion: "1", Labels: map[string]string{ <ins> "a":                  "b", </ins> v1.IsHeadlessService: "", }, },

Discussion:
bug (): Originally posted by in cc /sig network /priority critical-urgent
fix in
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Change:
if failSwapOn { // Check whether swap is enabled. The Kubelet does not support running with swap enabled. <del> swapData, err := ioutil.ReadFile("/proc/swaps") </del> <ins> swapFile := "/proc/swaps" swapData, err := ioutil.ReadFile(swapFile) </ins> if err != nil { <del> return nil, err } swapData = bytes.TrimSpace(swapData) // extra trailing n swapLines := strings.Split(string(swapData), "n") </del> <ins> if os.IsNotExist(err) { klog.Warningf("file %v does not exist, assuming that swap is disabled", swapFile) } else { return nil, err } } else { swapData = bytes.TrimSpace(swapData) // extra trailing n swapLines := strings.Split(string(swapData), "n") </ins> <del> // If there is more than one line (table headers) in /proc/swaps, swap is enabled and we should // error out unless --fail-swap-on is set to false. if len(swapLines) > 1 { return nil, fmt.Errorf("running with swap on is not supported, please disable swap! or set --fail-swap-on flag to false. /proc/swaps contained: %v", swapLines) </del> <ins> // If there is more than one line (table headers) in /proc/swaps, swap is enabled and we should // error out unless --fail-swap-on is set to false. if len(swapLines) > 1 { return nil, fmt.Errorf("running with swap on is not supported, please disable swap! or set --fail-swap-on flag to false. /proc/swaps contained: %v", swapLines) } </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: Kubelet doesn't start during , journalctl shows: What you expected to happen: Kubelet correctly identifies absence of as "no swap present", kubelet service starts and can finish. How to reproduce it (as minimally and precisely as possible): Build a Linux kernel with , install kubeadm, kubelet and try . Anything else we need to know?: No registered swap devices or a kernel without swap enabled both means that there is no swap space present. Kubectl successfully checks for the former case but throws an error on the later. Failure to open means no swap. Environment: Kubernetes version (use ): Hardware configuration: OS: Kernel: Install tools:
/sig cluster-lifecycle
this is a potential improvement for the kubelet. /sig node /remove-sig cluster-lifecycle
/assign
The issue can be worked around by adding to (defined in on Debian): /etc/default/kubelet
Change:
], tags = ["automanaged"], ) <ins> go_test( name = "go_default_test", srcs = ["humanreadable_test.go"], importpath = "k8s.io/kubernetes/pkg/printers", library = ":go_default_library", deps = [ "//pkg/api:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1alpha1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/runtime:go_default_library", ], ) </ins>

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: 1when error has occurwe should not print header 2 when i get ns use --all-namespaces, i get NAMESPACE column, we should return error: storageclass is not namespaced What you expected to happen: 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:
/assign
/sig cli
Change:
// for dynamic provisioning exists, the driver is expected to provide // capacity information for it. CapCapacity Capability = "capacity" <ins> // To support ReadWriteOncePod, the following CSI sidecars must be // updated to these versions or greater: // - csi-provisioner:v3.0.0+ // - csi-attacher:v3.3.0+ // - csi-resizer:v1.3.0+ CapReadWriteOncePod Capability = "readWriteOncePod" </ins> ) // DriverInfo represents static information about a TestDriver.

Discussion:
For the ReadWriteOncePod feature to graduate to beta, we need to have E2E test coverage for its current alpha behavior. See this section of KEP-2485 for more context on what cases we need to cover for alpha: This is a requirement for beta graduation, see:
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
Change:
}) } <ins> // RegisterMetrics registers a list of metrics. // This function is exported because it is intended to be used by out-of-tree plugins to register their custom metrics. func RegisterMetrics(extraMetrics ...metrics.Registerable) { for _, metric := range extraMetrics { legacyregistry.MustRegister(metric) } } </ins> // GetGather returns the gatherer. It used by test case outside current package. func GetGather() metrics.Gatherer { return legacyregistry.DefaultGatherer

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Support adding extra metrics for framework plugins Why is this needed: /sig scheduling
/assign
Change:
return err } <del> // With the goal of different controllers being able to manage different // subsets of EndpointSlices, LabelManagedBy has been added to indicate // which controller or entity manages an EndpointSlice. As part of this // v1.16->v1.17 change, EndpointSlices will initially be assumed to be // managed by this controller unless a label is set to indicate otherwise. // To ensure a seamless upgrade process, the managedBySetupAnnotation is // used to indicate that LabelManagedBy has been set initially for related // EndpointSlices. If it hasn't been set to the expected value here, we call // ensureSetupManagedByAnnotation() to set up LabelManagedBy on each // EndpointSlice. // TODO(robscott): Remove this before v1.18. err = c.ensureSetupManagedByAnnotation(service) if err != nil { c.eventRecorder.Eventf(service, v1.EventTypeWarning, "FailedToSetEndpointSliceManagedByLabel", "Error adding managed-by Label to Endpoint Slices for Service %s/%s: %v", service.Namespace, service.Name, err) return err } </del> esLabelSelector := labels.Set(map[string]string{ discovery.LabelServiceName: service.Name, discovery.LabelManagedBy:   controllerName,

Discussion:
What happened: kube-controller-manager panic for What you expected to happen: no panic. How to reproduce it (as minimally and precisely as possible): No idea. I guess it's hard to reproduce. Anything else we need to know?: Found from here: 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: /assign cc Should we do something for v1.17? (v1.17 code freeze now, but still have the opportunity to fix) can be removed safely in v1.18, right?
/sig scheduling
Working on this in /sig network /priority critical-urgent /assign
Sorry, I didn't realize it. I should have a search before firing an issue. I recommend adding this issue to your PR. e.g. `
Updated, thanks!
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
This seems to be writing to a cached (should be const) service. I think we need to DeepCopy() it before we mutate the Go type. does that sound right? Is this still our best state of the art?
yes, copy before change
we have a tool to catch this (the cache mutation detector), but it got disabled in our test runs two years ago (xref )
yes great catch - I was always convinced this is enabled...
Change:
informerFactory.Start(stop) go hpaController.Run(stop) <ins> // Wait for HPA to be processed. <-tc.processed </ins> tc.Lock() <ins> tc.finished = true </ins> if tc.verifyEvents { tc.Unlock() // We need to wait for events to be broadcasted (sleep for longer than record.sleepDuration).

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: Resync period for HorizontalPodAutoscaler controller is set to 15 seconds in order to update HPAs every 15 seconds. Sometimes updates are skipped and period between two updates is 30 seconds. What you expected to happen: HPA should be updated every 15 seconds. How to reproduce it (as minimally and precisely as possible): Add debugs to HPA controller showing how often HPAs are processed. Create HPA. Anything else we need to know?: HPA controller uses rate RateLimitingQueue: New requests are always with 15 seconds delay: If request for the given HPA is in the queue then newly request is skipped. Requests are and removed from the queue at the same moment so there is a race condition. See following scenario: 00:00:00 - Resync adds request to queue to be executed at 00:00:15 00:00:15 - Resync adds next request to queue to be executed at 00:00:30 but it is skipped because previous request is still in the queue 00:00:15 - Request at 00:00:00 is executed 00:00:30 - Resync adds next request to queue to be executed at 00:00:45 00:00:45 - Request at 00:00:30 is executed In above scenario HPA wasn't updated between 00:00:15 and 00:00:45. Environment: Kubernetes version (use ): HEAD Cloud provider or hardware configuration: GKE <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig autoscaling
/assign krzysztof-jastrzebski
Change:
} var nodeCIDRMaskSizeIPv4, nodeCIDRMaskSizeIPv6 int <del> if utilfeature.DefaultFeatureGate.Enabled(features.IPv6DualStack) { </del> <ins> if dualStack { </ins> // only --node-cidr-mask-size-ipv4 and --node-cidr-mask-size-ipv6 supported with dual stack clusters. // --node-cidr-mask-size flag is incompatible with dual stack clusters. nodeCIDRMaskSizeIPv4, nodeCIDRMaskSizeIPv6, err = setNodeCIDRMaskSizesDualStack(ctx.ComponentConfig.NodeIPAMController) } else { // only --node-cidr-mask-size supported with single stack clusters. <del> // --node-cidr-mask-size-ipv4 and --node-cidr-mask-size-ipv6 flags are incompatible with dual stack clusters. </del> <ins> // --node-cidr-mask-size-ipv4 and --node-cidr-mask-size-ipv6 flags are incompatible with single stack clusters. </ins> nodeCIDRMaskSizeIPv4, nodeCIDRMaskSizeIPv6, err = setNodeCIDRMaskSizes(ctx.ComponentConfig.NodeIPAMController) }

Discussion:
With the feature gate disabled, kube-controller-manager accepts a argument, but with enabled, it only accepts and and rejects . This blocks moving dual-stack to beta, since switching the feature gate to on-by-default would break existing single-stack clusters using . /cc /sig network /priority important-soon
let me tag too, IIRC he implemented it and may be is more familiar with this
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
"k8s.io/apiserver/pkg/authentication/request/bearertoken" bootstrapapi "k8s.io/cluster-bootstrap/token/api" "k8s.io/kubernetes/plugin/pkg/auth/authenticator/token/bootstrap" <del> bootstraputil "k8s.io/kubernetes/test/e2e/lifecycle/bootstrap" </del> "k8s.io/kubernetes/test/integration" "k8s.io/kubernetes/test/integration/framework" )

Discussion:
Originally tracked at . After fixing "not include test files in import-boss" in , we have a regression here: is using . We need remove dependencies from integration tests to e2e tests again. /assign /sig testing
/sig auth as per the required change
/kind cleanup /area test
It would be helpful to outline an argument as to why this is the case. I can imagine reasons, but none are mentioned here.
Description updated.
/triage accepted /priority backlog /milestone v1.21 This seems a simple enough fix to land (and thank you for doing this) but marking low enough priority to make it clear we may back out and wait for v1.22 if we don't have bandwidth for this
So while I think we should probably do this anyhow I want to note: This issue lists the reasons: we have no intention to stage e2e (there's been much discussion about this since then) we generally don't want anything non-informational (required jobs) running only sometimes anyhow, it's just not reliable Decoupling these seems like a good idea from a purely code-organization perspective, but the reasons in the previous issue are no longer valid.
/milestone v1.22 The PR didn't land in time. At this point I view this as nice to have. Even if it's low impact, let's wait until next release.
Change:
<ins> #!/bin/bash set -e set -x CGO_ENABLED=0 go build  -a -ldflags '-extldflags "-static" -s' hello.go </ins>

Discussion:
/kind feature Hey, in K8s 1.23 we are planning to deprecate multiple klog flags. Deprecated flags: , , , , , , , , , , , One of the alpha milestones is requires us to remove usage of deprecated flags within K8s repo. Examples found for kubemark [x] [x] [x] [x] Recommendation, either: Stop depending on writing to files and remove flags , or Add go-runner to kubemark image and migrate to /sig scalability /wg structured-logging
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
/assign
Resolved in both k/k and kubernetes-sigs/cloud-provider-azure. /close
Change:
// Obtain Load Balancer Ingress IPs var ips []string for _, ing := range service.Status.LoadBalancer.Ingress { <del> ips = append(ips, ing.IP) </del> <ins> if ing.IP != "" { ips = append(ips, ing.IP) } </ins> } if len(ips) > 0 {

Discussion:
Originally post on project <!-- Thanks for helping us to improve K3S! We welcome all bug reports. Please fill out each area of the template so we can better help you. Comments like this will be hidden when you post but you can delete them if you wish. --Environmental Info: K3s Version: v1.21.0+k3s1 <!-- Provide the output from "k3s -v" --Node(s) CPU architecture, OS, and Version: Linux 4.19.0-16-cloud-amd64 SMP Debian 4.19.181-1 (2021-03-19) x86_64 <!-- Provide the output from "uname -a" on the node(s) --Cluster Configuration: 1 server & 3 agents <!-- Provide some basic information on the cluster configuration. For example, "3 servers, 2 agents". --Describe the bug: I use an external cloud controller manager to manage load balancing and services exposition. But on my services spec, I have no field but a instead. Everything works fine but server logs are flooded with entries like <!-- A clear and concise description of what the bug is. --Steps To Reproduce: <!-- Steps to reproduce the behavior. Please include as the first step how you installed K3s on the node(s) (including all flags or environment variables). If you have customized configuration via systemd drop-ins or overrides () please include those as well. --- Installed K3s: Use an external CCM which only provide a hostname to expose service Expected behavior: No more logs like <!-- A clear and concise description of what you expected to happen. --Actual behavior: Server logs are flooded with entries like <!-- A clear and concise description of what actually happened. --Additional context / logs: <!-- Add any other context and/or logs about the problem here. --Should it be a good idea to test consistency of IP here : or here ?
/sig cloud-provider
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /wg structured-logging 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
/sig network
/assign
could you help to triage this issue? Since still have label
/triage accepted Seems like a missing check for ""
Change:
if pvc.Spec.VolumeMode != nil { w.Write(LEVEL_0, "VolumeMode:t%vn", *pvc.Spec.VolumeMode) } <ins> if pvc.Spec.DataSource != nil { w.Write(LEVEL_0, "DataSource:n") w.Write(LEVEL_1, "Name:t%vn", pvc.Spec.DataSource.Name) w.Write(LEVEL_1, "Kind:t%vn", pvc.Spec.DataSource.Kind) } </ins> printPodsMultiline(w, "Mounted By", mountPods) if len(pvc.Status.Conditions) > 0 {

Discussion:
Currently there's now way for a user to check what they entered in the DataSource field of a PVC create request. In the past, this wasn't as confusing because if one were to submit invalid info (unsupported Kind) the verification checks would fail and the request would be rejected with a helpful message indicating why. As of 1.14 that's no longer the case, a user is able to put anything they wish in these fields and the create is performed and they get a PVC, and there's no way for them to see what is or isn't set. Adding output of DataSource to would be useful, not only for invalid cases where the input might just get eaten, but also for users to have the ability to check for originating sources of their PVCs.
/sig storage
/assign
GitHub didn't allow me to assign the following users: me. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign me 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
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