jiebi/CodeConvo huggingface dataset:
Change:
return nil, err } <ins> updateService := updateServiceLoadBalancerIP(service, to.String(serviceIP)) flippedService := flipServiceInternalAnnotation(updateService) if _, err := az.reconcileLoadBalancer(clusterName, flippedService, nil, false /* wantLb */); err != nil { return nil, err } if _, err := az.reconcilePublicIP(clusterName, updateService, true /* wantLb */); err != nil { return nil, err } </ins> return lbStatus, nil }

Discussion:
/kind bug What happened: ILB Frontend IP configuration does not change while updating service What you expected to happen: LB Frontend IP configuration should get updated How to reproduce it (as minimally and precisely as possible): Source issue : AKS service is created using .yaml manifest. ILB is described as it is shown in the documentation: annotations: "true" spec: ports: port: 80 type: LoadBalancer loadBalancerIP: 10.240.200.2 ILB instance with the "kubernetes-internal" name is created with a correct private IP address pointing to the service described. If I change the "loadBalancerIP" to another internal IP address and re-deploy the service, the last is deployed with the correct new IP address, but "kubernetes-internal" ILB still has the old Frontend IP configuration. Environment: Cloud provider or hardware configuration: Azure
/sig azure
This also not works for public LB. /cc Could you fix the bug and cherry pick to old versions?
I got this bug today, I changed the external LoadBalancerIP on a LoadBalancer service. The service event log showed that it immediately recognised the change ("oldIP =newIP") but I had to delete/recreate the service to see the change in the Azure loadbalancer.
Change:
} urlRewriter := func(targetUrl string) string { <del> return t.rewriteURL(targetUrl, req.URL) </del> <ins> return t.rewriteURL(targetUrl, req.URL, req.Host) </ins> } err := rewriteHTML(reader, writer, urlRewriter) if err != 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: When accessing a service (e.g., ) by using the Apiserver proxy feature and the service returns with header, such as The returned header does not preserve the path if the service sent a redirect with an absolute path. Depending on the cluster, the header written by the service itself might have been and the apiserver proxy did rewrite the host:port to match the correct values. Unfortunately, it did not rewrite the path segment. What you expected to happen: I would expect the apiserver to rewrite the path segment of the response header so that it reflects the fact that it's proxied under the path: How to reproduce it (as minimally and precisely as possible): The path was not preserved. Anything else we need to know?: To work around this issue, a service may return strictly a relative url in the header such as: The feature to rewrite headers is quite common. For instance, Apache Httpd does it thanks to: Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: custom_ OS (e.g. from /etc/os-release): Kernel (e.g. ):
/sig api-machinery /sig network
/assign
Thanks for the bug report!
GitHub didn't allow me to assign the following users: roycaihw. Note that only can be assigned. <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
return nodeAddresses(srv) } <del> func getAddressByName(client *gophercloud.ServiceClient, name types.NodeName) (string, error) { </del> <ins> func getAddressByName(client *gophercloud.ServiceClient, name types.NodeName, needIPv6 bool) (string, error) { </ins> addrs, err := getAddressesByName(client, name) if err != nil { return "", err

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The Kubernetes master created routes in the neutron router that assign an IPv6 nexthop for a IPv4 prefix. This is not possible and causes a reachability problem between the pods. Example route: What you expected to happen: When describing a node the master has the following information It should detect the address type and choose the correct InternalIP How to reproduce it (as minimally and precisely as possible): Deploy on a Openstack cloud with IPv6 enabled using the following playbook Anything else we need to know?: The wrong next hop is coming from calling the function and nowhere is a check if the address is IPv4 or IPv6 Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Openstack OS (e.g. from /etc/os-release): Ubuntu Xenial Kernel (e.g. ):Install tools: Others: /sig openstack
- Thank you for this detailed analysis. Seems to me that the best way to address this would be to add an IP family argument to getAddressByName() to let it know what V4/V6 family to look for for a next-hop address. In the calls to getAddressByName(), this argument could be set based on the family of route.DestinationCIDR.
Issue is probably related.
Change:
# $5: pod name, which should be either etcd or etcd-events function prepare-etcd-manifest { local host_name=${ETCD_HOSTNAME:-$(hostname -s)} <del> local host_ip=$(python -c "import socket;print(socket.gethostbyname("${host_name}"))") </del> <ins> local host_ip=$(${PYTHON} -c "import socket;print(socket.gethostbyname("${host_name}"))") </ins> local etcd_cluster="" local cluster_state="new" local etcd_protocol="http"

Discussion:
What happened: Pick an OS image where python is python3 and the cluster will not come up. What you expected to happen: Cluster should come up. How to reproduce it (as minimally and precisely as possible): Switch the default OS image to use an OS which has python3 as the default python. Run cluster/kube- for GCE. 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 cloud-provider
/assign
Change:
if err == nil { t.Fatalf("expected error but got none") } <del> if tt.errorContains != "" { if !strings.Contains(err.Error(), tt.errorContains) { t.Errorf("expected an error saying %q, but got: %v", tt.errorContains, err) </del> <ins> expected := false if len(tt.errorContainsAnyOf) != 0 { for _, errStr := range tt.errorContainsAnyOf { if strings.Contains(err.Error(), errStr) { expected = true break } </ins> } } <ins> if !expected { t.Errorf("expected the error to be any of %q, but got: %v", tt.errorContainsAnyOf, err) } </ins> return }

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: (regardlessoffailurepolicy)and_fail Testgrid link: Reason for failure: and Anything else we need to know: Spyglass: <!-- Please see the deflaking doc () for more guidance! --
/sig api-machinery /area apiserver
Can confirm this PR:
/assign
/triage accepted
The kube-apiserver processing flow is as follows, (non-critical paths are omitted) ... // other filters parse the http client timeout setting, sets the Ctx with Deadline in the http.Request ...// other filters select the http.Request.Context().Done() Pay attention to the processing logic in . Although the Context of http.Request has been cancelled, the Mutex on baseTimeoutWriter needs to be obtained between entering the function. The inner-handler may have written , ready to write , but the current code flow thinks that it should be Panic quickly, and it is recovered by and sends http2.Reset to the Client. As a result, a appears on the client side.
Currently seeing it in periodic and in presubmit for
Regardless of WithCache or WithoutCache, here is not reasonable.
/priority important-soon /milestone v1.21
PS: There were some recent failures:
/remove-priority important-soon /priority critical-urgent top flake for pull-kubernetes-integration per: triage link: FYI
may be one fix, may also be necessary (thanks for opening these
I believe that can effectively repair the issue, but currently is not the key PR to fix the issue.
Change:
// Check builtin modules exist or not if len(modules) != 0 { <del> kernelVersionFile := "/proc/sys/kernel/osrelease" b, err := r.Executor.Command("cut", "-f1", "-d", " ", kernelVersionFile).CombinedOutput() if err != nil { errors = append(errors, fmt.Errorf("error getting os release kernel version: %v(%s)", err, out)) return nil, errors } kernelVersion := strings.TrimSpace(string(b)) </del> builtinModsFilePath := fmt.Sprintf("/lib/modules/%s/modules.builtin", kernelVersion) out, err := r.Executor.Command("cut", "-f1", "-d", " ", builtinModsFilePath).CombinedOutput() if err != 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!--kube-proxy cannot use ipvs mode on Linux 4.19 due to a check for the module, which was changed to (). uses to check for : It should instead accept on Linux 4.19 or above. What happened: kube-proxy fell back from ipvs mode to iptables mode. What you expected to happen: kube-proxy using ipvs. How to reproduce it (as minimally and precisely as possible): Launch a cluster on an image using Linux 4.19 or above with kube-proxy using ipvs mode (see ). Environment: Kubernetes version (use ): All Kernel (e.g. ): 4.19 <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig network
/area ipvs /assign /cc
Okay, so should check {nfconntrackipv4 | nf_conntrack} and expect load at least one module?
I think so
Please just go ahead :)
Change:
StabilityLevel: metrics.ALPHA, }, []string{"result"}) // PodScheduleSuccesses counts how many pods were scheduled. <ins> // This metric will be initialized again in Register() to assure the metric is not no-op metric. </ins> PodScheduleSuccesses = scheduleAttempts.With(metrics.Labels{"result": "scheduled"}) // PodScheduleFailures counts how many pods could not be scheduled. <ins> // This metric will be initialized again in Register() to assure the metric is not no-op metric. </ins> PodScheduleFailures = scheduleAttempts.With(metrics.Labels{"result": "unschedulable"}) // PodScheduleErrors counts how many pods could not be scheduled due to a scheduler error. <ins> // This metric will be initialized again in Register() to assure the metric is not no-op metric. </ins> PodScheduleErrors            = scheduleAttempts.With(metrics.Labels{"result": "error"}) DeprecatedSchedulingDuration = metrics.NewSummaryVec( &metrics.SummaryOpts{

Discussion:
What happened: two scheduler metrics, and , was not recorded in . scheduler has some code for this already. It seems to be a bug. What you expected to happen: and was recorded How to reproduce it (as minimally and precisely as possible): /king bug /sig scheduling
/assign
What do you expect for ? And I think pending pods are available in metrics, but not from scheduler. You can get it from pods info metrics.
actually, scheduler has some code already for recording these metrics. But I found a bug in these code. I will post my PR to fix this issue soon. // I updated the issue description for clarifying.
Change:
// Deprecated func RawMustRegister(cs ...prometheus.Collector) { defaultRegistry.RawMustRegister(cs...) <del> // sideload global prom registry as fallback for _, c := range cs { prometheus.Register(c) } </del> } // RawRegister registers a prometheus collector but uses the global registry, this

Discussion:
What happened: CI failed when deprecated metrics. Refer to The reason is that a hidden metrics won't be created thus can't be registered to prometheus's registry. I guess the other PR failed for the same reason. What you expected to happen: How to reproduce it (as minimally and precisely as possible): When starting the cluster, panic happens Anything else we need to know?: In my option, we need to remove backoff from legacyregistry. 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 /sig instrumentation
Discoveries after run go test ( by ) after removing backoff and deprecating some metrics: The kubelet's metrics are protected by the unit tests, and they work well . The only block is , that is I mean register to legacy registry and gather from Prometheus.
By backoff do you mean the fallback call to prometheus.Register in the various legacyregistry register functions?
Yes. I opened a PR and see what would happen. (I guess it should be fine now)
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/uuid" <ins> "k8s.io/apimachinery/pkg/util/wait" </ins> "k8s.io/kubernetes/test/e2e/framework" <ins> imageutils "k8s.io/kubernetes/test/utils/image" "time" </ins> "github.com/onsi/ginkgo" ) <ins> const ( podTemplateRetryPeriod  = 1 * time.Second podTemplateRetryTimeout = 1 * time.Minute ) </ins> var _ = ginkgo.Describe("[sig-node] PodTemplates", func() { f := framework.NewDefaultFramework("podtemplate") /*

Discussion:
[x] Original approval issue: [x] two weeks soak end date: 2 July 2020 This issue is created to allow edit by According to this APIsnoop query, there are still an endpoint which is untested. /wip /hold a set of 3 Pod Templates with a static label within a Namespace. that all 3 Pod Templates with the label in the Namespace are created. the set of Namespaced Pod Templates with a label via DeleteCollection. that all Pod Templates with the label have been deleted. Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 1 points This test is also created with the goal of conformance promotion.
/sig testing /sig architecture /area conformance
/area conformance
During Conformance Meeting: Is there a way to write this test so it is resource agnostic? If we are just changing the resource... can be parameterize the resource-type
/assign
GitHub didn't allow me to assign the following users: heyste. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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
GitHub didn't allow me to assign the following users: heyste. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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
/reopen Merge 17 July 2020
Reopened this issue. <detailsIn response to : /reopen Merge 17 July 2020 Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
// Complete assigns RenameContextOptions from the args. func (o *RenameContextOptions) Complete(cmd *cobra.Command, args []string, out io.Writer) error { if len(args) != 2 { <del> cmd.Help() return fmt.Errorf("Unexpected args: %v", args) </del> <ins> return helpErrorf(cmd, "Unexpected args: %v", args) </ins> } o.contextName = args[0]

Discussion:
The '-context' does not seem to add any value
add priority and team please.
Blocked on
/sig cli
Change:
} // we're not writing to this stream errorStream.Close() <ins> defer pf.streamConn.RemoveStreams(errorStream) </ins> errorChan := make(chan error) go func() {

Discussion:
The port forwarding client leaks memory when a port forwarding session is reused over time. The port forwarder client should not leak memory. forwarding a port with kubectl. and close many connections to the forwarded port. The amount of memory leaked for each connection is quite small, so many connections are needed to observe the leak. This is related to , which was reported for the kubelet and fixed in . However, the same problem happens to the client. The client needs to call on the , otherwise the streams created by will be kept in memory until the port forwarder itself is closed, even if the streams themselves closed long before. <details</details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery
/cc /triage accepted
/cc
Change:
klog.Errorf("Failed to find a shared datastore matching zone %s. err: %+v", zonesToSearch, err) return "", err } <del> // Prepare error msg to be used later, if required. err = fmt.Errorf("The specified datastore %s does not match the provided zones : %s", datastoreName, zonesToSearch) } found := false // Check if the selected datastore belongs to the list of shared datastores computed. for _, sharedDs := range sharedDsList { if datastoreInfo, found = candidateDatastores[sharedDs.Info.Url]; found { klog.V(4).Infof("Datastore validation succeeded") found = true break </del> <ins> found := false for _, sharedDs := range sharedDsList { if datastoreInfo, found = candidateDatastores[sharedDs.Info.Url]; found { klog.V(4).Infof("Datastore validation succeeded") found = true break } } if !found { err = fmt.Errorf("The specified datastore %s does not match the provided zones : %s", datastoreName, zonesToSearch) klog.Error(err) return "", err </ins> } <del> } if !found { klog.Error(err) return "", err </del> } } }

