jiebi/CodeConvo huggingface dataset:
Change:
}) }) <del> It("should have an terminated reason [NodeConformance]", func() { </del> <ins> /* Release : v1.13 Testname: Kubelet, failed pod, terminated reason Description: Create a Pod with terminated state. Pod MUST have only one container. Container MUST be in terminated state and MUST have an terminated reason. */ framework.ConformanceIt("should have an terminated reason [NodeConformance]", func() { </ins> Eventually(func() error { podData, err := podClient.Get(podName, metav1.GetOptions{}) if err != nil {

Discussion:
What happened: These tests are errantly listed as (ref: ) but aren't actually run as part of Conformance. They need to be moved to test/e2e/common to be included. To my eyes they may meet the criteria for conformance. There's definitely nothing about them that is node specific. They should be running as part of our regular CI, and they should probably be running as presubmits. Porting them to test/e2e/common would cause this to happen. /kind cleanup /sig node /area test /assign
GitHub didn't allow me to assign the following users: mkurylec. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : What happened: These tests are errantly listed as (ref: ) but aren't actually run as part of Conformance. They need to be moved to test/e2e/common to be included. /sig node /area test /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:
ErrCodeResourceVersionConflicts ErrCodeInvalidObj ErrCodeUnreachable <ins> ErrCodeTimeout </ins> ) var errCodeToMessage = map[int]string{

Discussion:
It is possible to issue a list request which exceeds the duration set by the request-timeout apiserver flag. The request-timeout flag does not appear to be enforced when the apiserver is decoding the response from etcd. Specifically, listing a large number of CRDs from etcd can result in high request latency from using json encoding compared to protobuf encoding. While overall etcd latency is low, the overall listing from storage latency may be over the 1 minute timeout, particularly if the apiserver needs to fetch multiple pages from etcd. We expected the list requests to be subject to the duration specified by the request-timeout flag when this latency is coming from the listing from storage phase of the request. Create 4000 CRs and list all the objects from etcd in 2 pages of 2000 objects. If the time to list 1 page + decode takes around 50s, listing 2 pages will result in the listing from storage phase of the request taking around 1 minute and 40s before the request fails and the client is returned a 500 response code. Logs for apiserver Trace message: Audit log entry: Related issue for supporting protobuf for CRDs: <details</details<detailsAWS </details<details</details<details</details<details</details<details</details
/sig api-machinery CC:
Interesting.. - do you know where exactly we stuck? In the call to storage: we pass the context that has timeout set, so that shouldn't hang. OTOH, for the processing part: (a) I don't know if transformer honors the context - it probably depends on the implementation (b) but the decoding (appendListitem) certainly isn't honoring the context So (b) might definitely be a problem, even independently from from the transformer So I guess what I'm saying is that if listing from etcd finishes fast but the decoding is what takes most of time, then what you described can certainly be a problem. But is that the thing you're observing?
Yes, that is our understanding. Specifically, that the decoding which occurs in appendListItem doesn't respect the context: As a separate follow-up, it would be useful to include decoding time, or at least the overall listing from storage time, as a separate latency annotation, given the audit log entry is only capturing this latency as part of
+1.

We need more granular latency tracker especially on the latency spent on decoding. Right now, it only captures etcd round trip and transformer latency.
I would be supportive for both and would be happy to review it if someone opens up a PR for it.
/triage accepted
/assign
/reopen I think we need to reopen it to document how we resolved the unit test failures brought on by adding it
Reopened this issue. <detailsIn response to : /reopen I think we need to reopen it to document how we resolved the unit test failures brought on by adding it 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:
// in case of latency in our caches, make a call direct to storage to verify that it truly exists or not _, err = e.client.Namespaces().Get(a.GetNamespace()) if err != nil { <del> return admission.NewForbidden(a, fmt.Errorf("Namespace %s does not exist", a.GetNamespace())) </del> <ins> if errors.IsNotFound(err) { return err } return errors.NewInternalError(err) </ins> } return nil

Discussion:
Currently the admission controller returns a forbidden (403) error if the namespace doesn't exist. We should return a 404 error instead.
Change:
if pod.Status.Phase != v1.PodRunning || !podutil.IsPodReady(&pod) { // save this pod name for later, but pretend it doesn't exist for now <del> unreadyPods.Insert(pod.Name) </del> <ins> if pod.Status.Phase != v1.PodFailed { // Failed pods should not be counted as unready pods as they will // not become running anymore. unreadyPods.Insert(pod.Name) } </ins> delete(metrics, pod.Name) continue }

Discussion:
/kind bug What happened: HPA fails to launch additional pods due to pods in evicted state, even with utilization significantly over target. What you expected to happen: When HPA pods reach the target utilization, new pods should be allocated and provisioned. How to reproduce it (as minimally and precisely as possible): Launch a HPA, let the pods fill the disk on the host which will trigger evictions due to "Pod The node was low on resource: [DiskPressure]", HPA will exceed target and not allocate additional pods. Anything else we need to know?: Seems related to and though those are not specific to HPA. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): cos-stable-57-9202-64-0 kernel commit id Kernel (e.g. ):Linux gke-prod1-use1b-v2--35s4 4.4.70+ SMP Mon Sep 18 12:43:08 PDT 2017 x86_64 Intel(R) Xeon(R) CPU @ 2.30GHz GenuineIntel GNU/Linux
/sig scheduling
Are there any workarounds while we wait for a fix? We have ran into this on a 1.8.4 GKE cluster.
/sig autoscaling /remove-sig scheduling
I am thinking of fixing this by excluding pods with Phase=Failed from the unreadyPods that are taken into account. It seems the right thing to do as they will not become running again. Do you see any issues?
that seems decent -- anything that will never be running again should not be factored into our calculations.
/status approved-for-milestone Adding to milestone -- if the HPA isn't functioning in the case of evictions, that seems like a decently severe HPA bug.
oops, missing priority was my fault, moving back into milestone: /priority critical-urgent /remove-priority important-soon
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues.

Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
// find out what content is supported on the server resources, err := c.Discovery().ServerPreferredNamespacedResources() <del> if err != nil { </del> <ins> if err != nil && !isDynamicDiscoveryError(err) { </ins> return false, err } groupVersionResources, err := discovery.GroupVersionResources(resources) <del> if err != nil { </del> <ins> if err != nil && !isDynamicDiscoveryError(err) { </ins> return false, err }

Discussion:
Seen in https://k8s- Aug 26 09:35:45.074: Couldn't delete ns: "e2e-tests-containers-9cscj": an error on the server ("missing route (service "sample-api" not found)") has prevented the request from succeeding (get ) (&errors.StatusError{ErrStatus:v1.Status{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ListMeta:v1.ListMeta{SelfLink:"", ResourceVersion:""}, Status:"Failure", Message:"an error on the server ("missing route (service "sample-api" not found)") has prevented the request from succeeding (get )", Reason:"InternalError", Details:(*v1.StatusDetails)(0xc4217a4900), Code:500}})
https://k8s-
Change:
Latest(). Flatten(). TransformRequests(func(req *rest.Request) { <ins> // We need full objects if printing with openapi columns if o.PrintWithOpenAPICols { return } </ins> if o.ServerPrint && o.IsHumanReadablePrinter && !o.Sort { group := metav1beta1.GroupName version := metav1beta1.SchemeGroupVersion.Version

Discussion:
/kind bug /sig cli What happened: kubectl 1.11.0 defaults to (see ), hence, you need to explicitly specify it for each and every single request for a resource managed by an aggregated API server. However, it is even not able to print those resources properly (which was possible before with versions <= 1.10.5): and What you expected to happen: Properly printed and well-formatted output of . (Actually, I do not want to specify but this is what is for). Environment: Kubernetes version (use ):Kernel (e.g. ): MacOS Install tools: Brew
/cc
fixed in
/assign
Change:
// TODO check dns record in global dns server }) <del> It("should be able to connect to a federated ingress via its load balancer", func() { </del> <ins> PIt("should be able to connect to a federated ingress via its load balancer", func() { </ins> By(fmt.Sprintf("Waiting for Federated Ingress on %v", jig.ing.Name)) // check the traffic on federation ingress jig.waitForFederatedIngress()

Discussion:
This has surfaced in Ingress and Service e2e tests that manipulate DNS entries. The service controller queries the managed dns entry, thinks that the CNAME doesn't exist and adds a new one. However, clouddns says (through a 409) that the entry already exists. Error message aside, the control flow within the service controller's endpoint_helper prevents a service from being deleted. It's unclear at this point whether there's a race condition. I doubt it given the amount of logging that happens showing that there is no concurrent CNAME entry being created. cc Have you seen this in your refactoring?
Hi I used CoreDNS for most of my testing for service controller refactoring and i did not notice these errors. my local test environment is slightly different than the CI environment. i would do more tests on this issue using CoreDNS and would confirm, if it is an issue also in coredns or just google-clouddns.
If you're not still working on this, please unassign yourself and we'll try to find someone else. Thanks.
This issue was labelled only for sig/multicluster and is thus moved over to kubernetes/federation. If this does not seem to be right, please reopen this and notify us /close
Change:
svc *api.Service }{ { <del> name: "spec:v4 ip:v4 dualstack:off", </del> <ins> name: "spec:v4 ip:v4 dualstack:off isIPv6Primary:false", isIPv6Primary:          false, </ins> specExpctPrimary:       true, clusterIPExpectPrimary: true, enableDualStack:        false,

Discussion:
What happened: When K8s is started in dual-stack mode with IPv6 as the "main" (or base) family services specified with ipFamily:IPv4 still get a ipv6 ; The is expicitly set to "10.0.0.0" using . What you expected to happen: Services with ipFamily:IPv4 shall get ipv4 ClusterIP addresses. How to reproduce it (as minimally and precisely as possible): Setup a K8s cluster in dual-stack mode with family IPv6 as base Define a service with ipFamily: IPv4 To make K8s think IPv6 is the main family the cue is to define ipv6 addresses to K8s binaries. Below are my settings as an example. I do not use but install "from scratch"; Master processes; is accessed with ipv4 which does not affect the K8s family. Worker processes; Anything else we need to know?: There are other problems with dual-stack/ipv6-base but may be caused by this one. For example does not work and some processes does not become "ready". Ipv6 traffic to ipv6 services and DNS works; Environment: Kubernetes version (use ):Cloud provider or hardware configuration: - OS (e.g: ): BusyBox based own setup. Kernel (e.g. ):Install tools: "from scratch" Network plugin and version (if this is a network-related bug): Others:
/sig network /cc
The problem seem to be; The problem occurs when an ipv6 range is specified first, even in an ipv4-based dual-stack cluster. But the ipv6 range must be specified first otherwise the "kubernetes" service gets an ipv4 address but an ipv6 backend; ~Perhaps the way to fix this problem is to make sure the service address is from the right family and require that the order to is "ipv4,ipv6".~ Bad idea!
There seem to be a option; But I can't see it in the help printout. I will try to use it...
:disappointed:
Here it where the kubernetes service address is set;
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Change:
klog.V(2).Infof("azureDisk - update(%s): vm(%s) - detach disk(%s, %s)", nodeResourceGroup, nodeName, diskName, diskURI) rerr := ss.VirtualMachineScaleSetVMsClient.Update(ctx, nodeResourceGroup, ssName, instanceID, newVM, "detach_disk") if rerr != nil { <del> return rerr.Error() </del> <ins> klog.Errorf("azureDisk - detach disk(%s, %s) on rg(%s) vm(%s) failed, err: %v", diskName, diskURI, nodeResourceGroup, nodeName, rerr) if rerr.HTTPStatusCode == http.StatusNotFound { klog.Errorf("azureDisk - begin to filterNonExistingDisks(%s, %s) on rg(%s) vm(%s)", diskName, diskURI, nodeResourceGroup, nodeName) disks := ss.filterNonExistingDisks(ctx, *newVM.VirtualMachineScaleSetVMProperties.StorageProfile.DataDisks) newVM.VirtualMachineScaleSetVMProperties.StorageProfile.DataDisks = &disks if rerr = ss.VirtualMachineScaleSetVMsClient.Update(ctx, nodeResourceGroup, ssName, instanceID, newVM, "detach_disk"); rerr != nil { return rerr.Error() } } </ins> } <ins> klog.V(2).Infof("azureDisk - update(%s): vm(%s) - detach disk(%s, %s) succeeded", nodeResourceGroup, nodeName, diskName, diskURI) </ins> 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: check disk status before disk azure disk There is little possibility that attach disk would cost 10min, and disk could be attached, deleted in same time, that would cause race condition. 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure
Change:
# verify master has all required daemons echo "Validating master" local machine="master" <del> local -a required_daemon=("salt-master" "salt-minion" "kube-apiserver" "nginx" "kube-controller-manager" "kube-scheduler") </del> <ins> local -a required_daemon=("salt-master" "salt-minion" "kube-apiserver" "nginx" "kube-controller-manager" "kube-scheduler" "kubelet") </ins> local validated="1" until [[ "$validated" == "0" ]]; do validated="0"

Discussion:
Self-assigning as I work out a reliable fix.
cc
Running into a few issues. On GCE, did you guys block somewhere to wait for etcd to be running before reporting success on kube-up?
No, except there is a race between addson services, dns and etcd container. We introduced a retry logic on those services.
I assume pulling the image is just so fast that you don't run into e2e errors, it looks like you guys block on wait-for-minions that uses glcloud, so I guess when minions are reported in etcd, then you know you are good...
Change:
type ResourceQuotaScope string const ( <del> // Match all pod objects where spec.activeDeadlineSeconds </del> <ins> // Match all pod objects where spec.activeDeadlineSeconds >=0 </ins> ResourceQuotaScopeTerminating ResourceQuotaScope = "Terminating" <del> // Match all pod objects where !spec.activeDeadlineSeconds </del> <ins> // Match all pod objects where spec.activeDeadlineSeconds is nil </ins> ResourceQuotaScopeNotTerminating ResourceQuotaScope = "NotTerminating" // Match all pod objects that have best effort quality of service ResourceQuotaScopeBestEffort ResourceQuotaScope = "BestEffort"

Discussion:
The following comments are incomplete. For example, comments for "ResourceQuotaScopeTerminating" should be: Ref: /good-first-issue
/sig scheduling
/assign
Per ResourceQuota is within scope of api-machinery. /sig api-machinery /remove-sig scheduling
/assign
/unassign rakeshreddybandi
/remove-good-first-issue
Hi!! I'd like to help #investigate this problem I'm a beginner, so I'll make my best. Can you please help me point me in the right direction? What's the output today vs. how does the output should look like?
Oh I get it, the comments on top of the lines are not completely accurate on what the message displays, right? I think I got it
Yeah - But I've already opened a PR for this! - See the linked PR So this is already done, just waiting on final merge.
Great Dean, thanks for that!
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
/remove-lifecycle rotten
Change:
nodeStorageClient.Nodes(), podRegistry, ) <del> go util.Forever(func() { podCache.UpdateAllContainers() }, m.cacheTimeout) </del> <ins> if c.SyncPodStatus { go util.Forever(func() { podCache.UpdateAllContainers() }, m.cacheTimeout) } </ins> go util.Forever(func() { podCache.GarbageCollectPodStatus() }, time.Minute*30) // TODO: refactor podCache to sit on top of podStorage via status calls

Discussion:
Split off as a smaller more specific work item. Apiserver should have a flag that makes it not attempt to GET from kubelets. This would be used in conjunction with . After we have converted the top N Getting-started-guides to the new style, we can rip out the kubelet client from the apiserver altogether.
This is tightly related to so I'll take it.
Change:
dynamicEndpoint = pvSpec.Glusterfs.EndpointsName } glog.V(3).Infof("glusterfs: dynamic namespace and endpoint : [%v/%v]", dynamicNamespace, dynamicEndpoint) <del> err = d.plugin.deleteEndpointService(dynamicNamespace, dynamicEndpoint) </del> <ins> err = d.deleteEndpointService(dynamicNamespace, dynamicEndpoint) </ins> if err != nil { glog.Errorf("glusterfs: error when deleting endpoint/service :%v", err) } else {

Discussion:
several operations to the glusterfs mount operation that nodes are not permitted to perform: looks up arbitrary secrets based on storage class parameters. this will not succeed, as the node authorizer will only allow nodes access to secrets referenced by pods or persistent volumes used by the node attempts to create a service and endpoint using the node's API client. nodes do not have permission to create arbitrary endpoints and services. For both of those reasons, that recreate operation will fail when attempted from the node. The recreate operation should probably move to one of the storage-related controllers (provisioner or attach/detach) cc
Marking this with 1.7 milestone until we have a better idea of whether this is blocking or not for the 1.7 release.
CC Is the endpoint originally created by the user or by the volume plugin creating/deleting Endpoint objects? In addition to the concerns raised, having a volume create new API objects seems like a bad idea (abstraction layer violation?).
From on Slack: Unless there is justification otherwise, I will roll back the PR on Monday.
cc/
revert button doesn't work, have to do it manually
Revert PR is approved and awaiting merge (). Once that merges this issue can be closed.
Opened an E2E pr to catch this kind of behavior in the future. WIP, still exploring a method to reproduce and catch the behavior.
Change:
"disruptive.go", "driveroperations.go", "ephemeral.go", <ins> "fsgroupchangepolicy.go", </ins> "multivolume.go", "provisioning.go", "snapshottable.go",

Discussion:
We need to add e2e that verifies volume permissions in pod with different values of fsGroupChangePolicy. /sig storage
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
Change:
"os" "regexp" <del> "k8s.io/mount-utils" </del> <ins> "github.com/opencontainers/selinux/go-selinux" </ins> v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/uuid" <ins> "k8s.io/kubernetes/pkg/kubelet/config" </ins> "k8s.io/kubernetes/pkg/volume" "k8s.io/kubernetes/pkg/volume/util" "k8s.io/kubernetes/pkg/volume/util/hostutil" "k8s.io/kubernetes/pkg/volume/util/recyclerclient" "k8s.io/kubernetes/pkg/volume/validation" <ins> "k8s.io/mount-utils" </ins> ) // ProbeVolumePlugins is the primary entrypoint for volume plugins.

Discussion:
crio-e2e tests The following tests fail when run on a node with SELinux enabled: Probably since these tests were . No response The host path volumes created under /tmp/hostpathpv don't have the right SELinux label set for access by containers started during the test. No response_ /sig node
/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]:
/remove-lifecycle stale