jiebi/CodeConvo huggingface dataset:
Change:
api-endpoint = ${GCE_API_ENDPOINT} EOF fi <del> if [[ -n "${PROJECT_ID:-}" && -n "${TOKEN_URL:-}" && -n "${TOKEN_BODY:-}" && -n "${NODE_NETWORK:-}" ]]; then </del> <ins> if [[ -n "${TOKEN_URL:-}" && -n "${TOKEN_BODY:-}" ]]; then </ins> use_cloud_config="true" cat <<EOF >>/etc/gce.conf token-url = ${TOKEN_URL} token-body = ${TOKEN_BODY} <ins> EOF fi if [[ -n "${PROJECT_ID:-}" ]]; then use_cloud_config="true" cat <<EOF >>/etc/gce.conf </ins> project-id = ${PROJECT_ID} <del> network-name = ${NODE_NETWORK} </del> EOF <del> if [[ -n "${NETWORK_PROJECT_ID:-}" ]]; then cat <<EOF >>/etc/gce.conf </del> <ins> fi if [[ -n "${NETWORK_PROJECT_ID:-}" ]]; then use_cloud_config="true" cat <<EOF >>/etc/gce.conf </ins> network-project-id = ${NETWORK_PROJECT_ID} EOF <del> fi if [[ -n "${NODE_SUBNETWORK:-}" ]]; then cat <<EOF >>/etc/gce.conf </del> <ins> fi if [[ -n "${NODE_NETWORK:-}" ]]; then use_cloud_config="true" cat <<EOF >>/etc/gce.conf network-name = ${NODE_NETWORK} EOF fi if [[ -n "${NODE_SUBNETWORK:-}" ]]; then use_cloud_config="true" cat <<EOF >>/etc/gce.conf </ins> subnetwork-name = ${NODE_SUBNETWORK} EOF <del> fi </del> fi if [[ -n "${NODE_INSTANCE_PREFIX:-}" ]]; then use_cloud_config="true"