Discussion:
Currently whenever a vSphere volume is provisioned, we are looking at all nodes in the cluster and then fetching their hosts and then their datastores and then ensuring that selected datastore in present on all the nodes. This is done every time a new PVC is provisioned. It can be pretty expensive in large clusters and number of involved API calls can be big. /sig storage /area vsphere cc
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : Currently whenever a vSphere volume is provisioned, we are looking at all nodes in the cluster and then fetching their hosts and then their datastores and then ensuring that selected datastore in present on all the nodes. This is done every time a new PVC is provisioned. /area vsphere 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
/triage accepted
/assign
Change:
func (m *APIRegistrationManager) EnabledVersions() []unversioned.GroupVersion { ret := []unversioned.GroupVersion{} for _, groupMeta := range m.groupMetaMap { <del> ret = append(ret, groupMeta.GroupVersions...) </del> <ins> for _, version := range groupMeta.GroupVersions { if m.IsEnabledVersion(version) { ret = append(ret, version) } } </ins> } return ret }

Discussion:
introduced a bug where doesn't consult anymore... I think. I was trying to debug another problem and spotted this. I think only clients use this function. APIServer has an entirely different mechanism for tracking enabled/disabled things. cc
Change:
} count++ <del> if err := info.Refresh(patchedObj, true); err != nil { return err } </del> oldData, err := json.Marshal(info.Object) if err != nil { return err

Discussion:
The bug is introduced in The oldData, newData in seem always to be the same. So it always showing . After digging a bit, I found that: the place where we save the may be wrong. sometimes oldData and newData are different because of different s, even though the patch is . cc:
cc
info.Object is updated by the info.Refresh call. We should compute old data prior to refreshing the info bug was introduced in
I think the second bug is because using read from stream has less infomation than when you fetch from server, so but didn't
Change:
watchCacheSizes := make(map[schema.GroupResource]int) watchCacheSizes[schema.GroupResource{Resource: "replicationcontrollers"}] = maxInt(5*clusterSize, 100) watchCacheSizes[schema.GroupResource{Resource: "endpoints"}] = maxInt(10*clusterSize, 1000) <ins> watchCacheSizes[schema.GroupResource{Resource: "endpointslices", Group: "discovery.k8s.io"}] = maxInt(10*clusterSize, 1000) </ins> watchCacheSizes[schema.GroupResource{Resource: "nodes"}] = maxInt(5*clusterSize, 1000) watchCacheSizes[schema.GroupResource{Resource: "pods"}] = maxInt(50*clusterSize, 1000) watchCacheSizes[schema.GroupResource{Resource: "services"}] = maxInt(5*clusterSize, 1000)

Discussion:
The regression is caused by two changes: Changes in reflector () which results in issuing LIST with RV="" (meaning it will go to etcd) on WATCH restarts caused by 410 (RV too old) errors Enabling EndpointSlice API without bumping the cache size for EndpointSlices (will be fixed in ). The default cache size is 100, which is not enough for resources that can change as rapidly as EndpointSlice (to compare cache size for Endpoints, which EndpointSlices is replacing, was 10* # nodes), which results in WATCHes being terminated with 410 and then issuing heavy LISTs to restart them (see above). If you take into account that this happens on each node (kube-proxy is watching EndpointSlices) the burst in heavy LIST can effectively kill control-plane which we observe in scale tests. Below the graphs showing exactly this situation in kubemark-5K test (last two runs failed in exactly the same way): ! ! We hope that will fix the issue and make our tests passing. We're currently running the tests manually to confirm that. /sig scalability /milestone v1.17
/priority critical-urgent This is a release blocker
Change:
if nodeID != "" { return true, nil } <del> // kubelet plugin registration service not implemented is a terminal error, no need to retry if strings.Contains(getNodeInfoError.Error(), "no handler registered for plugin type") { return false, getNodeInfoError </del> <ins> if getNodeInfoError != nil { klog.Warningf("Error calling CSI NodeGetInfo(): %v", getNodeInfoError.Error()) </ins> } // Continue with exponential backoff return false, 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: Kubelet dies with a panic exception if CSI plugin returns NodeId == "" and nil error. Exception log see at the end of the message What you expected to happen: Kubelet should just raise an error to the plugin and ignore the registration. How to reproduce it (as minimally and precisely as possible): Create a CSI plugin with only Node that would implement GetNodeInfo as follows: Register it as a DaemonSet and see kublet crush Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.10-gke.17 Cloud provider or hardware configuration: GKE OS (e.g: ): Container-Optimized OS (cos) Kernel (e.g. ): - Install tools: Network plugin and version (if this is a network-related bug): Others: Related exception Related line of code: - no check whether error is not nil before calling Error() on it.
/sig storage
/sig node is this the version of the kubelet too? 14 is out of support. is the issue reproducible with a 1.15+ kubelet?
/assign
I checked the code - same defect still exists in current codebase.
thanks /priority important-soon
Wow, that was fast. Thanks!