jiebi/CodeConvo huggingface dataset:
Change:
}, metricsName: "scheduler_pending_pods", wants: ` <del> # HELP scheduler_pending_pods [ALPHA] Number of pending pods, by the queue type. 'active' means number of pods in activeQ; 'backoff' means number of pods in backoffQ; 'unschedulable' means number of pods in unschedulableQ. </del> <ins> # HELP scheduler_pending_pods [STABLE] Number of pending pods, by the queue type. 'active' means number of pods in activeQ; 'backoff' means number of pods in backoffQ; 'unschedulable' means number of pods in unschedulableQ. </ins> # TYPE scheduler_pending_pods gauge scheduler_pending_pods{queue="active"} 15 scheduler_pending_pods{queue="backoff"} 25

Discussion:
I would like to propose the graduation of the following scheduler metrics from alpha to stable: These metrics have been stable for at least 15 months.
/sig scheduling /sig instrumentation
/cc
IIRC, the last addition to these metrics was the profile name label. I don't foresee need for new labels. I don't see many precedents for graduation in core components. are there any defined criteria for graduation?
As requested, the following is how long it has been since a change has been made to each of the requested metrics: - 2 years; last change was to migrate to the metrics stability framework - 17 months; last change was a renaming of the metric - 15 months; last change was a renaming of the metric - 17 months; last change was to add a label - 17 months; last change was to add a label
It's up to the component owners to commit to graduating these metrics, since the component owners own the metrics and therefore need to agree to support them in accordance to stability requirements. If you guys are okay with promoting these metrics, I don't see a reason, from an instrumentation side, why we would object to promotion.
+1 to graduation then. These metrics are very mature. Although, I'm not sure if all metrics already adhere to naming conventions. and don't have a unit suffix, but they are unit-less. Is that fine
is a gauge so it's fine, is a histogram so it's also fine.
I'm recently working with metrics, I'm glad to provide some help if no one has interest about it.
There is already an open PR for this.
Oh sorry, didn't notice about that. Forget it.
These graduations sound good to me, but I would be inclined to rename . I feel that the part of the metric is unnecessary. Having instead and keeping for the algorithm latency is already descriptive enough to know the difference between both. If that's not the case, then the text of the metric can be used to guide the users.
I agree that is rather confusing, so +1 to removing the prefix. The metric doesn't include retries, for example. We have a separate metric that includes retries: We need to rename that one eventually to e2e, but it can only be done after the existing one has been deprecated and deleted for a few releases. /triage accepted
/assign
/cc
The PR for this is ready to be reviewed:
Change:
InitSnapshottableTestSuite, InitSnapshottableStressTestSuite, InitVolumePerformanceTestSuite, <ins> InitReadWriteOncePodTestSuite, </ins> ) func getVolumeOpsFromMetricsForPlugin(ms testutil.Metrics, pluginName string) opCounts {

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:
svcName := fmt.Sprintf("%s.%s.svc.%s", svc.Name, svc.Namespace, framework.TestContext.ClusterDNSDomain) // Service must resolve to IP cmd := fmt.Sprintf("nslookup %s", svcName) <del> _, stderr, err := framework.RunHostCmdWithFullOutput(pod.Namespace, pod.Name, cmd) // NOTE(claudiub): nslookup may return 0 on Windows, even though the DNS name was not found. In this case, // we can check stderr for the error. if err != nil || (framework.NodeOSDistroIs("windows") && strings.Contains(stderr, fmt.Sprintf("can't find %s", svcName))) { return fmt.Errorf("ExternalName service %q must resolve to IP", pod.Namespace+"/"+pod.Name) } return nil </del> <ins> return wait.PollImmediate(framework.Poll, ServiceReachabilityShortPollTimeout, func() (done bool, err error) { _, stderr, err := framework.RunHostCmdWithFullOutput(pod.Namespace, pod.Name, cmd) // NOTE(claudiub): nslookup may return 0 on Windows, even though the DNS name was not found. In this case, // we can check stderr for the error. if err != nil || (framework.NodeOSDistroIs("windows") && strings.Contains(stderr, fmt.Sprintf("can't find %s", svcName))) { framework.Logf("ExternalName service %q failed to resolve to IP", pod.Namespace+"/"+pod.Name) return false, nil } return true, nil }) </ins> } // CheckServiceReachability ensures that request are served by the services. Only supports Services with type ClusterIP, NodePort and ExternalName.

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: - Which test(s) are flaking: Testgrid link: https://k8s- https://k8s- Reason for failure: Anything else we need to know: Having some trouble with finding this in Triage, but here are two example failures: /sig network <!-- Please see the deflaking doc () for more guidance! --
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 I'll take time to see it.
Any updates on this? Should we triage-accept it?
Change:
FakeMemoryCapacity     = 4026531840 FakeKernelVersion      = "3.16.0-0.bpo.4-amd64" FakeContainerOsVersion = "Debian GNU/Linux 7 (wheezy)" <del> FakeDockerVersion      = "1.5.0" </del> <ins> FakeDockerVersion      = "1.13.1" </ins> ) var _ cadvisor.Interface = new(Fake)

Discussion:
The current node e2e tests include images using Docker 1.11.x to , with the pending PR to test 18.06 () We should update the images to drop older docker versions. I think we can start by getting rid of 1.11 and 1.12, so that we still have three minor versions tested: , , and 1.13.x /cc (for cos and ubuntu)
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
/assign Yang, could you take a look? Thanks
Change:
) var ( <ins> NodeName = prometheus.NewGaugeVec( prometheus.GaugeOpts{ Subsystem: KubeletSubsystem, Name:      NodeNameKey, Help:      "The node's name. The count is always 1.", }, []string{NodeLabelKey}, ) </ins> ContainersPerPodCount = prometheus.NewSummary( prometheus.SummaryOpts{ Subsystem: KubeletSubsystem,

Discussion:
What would you like to be : It would be useful if the kubelet exported a metric that contained its own name as a label, for instance: . This name should be consistent with the output of . Why is this needed: This would allow us to join the kubelet metrics against metrics exported by kube-state-metrics. An example of this can be seen in We've arranged in our cluster for the labels to be set to the node's name, but this is controlled by Prometheus and depends on your scrape & relabelling config. As such, in general we can't rely on this to be the case - for instance, with the prometheus-operator the label is a IP:Port combo. /cc
/sig instrumentation
This metric as it is right now doesn’t conform to the instrumentation guidelines, so yes we should changes this as part of the metrics overhaul targeted for 1.14.
you mean to add a label in kubelet metrics ?
precisely.
/assign
Change:
package clientbuilder import ( <ins> "k8s.io/client-go/discovery" </ins> clientset "k8s.io/client-go/kubernetes" restclient "k8s.io/client-go/rest" "k8s.io/klog/v2"

Discussion:
Ran kube-controller-manager with and observed this in the log every 30 seconds: This is also happening in 1.20, 1.19, and 1.18 The GC and quota clients look up discovery information every 30 seconds. They have a QPS of 20 requests per second and a burst of 30 requests. Default configuration of kube-controller-manager runs without constant throttling warnings. /sig api-machinery
/assign /triage accepted
Change:
}, } <del> for _, test := range tests { </del> <ins> for ix, test := range tests { </ins> glog.V(4).Infof("starting test %q", test.name) // Initialize the controller

Discussion:
Not many details in the logs: FAIL 2.721s
I ran tests a few times against recent master but couldn't see this, could it be an edgy case?
i'll look at it
should help a lot, still there will be a short window where the test could get wrong. Patch will follow when is merged.
Today I saw a very similar error to the one reported in , but seeing as that was closed as a dupe of this, adding details here:
this looks like something new. Let's keep this issue open for this unit test flake: I filled for integration test flake you reported.
Change:
podutil.VisitPodSecretNames(pod, func(name string) bool { hasSecrets = true return false <del> }) </del> <ins> }, podutil.AllContainers) </ins> if hasSecrets { return admission.NewForbidden(a, fmt.Errorf("a mirror pod may not reference secrets")) }

Discussion:
Fully described in , and will visit these fields for all containers, regardless of whether they're hidden behind a feature gate (e.g. ). This is usually correct, these methods are often used to drop fields and in this case should visit all containers that are persisted regardless of whether they're disabled, but the callers of these methods should signal that explicitly rather than relying on the implicit behavior. /cc /priority important-longterm /kind bug /sig node
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : Fully described in , and will visit these fields for all containers, regardless of whether they're hidden behind a feature gate (e.g. ). /priority important/long-term /kind bug /sig node 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
are you interested in taking this one, too?
VisitPodSecretNames and VisitPodConfigmapNames already specify AllContainers for VisitContainers Can you let me know what else needs to be done?
Callers should specify whether they want to visit all containers or not. There are valid reasons for each, so we shouldn't assume the desired behavior, even if 100% of the current users want to visit all containers. Jordan's original comment in has some examples of current uses. I don't think this needs to be as configurable as , so my naive first attempt to implement this would probably just be a new to and
Change:
- [Cluster Requirements](#cluster-requirements) - [Decide where you will store your data](#decide-where-you-will-store-your-data) - [Host Path](#host-path) <ins> - [SELinux](#selinux) </ins> - [GCE Persistent Disk](#gce-persistent-disk) - [Create the MySQL Password Secret](#create-the-mysql-password-secret) - [Deploy MySQL](#deploy-mysql)

Discussion:
Version: Running this example on RHEL 7.2 (assume same for centos), and using hostPath, I get a permissions error when the mysql container does a . If I set selinux to permissive on the host it works. If I manually run the container with it works. I was not able to get it to work when adding to the deployment. My fix was to locate the PVs in by changing the local- file, and doing . I this comment to local- If this issue is valid I will create a quick PR to doc this selinux solution.
See pr
Change:
rbac.NewClusterBinding("system:kube-controller-manager").Users(user.KubeControllerManager).BindingOrDie(), rbac.NewClusterBinding("system:kube-dns").SAs("kube-system", "kube-dns").BindingOrDie(), rbac.NewClusterBinding("system:kube-scheduler").Users(user.KubeScheduler).BindingOrDie(), <ins> rbac.NewClusterBinding("system:aws-cloud-provider").SAs("kube-system", "aws-cloud-provider").BindingOrDie(), </ins> // This default binding of the system:node role to the system:nodes group is deprecated in 1.7 with the availability of the Node authorizer. // This leaves the binding, but with an empty set of subjects, so that tightening reconciliation can remove the subject.

Discussion:
Recently introduced fix of tainting the node if EBS volume on a node is stuck for too long in "attaching" state does not work on RBAC enabled clusters because of missing service account permissions. /sig storage /sig aws
Change:
Time_Key    timestamp Time_Format %Y-%m-%dT%H:%M:%S.%L%z <del> # ---------- [PARSER] Name   json Format json Time_Key time Time_Format %d/%b/%Y:%H:%M:%S %z [PARSER] Name         docker Format       json Time_Key     time Time_Format  %Y-%m-%dT%H:%M:%S.%L Time_Keep    On </del> [PARSER] Name        syslog-rfc5424 Format      regex

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 --The default fluent-bit configuration for GCE Windows nodes produces unparsed JSON logs and does not forward container logs. Container log output is produced. fluent-bit on a given windows image. a GCE Windows e2e cluster and view the stackdriver output for pods. Kubernetes version (use ): 1.20+ Cloud provider or hardware configuration: GKE/GCE OS (e.g: ): Windows Kernel (e.g. ): Any version Install tools: fluent-bit Network plugin and version (if this is a network-related bug): Others:
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
Change:
func TestEnsurePublicIPExists(t *testing.T) { testCases := []struct { <del> desc          string existingPIPs  []network.PublicIPAddress expectedPIP   *network.PublicIPAddress expectedID    string expectedDNS   string expectedError bool </del> <ins> desc                    string existingPIPs            []network.PublicIPAddress inputDNSLabel           string foundDNSLabelAnnotation bool expectedPIP             *network.PublicIPAddress expectedID              string expectedError           bool </ins> }{ { desc:         "ensurePublicIPExists shall return existed PIP if there is any",

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: After issue is fixed. Cloud provider will automatically reconcile the Azure Public Ip DNS record same as the service annotation. As a result, user finds their DNS record will be deleted if the annotation is not set. Such a change is a block to users who have set the DNS record on their public IP without using this annotation when they upgrade the cluster. Besides, if the public ip is a user's own public ip, it is also not reasonable to delete the DNS record. What you expected to happen: We may need to change the reconcile logic. Maybe only delete the DNS record, when the annotation exists but empty value How to reproduce it (as minimally and precisely as possible): Manually add the DNS label to Azure Public IP resource via Portal Environment: Kubernetes version (use ): 1.15.7 Cloud provider or hardware configuration: Azure
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig Azure 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 cloud-provider
/area provider/azure
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig Azure 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
/assign
The fix helm install helm-nginx-ingress stable/nginx-ingress  --namespace ingress-nginx-ns  --set controller.replicaCount=2  --set controller.nodeSelector."beta.kubernetes.io/os"=linux  --set controller.service.annotations."service.beta.kubernetes.io/azure-dns-label-name"=MY-AZURE-DNS  --set defaultBackend.nodeSelector."beta.kubernetes.io/os"=linux
Change:
} pv.Spec.Capacity = v1.ResourceList{ <del> v1.ResourceName(v1.ResourceStorage): resource.MustParse(fmt.Sprintf("%dGi", sizeGB)), </del> <ins> v1.ResourceName(v1.ResourceStorage): resource.MustParse(fmt.Sprintf("%dG", sizeGB)), </ins> } return pv, nil }

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: Create 50Gi podVolumeClaim with glusterfs provisioner. What you expected to happen: I expected 50Gi volume would be created, instead of 54Gi. How to reproduce it (as minimally and precisely as possible): storage class with glusterfs as dynamic provisioner. podVolumeClaim. Anything else we need to know?: Commit, that cause it: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig storage
Is it better to check binary/decimal format?
make sense
The bug doesn't exist in the commit you linked. Heketi can't provision volume in chunks of GiB that you are requesting, so it is never going to provision 50GiB if you asked for 50GiB. It will round the value upto GB and provision it. For example, if you are asking for 50GiB it will provision 51GiB after rounding upto to GBs. The problematic line in code is - That line incorrectly assumes returned integer from function to be in GiB whereas it is in GB, it should be relatively easy to change that line. So If you request 50GiB it will give you 54GB and 51GiB.
Yeah, inside the container i got:
Yep, the problem is in how the size is represented in PV. can you make a PR for fixing it?
Yes, it would be great.
Completely agree to what wrote. thanks for the PR.
/assign
Change:
docker run --rm --privileged multiarch/qemu-user-static:register --reset curl -sSL --retry 5 https://github.com/multiarch/qemu-user-static/releases/download/v2.5.0/x86_64_qemu-${QEMUARCH}-static.tar.xz | tar -xJ -C ${TEMP_DIR} endif <del> # This cross-compiles cni for all architectures # TODO(freehan): Push the latest cni for all arches to storage.googleapis.com so we may just download the binaries docker run -it -v ${TEMP_DIR}/cni-bin:/cnibin golang:1.6 /bin/bash -c " git clone https://github.com/containernetworking/cni  && cd cni  && git checkout $(CNI_RELEASE)  && GOARCH=$(ARCH) ./build  && cp bin/* /cnibin" </del> <ins> # Download CNI curl -sSL --retry 5 https://storage.googleapis.com/kubernetes-release/network-plugins/cni-${ARCH}-${CNI_RELEASE}.tar.gz | tar -xz -C ${TEMP_DIR}/cni-bin </ins> docker build -t ${REGISTRY}/hyperkube-${ARCH}:${VERSION} ${TEMP_DIR} rm -rf "${TEMP_DIR}"

Discussion:
We should update cni binaries to containernetworking/cni and release binaries for all arches. I do not have push access to the repo, so I guess some googler have to do it.
Thanks. I have this on my plate.
Change:
"time" "k8s.io/api/core/v1" <ins> apiequality "k8s.io/apimachinery/pkg/api/equality" </ins> "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels"

Discussion:
Currently, endpoints objects containing no subsets are decoded by the go client as subsets:[] (when requested individually) or as subsets:null (when requested in a list of endpoints). Because the endpoints controller is fed via a lister/watcher, it gets the subsets:null version fed to it. The subsets computation then returns an empty slice, which fails reflect.DeepEqual, which triggers a write attempt
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
Change:
1. Docker, using one of the following configurations: * **macOS** You can either use Docker for Mac or docker-machine. See installation instructions [here](https://docs.docker.com/docker-for-mac/). <del> **Note**: You will want to set the Docker VM to have at least 3GB of initial memory or building will likely fail. (See: [#11852]( http://issue.k8s.io/11852)). </del> <ins> **Note**: You will want to set the Docker VM to have at least 4.5GB of initial memory or building will likely fail. (See: [#11852]( http://issue.k8s.io/11852)). </ins> * **Linux with local Docker**  Install Docker according to the [instructions](https://docs.docker.com/installation/#installation) for your OS. * **Remote Docker engine** Use a big machine in the cloud to build faster. This is a little trickier so look at the section later on. 2. **Optional** [Google Cloud SDK](https://developers.google.com/cloud/sdk/)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Current instruction state that Kubernetes requires 3GB to build in Docker on osx. Attempting to build () with 3GB, 3.5GB, and 4.0GB fail. What you expected to happen: I expect osx users to be able to build Kubernetes, and the instructions to indicate that at least 4.5GB of memory are required. How to reproduce it (as minimally and precisely as possible): On osx setup docker with 3GB memory, and then attempt to build Kubernetes () and it will fail. Anything else we need to know?: Environment: Kubernetes version (use ): upstream/master OS (e.g. from /etc/os-release): osx - 10.13.4
/sig contributor-experience
/sig docs