Discussion:
The "Services should be able to create an internal type load balancer [Slow]" e2e test is failing on our 2k-node gce clusters - https://k8s- with the following error: We're using custom subnets for our large cluster tests, and seems like the glbc controller is not able to handle them. cc
Seems similar to Assigning to you as you seem to have the context already :) Also, is this expected to be fixed in 1.8 timeframe?
doesn't set the necessary variables for the GCE cloud provider. Will throw you a PR.
Cool - thanks a lot!
Ref
I see the last test on 09/09 failed, but I can't see the build log due to exceeding memory. Any other way I can see the log, /reopen
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/network sig/scalability: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
nevermind - went directly to raw log.
Friendly ping. This e2e is still failing (https://k8s-) and it's part of release-blocking suite.
/close
Change:
// kep: https://kep.k8s.io/2876 // alpha: v1.23 // beta: v1.25 <ins> // stable: v1.29 </ins> // // Enables expression validation for Custom Resource CustomResourceValidationExpressions featuregate.Feature = "CustomResourceValidationExpressions"

Discussion:
This is the tracking issue of promoting CRD validation rules to GA: Listed the blocking issues/features below: [x] [x] [x] [x] Issues be aware of but should not be a GA blocker [ ] [ ] [ ] [ ] [ ] /sig api-machinery /triage accepted
/assign
/cc
Change:
cadvisormetrics.NetworkUsageMetrics:     struct{}{}, cadvisormetrics.AcceleratorUsageMetrics: struct{}{}, cadvisormetrics.AppMetrics:              struct{}{}, <ins> cadvisormetrics.ProcessMetrics:          struct{}{}, </ins> } if usingLegacyStats { includedMetrics[cadvisormetrics.DiskUsageMetrics] = struct{}{}

Discussion:
What happened: containersockets, containerthreads, containermaxthreads metrics were as part of Kubernetes 1.16 release. However, I only see 0 for these metrics. What you expected to happen: These metrics should give non-zero numbers. How to reproduce it (as minimally and precisely as possible): New cluster using Kubernetes 1.16.2 + Prometheus 2.11.1. Scraped containersockets, containerthreads, containermaxthreads metrics always return 0 Anything else we need to know?: Environment: Kubernetes version (use ): 1.16.2 Cloud provider or hardware configuration: Azure, cluster provisioned using aks-engine OS (e.g: ): Ubuntu Kernel (e.g. ): Install tools: aks-engine Network plugin and version (if this is a network-related bug): Others: /sig api-machinery /sig node
/cc /remove-sig api-machinery
It seems like this fix has only been merged into 1.17+. Is it possible to backport this fix into 1.16 as well? (I still see this issue in 1.16.9)
I am also seeing this issue in 1.6.9. Any possibility of backporting this fix to 1.16?
Also seeing this in 1.16.9, is there anything preventing this change from being backported?
/cc
Though we meant to enable process metrics in 1.16, we accidentally didn't. I consider the collection of new metrics a feature, and don't think it should be backported. It will likely cause some additional resource usage on the node, which isn't appropriate for a patch release.
Change:
}, }, }, <ins> expectedElements:   []string{"EndpointsNamespace", "<unset>"}, </ins> unexpectedElements: []string{"VolumeMode", "Filesystem"}, }, {

Discussion:
What happened: What you expected to happen: EndpointNamespace should be the string name of the namespace used. How to reproduce it (as minimally and precisely as possible): Create a glusterfs PV using an EndpointNamespace entry and run 'kubectl describe pv' on the resulting PV. Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-08-05T17:09:13Z", GoVersion:"go1.12.7", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-08-05T09:15:22Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Brightbox OS (e.g: ): Ubuntu 18.04.3 LTS Kernel (e.g. ): Linux bionic-vm 4.15.0-58-generic -Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm 1.15
/sig cli
/assign
Change:
utilruntime.Must(flowcontrolv1beta1.AddToScheme(scheme)) utilruntime.Must(flowcontrolv1beta2.AddToScheme(scheme)) utilruntime.Must(flowcontrolv1beta3.AddToScheme(scheme)) <del> // TODO(#112512): This controls serialization order, for 1.26, we can //  set the serialization version to v1beta2 because vN-1 understands that //  level. In 1.27, we should set the serialization version to v1beta3. utilruntime.Must(scheme.SetVersionPriority(flowcontrolv1beta2.SchemeGroupVersion, flowcontrolv1beta3.SchemeGroupVersion, </del> <ins> utilruntime.Must(scheme.SetVersionPriority(flowcontrolv1beta3.SchemeGroupVersion, flowcontrolv1beta2.SchemeGroupVersion, </ins> flowcontrolv1beta1.SchemeGroupVersion, flowcontrolv1alpha1.SchemeGroupVersion)) }

Discussion:
adds new version for in 1.26. For 1.26, we are setting the storage version to because vN-1 understands that level. In 1.27, we should change the storage version from to .
/sig api-machinery
/cc
/cc
/triage accepted
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:
klog.Error(err) return nil } <ins> if hist.Histogram == nil { klog.Errorf("metric %q is not a Histogram metric", metric) return nil } </ins> if err := hist.Validate(); err != nil { klog.Error(err) return nil

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: schedulerperf now is not able to support metrics other than "Histogram", if other type of "metrics" is configured in test, it will throw below exception, What you expected to happen: should show helpful error message instead of . How to reproduce it (as minimally and precisely as possible): Define testcase with in the config which includes a , for example. 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 scheduling
/assign
Change:
if v1helper.GetPersistentVolumeClass(volume) != requestedClass { continue } <ins> if !nodeAffinityValid { continue } </ins> if node != nil { // Scheduler path

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?: /assign What happened: Volume got bound to PV on node "kubernetes-minion-group-82c8" When the pod went back through scheduling, the predicate returned success for other nodes even though we should have updated the PV cache to point to the PVC: I think in , instead of continuing if the node affinity doesn't match, it should fail if the PV is prebound.
This causes two issues: On the second pass, the scheduler may choose a different node. Then in Assume/Bind volumes, we'll also prebind a second set of PVs. If the scheduler chose a different node on the second pass, and the PVCs became fully bound in between the predicates and assume volumes, then assume volumes will return success and the pod will get scheduled to the wrong node.
Change:
return 1 } <ins> kube::util::download_file() { local -r url=$1 local -r destination_file=$2 rm  ${destination_file} 2&> /dev/null || true for i in $(seq 5) do if ! curl -fsSL --retry 3 --keepalive-time 2 ${url} -o ${destination_file}; then echo "Downloading ${url} failed. $((5-i)) retries left." sleep 1 else echo "Downloading ${url} succeed" return 0 fi done return 1 } </ins> # ex: ts=2 sw=2 et filetype=sh

Discussion:
Sometimes e2e tests fails during cluster installation because curl fails with: For example see here: https://k8s- Downloading etcd failed. I've run curl to get etcd from github 4400 times. It failed 5 times. So it doesn't happen often.
Change:
{"GET", "/api", "", code200}, {"GET", "/healthz", "", code200}, {"GET", "/version", "", code200}, <ins> {"GET", "/invalidURL", "", code404}, </ins> } return requests }

Discussion:
Authenticated requests to master with an invalid URL path should return a non-status 200 response code. Preferably a 404 (not found). Sample output: { "paths": [ "/api", "/api/v1beta1", "/api/v1beta2", "/api/v1beta3", "/healthz", "/healthz/ping", "/logs/", "/metrics", "/static/", "/swagger-ui/", "/swaggerapi/", "/validate", "/version" ] }
Change:
pathOptions.EnvVar = "" buf := bytes.NewBuffer([]byte{}) cmd := NewCmdConfigUnset(buf, pathOptions) <del> cmd.SetArgs(test.args) if err := cmd.Execute(); err != nil { t.Fatalf("unexpected error executing command: %v,kubectl unset args: %v", err, test.args) </del> <ins> opts := &unsetOptions{configAccess: pathOptions} err = opts.complete(cmd, test.args) if err == nil { err = opts.run(buf) </ins> } config, err := clientcmd.LoadFromFile(fakeKubeFile.Name()) if err != nil { t.Fatalf("unexpected error loading kubeconfig file: %v", err) } <ins> if err != nil && err.Error() != test.expectedErr { t.Fatalf("expected error:n %vnbut got error:n%v", test.expectedErr, err) } </ins> if len(test.expected) != 0 { if buf.String() != test.expected { t.Errorf("Failed in :%qn expected %vn but got %v", test.description, test.expected, buf.String())

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): 1.5.3 Environment: Cloud provider or hardware configuration: minikube 0.17.1 How to reproduce it (as minimally and precisely as possible): config Note that there's only one context. the property of a non-existent context config Note that a context named foo was created just because I tried to unset a property. What you expected to happen: should give an informative message saying that context doesn't exist. Anything else we need to know: This is probably low-hanging fruit.
/sig cli
/assign i will take a look for this
GitHub didn't allow me to assign the following users: a, look, for, this, i, will, take. Note that only can be assigned. <detailsIn response to : /assign i will take a look for this 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
i can reproduce this, this is a bug, have open PR fix this. thanks
/kind bug
Change:
func loadWebhook(configFile string, groupVersion schema.GroupVersion, initialBackoff time.Duration, customDial utilnet.DialFunc) (*webhook.GenericWebhook, error) { w, err := webhook.NewGenericWebhook(audit.Scheme, audit.Codecs, configFile, []schema.GroupVersion{groupVersion}, initialBackoff, customDial) <ins> if err != nil { return nil, err } </ins> w.ShouldRetry = retryOnError <del> return w, err </del> <ins> return w, nil </ins> } type backend struct {

Discussion:
What happened: When parsing an audit webhook config file that errors (ca file does not exist), the apiserver will panic. What you expected to happen: Error gracefully with explanation to the error (ca authority does not exist). How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: we are assigning a null pointer when . We just need to add a standard before. Will follow up with a PR shortly. Environment: Kubernetes version (use ):kube-apiserver --version Kubernetes v1.19.0-alpha.0.597+ /kind bug /area apiserver
/sig api-machinery
Change:
if !isInternal && wantLb { // Confirm desired public ip resource exists var pip *network.PublicIPAddress <del> domainNameLabel := getPublicIPDomainNameLabel(service) if pip, err = az.ensurePublicIPExists(service, desiredPipName, domainNameLabel, clusterName, shouldPIPExisted); err != nil { </del> <ins> domainNameLabel, found := getPublicIPDomainNameLabel(service) if pip, err = az.ensurePublicIPExists(service, desiredPipName, domainNameLabel, clusterName, shouldPIPExisted, found); err != nil { </ins> return nil, err } return pip, nil

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:
rcInstance.volumesNeedUpdateFromNodeStatus = nil // Act 2 - reconcile once <del> rcInstance.reconcileNew() </del> <ins> rcInstance.reconcile() </ins> // Assert 2 // MountDevice was attempted

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 --We have even encountered such case that pod continuously reports “Unable to attach or mount volumes for pod;...” when kubelet restarted. The reasons are listed in details as below: , as result of apiserver instantaneous unstablility, dswp get pvc‘s pv spec failed, then the pvc volume does not be to dsw. , syncStates() lists all the volume directories locally, and recontructs the volume from local volume, if the volume isn't in dsw, it will put the recontructed volume to asw, but now the volume.OuterVolumeSpecName isn't correct. chance, at this time, In , the fail to pvc volume is to dsw again normally in reconcile() -mountAttachVolumes(), it compares dsw and asw by volume's innerVolumename, it's all the same. but it could not sense the OuterVolumeSpecName dismatch. so it will not re-mount again to update asw cache , it checks pod's volume attach or mount success by comparing volume.OuterVolumeSpecName and , but this pv'c OuterVolumeSpecName isn't correct in asw. so pod continuously reports “Unable to attach or mount volumes for pod;...” reconcile() could sense the reconstruct volume's dismatch to the dsw, then re-mount again to make volume cache consistency Kubernetes version (use ): 1.19.4 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
/triage accepted
/assign
CC
I think this is a point that can be optimized. /cc
I will give a fix for this
Thanks for reporting the issue, this innerSpecName and outerSpecName are confusing and cause issues. Please ping me for review when you have a fix. Thanks!
Please don't triage your own issues immediately, give someone else a chance to review them :( /sig storage
okay, I know
Change:
"k8s.io/klog" "k8s.io/kubernetes/pkg/features" schedulerlisters "k8s.io/kubernetes/pkg/scheduler/listers" <ins> "k8s.io/kubernetes/pkg/scheduler/metrics" </ins> schedulernodeinfo "k8s.io/kubernetes/pkg/scheduler/nodeinfo" nodeinfosnapshot "k8s.io/kubernetes/pkg/scheduler/nodeinfo/snapshot" )

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add a metric to track scheduler cache size. metric name Description -- -- schedulercachesize Number of elements in scheduler cache. Why is this needed: Gives better observability of scheduler cache. For, the number of "assumedpods" gives us an idea of how many pods are "assumed" and therefore being "bound". We can compare this with number of to make sure assume-bind works as expected. /sig scheduling
Is anyone already working on these metrics? If not I'd like to help out /assign
Thanks . Feel free to work on this one. Just a reminder, we may need feedback/approval from sig-instrumentation.
Change:
}) Context("CSI volume limit information using mock driver", func() { <del> It("should report attach limit when limit is bigger than 0", func() { </del> <ins> It("should report attach limit when limit is bigger than 0 [Slow]", func() { </ins> // define volume limit to be 2 for this test var err error

Discussion:
created a spread sheet of the slowest running tests for the pull-kubernetes-gce job. cc discussion on slack: spreadsheet: pie chart of test durations from SIGs: ! it seems appropriate to evaluate the state of the tests and reduce these runtimes. possibly move tests to periodic by marking them as [Slow]. /assign /kind design /area test (?)
/remove-kind bug
Are pull jobs the right place to be calculating the time? Or should be be counting in CI instead?
pull is the one timing out, so probably?
Looking at some of the top slowness:: subPath should fail for new directories when readOnly specified in the volumeSource: This test case is no longer defined in master HostPathType: This test case has not been checked in yet and is trying to be in a PR PersistentVolumes-local StatefulSet with pod affinity should use volumes spread across nodes when pod has anti-affinity: This test is already marked as slow in master
Created This should address most of the top slow storage tests
Change:
gcePDDetachPollTime = 10 * time.Second nodeStatusTimeout   = 10 * time.Minute nodeStatusPollTime  = 1 * time.Second <ins> podEvictTimeout     = 2 * time.Minute </ins> maxReadRetry        = 3 minNodes            = 2 ) var _ = SIGDescribe("Pod Disks", func() { var ( <ins> ns         string cs         clientset.Interface </ins> podClient  v1core.PodInterface nodeClient v1core.NodeInterface host0Name  types.NodeName

Discussion:
When pod is evicted, pod is terminated. After this change , attach/detach controller should be able to detach the pod correctly so that new pod which uses the same volume will start up. We need to have an e2e test for this scenario.
what environment is good for this e2e test? GCE or GKE or AWS? I see we have which has func, Can you comment on why is insufficient to cover this issue?
does the pod need to be evicted? Or would be ok to delete the pod and then check that the PD is detached. Then create a new pod using the same PD and test that it attaches?
[MILESTONENOTIFIER] Milestone Removed Important: This issue was missing labels required for the v1.9 milestone for more than 3 days: kind: Must specify exactly one of , or . <details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
ping ^^
sorry for the delay. Here we want to test the detach behavior of evicted pods. So delete a pod directly is different from it. When Pod is evicted, the containers will be killed and the pod status is terminated. But the pod api object is not deleted from API server. Before PR , such evicted pods will not trigger detach operation because the pod api object is not deleted from api server. So the purpose of the test is to make sure detach operation is triggered for such evicted pods.
Thanks Do you have a suggestion for how to force a pod to be evicted?
You could have the pod do some memory intensive application
ah, like my use of in the io-streaming pr :-)
- Here's another option to cause eviction: .