jiebi/CodeConvo huggingface dataset:
Change:
if err := saveVolumeData(dataDir, volDataFileName, volData); err != nil { klog.Error(log("failed to save volume info data: %v", err)) <del> if err := os.RemoveAll(dataDir); err != nil { klog.Error(log("failed to remove dir after error [%s]: %v", dataDir, err)) return nil, err </del> <ins> if removeErr := os.RemoveAll(dataDir); removeErr != nil { klog.Error(log("failed to remove dir after error [%s]: %v", dataDir, removeErr)) </ins> } return nil, err }

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: Error msg override when saveVolumeData fails. What you expected to happen: return the right error. 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:
/sig storage
/assign
Change:
// ResourceEventHandlerFuncs is an adaptor to let you easily specify as many or // as few of the notification functions as you want while still implementing <del> // ResourceEventHandler. </del> <ins> // ResourceEventHandler.  This adapter does not remove the prohibition against // modifying the objects. </ins> type ResourceEventHandlerFuncs struct { AddFunc    func(obj interface{}) UpdateFunc func(oldObj, newObj interface{})

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: I discovered colleagues writing informer clients that modify objects delivered by informers. I went looking for where it says they should not do that, and I could not find it. What you expected to happen: I expected this critical restriction to be prominently documented. How to reproduce it (as minimally and precisely as possible): Try to find where it says that a client of an informer must not modify an object delivered by the informer. 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:
Documentation aside, I would suggest adding to your CI infra to make it harder for people to make this mistake.
/assign Thank you for fixing docs!
Change:
nsn  types.NamespacedName port uint16 <del> listeners   []net.Listener </del> httpServers []httpServer endpoints int // number of local endpoints for a service

Discussion:
When a LoadBalancer Service with Local ExternalTrafficPolicy was deleted normally, an error log "use of closed network connection" was always generated in kube-proxy log, which confused people that there was something wrong: Do not generate error log when it's expected. a LoadBalancer Service with Local ExternalTrafficPolicy it No response <detailsv1.26.0 </details<details</details<details</details<details</details<details</details<details</details
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 network
Change:
}) ginkgo.It("should test the lifecycle of an Endpoint", func() { <del> ns := f.Namespace.Name </del> <ins> testNamespaceName := f.Namespace.Name </ins> testEndpointName := "testservice" <del> ginkgo.By("creating an Endpoint") _, err := f.ClientSet.CoreV1().Endpoints(ns).Create(context.TODO(), &v1.Endpoints{ </del> <ins> testEndpoints := v1.Endpoints{ </ins> ObjectMeta: metav1.ObjectMeta{ <del> Name:      testEndpointName, Namespace: ns, </del> <ins> Name: testEndpointName, </ins> Labels: map[string]string{ <del> "testendpoint-static": "true", </del> <ins> "test-endpoint-static": "true", </ins> }, }, Subsets: []v1.EndpointSubset{{

Discussion:
[x] Original approval issue: [x] Two weeks soak end date: This issue is created to allow edit by /wip /hold This issue proposes the writing of a new test for the API endponts , , , with the intention of promoting it to Conformance. This issue contains a very basic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. According to this APIsnoop query, there are still some remaining Endpoints endpoints which are untested. a Service in a namespace all Endpoints in all Namespaces find the created Service(1) /update the Namespaced Endpoint for the Service(1) the Namespaced Endpoint for the Service(1) the Namespaced Endpoint for the Service(1) Namespaced Endpoint(1) via a Collection with a LabelSelector Discover useragents: If a test with these calls gets merged, Conformance coverage will go up by 4 points* /sig testing /sig architecture /area conformance
/reopen Wait for Promotion PR to Merge.
Reopened this issue. <detailsIn response to : /reopen Wait for Promotion PR to Merge. 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:
if !errors.Is(err, tc.wantErr) { t.Errorf("Got error %v, want %v", err, tc.wantErr) } <del> if diff := cmp.Diff(tc.wantStatusUpdates, statusUpdates); diff != "" { </del> <ins> if diff := cmp.Diff(tc.wantStatusUpdates, statusUpdates, cmpopts.IgnoreFields(batch.JobCondition{}, "LastProbeTime", "LastTransitionTime")); diff != "" { </ins> t.Errorf("Unexpected status updates (-want,+got):n%s", diff) } rmFinalizers := len(fakePodControl.Patches)

Discussion:
If the user update , duplicate condition: ! Only one Failed condition Create Job and wait it marked as Failed Update the Failed condition to False No response <details</details<details</details<details</details<details</details<details</details<details</details
It's not a bug. The is a list, so it can contain many conditions with different probe timestamps. Also, we should not update the fields.
But should we avoid the duplicate Type's conditionIn my opinionthis will confuse the user. According to kubelet, it will rewrite the 'Ready' condition in pod, and take is as managed only by kubelet. Should we did this for job Failed condition? Refer:
/sig apps
It is a bug. We should only have one condition for each type. /triage accepted
/assign
/assign
/assign
I have reproduced the issue locally and intend work on the fix
/priority backlog Since the user is manually modifying the status, this is not an inherent bug in the controller. Still worth avoiding duplicates.
Change:
lastMarkedDirty: time.Now(), service:         newServiceKey(*apiService.Spec.Service), }) <ins> dm.removeUnusedServices() </ins> dm.dirtyAPIServiceQueue.Add(apiService.Name) } func (dm *discoveryManager) RemoveAPIService(apiServiceName string) { if dm.setInfoForAPIService(apiServiceName, nil) != nil { // mark dirty if there was actually something deleted <ins> dm.removeUnusedServices() </ins> dm.dirtyAPIServiceQueue.Add(apiServiceName) } }

Discussion:
The in apiserver grows infinitely without ever purging serviceKeys which are not referenced by any APIServices. /sig api-machinery /cc /assign a limited size cache APIService your services Spec.Service field to a new address step 2 and watch the list grow No response_ <details26-1.27 </details<detailsN/A </details<details</details<detailsN/A </details<detailsN/A </details<detailsN/A </details
/triage accepted
/assign
what do we want to the limit the cache size by?
the cache currently doesn't purge s which are not being used by an
is this still an issue? should it be resolved before enabling by default?
Can you elaborate? I am not sure what you mean by enabling by default?
Yes That's the cache for the downloaded discovery for each apiservice. The list probably doesn't grow very large. Fix is in . Considering the pain of non-aggregated discovery on some users, and the time they have had to wait to get the feature, I'd say the trade-off is that this isn't nearly as bad.
It's also worth noting that the cache should only grow for Aggregated APIServices that themselves expose aggregated discovery endpoint. We don't store a cache entry here otherwise. The list doesn't grow unless the aggregated discovery document was successfully fetched. This is a very rare case and especially at release a minuscule number of people on the bleeding edge might run into it. And even then it is not likely to be changing the so often once it is working enough to store a cache entry.
Change:
return &cfg, nil } <del> // getClusterNodes() returns the cluster nodes of a given cluster func getClusterNodes(cli *gcli.Client, cluster string) (dynamicHostIps []string, err error) { clusterinfo, err := cli.ClusterInfo(cluster) if err != nil { glog.Errorf("glusterfs: failed to get cluster details: %v", err) return nil, fmt.Errorf("failed to get cluster details: %v", err) } // For the dynamically provisioned volume, we gather the list of node IPs // of the cluster on which provisioned volume belongs to, as there can be multiple // clusters. for _, node := range clusterinfo.Nodes { nodei, err := cli.NodeInfo(string(node)) if err != nil { glog.Errorf("glusterfs: failed to get hostip: %v", err) return nil, fmt.Errorf("failed to get hostip: %v", err) } ipaddr := dstrings.Join(nodei.NodeAddRequest.Hostnames.Storage, "") dynamicHostIps = append(dynamicHostIps, ipaddr) } glog.V(3).Infof("glusterfs: hostlist :%v", dynamicHostIps) if len(dynamicHostIps) == 0 { glog.Errorf("glusterfs: no hosts found: %v", err) return nil, fmt.Errorf("no hosts found: %v", err) } return dynamicHostIps, nil } </del>

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:
s[i], s[j] = s[j], s[i] } func (s sortedPods) Less(i, j int) bool { <del> return s[i].ID < s[j].ID </del> <ins> return s[i].ID < s[j].ID && s[i].Namespace < s[j].Namespace </ins> } func CreateValidPod(name, namespace, source string) api.BoundPod {

Discussion:
The podInfo call has no way to accept namespace, which means the apiserver can't fetch pod info. Probably need to make namespace a required path parameter.
this is probably you :)
- is this something you see when working off ??
- ok so this is pod_cache, will review
If you don't time, I can pick up this one.
I got it.
Per discussion with , will deliver a pull after is merged.
Change:
return nil case admission.Delete: <del> // get the existing pod </del> <ins> // get the existing pod from the server cache </ins> existingPod, err := c.podsGetter.Pods(a.GetNamespace()).Get(a.GetName(), v1.GetOptions{ResourceVersion: "0"}) <ins> if errors.IsNotFound(err) { // wasn't found in the server cache, do a live lookup before forbidding existingPod, err = c.podsGetter.Pods(a.GetNamespace()).Get(a.GetName(), v1.GetOptions{}) } </ins> if err != nil { return admission.NewForbidden(a, err) }

Discussion:
When a node is deleting a pod, the NodeRestriction admission plugin ensures the pod is bound to the node. It first checks the server cache for the pod. In the case where a pod was created and immediately deleted, it may not yet exist in the server cache. Before forbidding, we should do a live lookup. https://k8s- cc
Change:
"//staging/src/k8s.io/apimachinery/pkg/api/errors:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/diff:go_default_library", </ins> "//staging/src/k8s.io/apiserver/pkg/admission:go_default_library", "//staging/src/k8s.io/apiserver/pkg/admission/testing:go_default_library", "//staging/src/k8s.io/client-go/informers:go_default_library",

Discussion:
What happened: We enabled the feature gate on to start switching from non-expiring to expiring ServiceAccount tokens as . It works well. We then wanted to completely get rid of the "legacy" non-expiring ServiceAccount token Secrets. To do that we configured with (so it wouldn't auto-create the Secrets), removed the existing Secrets and removed the reference from the respective ServiceAccount to the Secret. This works as expected: No non-expiring token Secrets are generated. However, when creating a Pod we now see: This happens because the rejects the Pod because it cannot find a ServiceAccount token Secret (because it doesn't exist anymore as intended). What you expected to happen: When using the feature the legacy ServiceAccount token Secrets aren't used anymore, so a Pod should not be rejected if the Secret doesn't exist. The Pod doesn't even use the Secret at all. How to reproduce it (as minimally and precisely as possible): Enable feature gate Start with Create a new ServiceAccount Deploy a dummy app using that ServiceAccount Observe no Pod being created with Describe the corresponding ReplicaSet to see the above Error event. Anything else we need to know?: Looking at the it seems that at least one legacy Secret must exist in order for the Pod to get admitted. This is enforced even when and we're relying on projected token volumes. Following the code path when is enabled reveals that the token is never going to be used later on as there's no SecretVolume to be mounted in . In other words:  is just fine when . During the transition period it's fine to have the legacy Secrets lying around but ultimately it's desirable to get rid of them because as far as I can tell they are still happily accepted by the API server. Environment: Kubernetes version: tested on but code seems the same in and Cloud provider or hardware configuration: OS (e.g: ): Ubuntu 18.04.3 LTS Kernel (e.g. ): 4.15.0-1054-aws Install tools: /kind bug /sig auth
Fixed in
Thank you!
Change:
"encoding/json" "fmt" "io" <ins> "k8s.io/client-go/util/retry" </ins> "runtime/debug" "strconv" "strings"

Discussion:
ci-kubernetes-kind-e2e-parallel ci-kubernetes-e2enode-ubuntu2-k8sstable1-gkespec Pods should run through the lifecycle of Pods and PodStatus failed to see Pod pod-test in namespace Triage: /sig node
/assign /triage accepted
GitHub didn't allow me to assign the following users: fromanirh. 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 /triage accepted 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
/milestone v1.22
/unassign /assign
I cannot reproduce (despite trying hard!) on my PC... I wonder if that flake wasn't greatly improved by: Now it looks like it fails rarely:
/area node-e2e
/priority important-longterm
/remove-kind flake /kind failing-test Appears to only be failing on the node-kubelet-orphans job: /priority important-soon /remove-priority important-longterm Next steps: check Prow config for this job, doesn't appear to be failing on any other jobs.
Now let's wait 12h to have the next run of kubelet-orphans /reopen
Reopened this issue. <detailsIn response to : Now let's wait 12h to have the next run of kubelet-orphans /reopen 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 /unassign MemoryManager tests probably shouldn't be running on these jobs, if we adjust the job configs this should fix the failures.
I updated the orphans job config to exclude -
/milestone v1.23
update: will keep looking into it
I think we can close it now, the orphans job is looking green now.
Feel free to re-open if you will encounter issues with the reported test under a different job.
/close
Closing this issue. <detailsIn response to : /close 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:
// Watch minions. // Minions may be listed frequently, so provide a local up-to-date cache. if false { <del> // Disable this code until minions support watches. </del> <ins> // Disable this code until minions support watches. Note when this code is enabled, // we need to make sure minion ListWatcher has proper FieldSelector. </ins> cache.NewReflector(f.createMinionLW(), &api.Node{}, f.MinionLister.Store).Run() } else { cache.NewPoller(f.pollMinions, 10*time.Second, f.MinionLister.Store).Run()

Discussion:
With latest master it can happen that pods get scheduled on minions that are not up and get stuck in state. Also the command now also lists the down minions.
Master now returns all minions, with minion status set. Scheduler hasn't been updated yet. I'll put a fix for this. kubectl should return only running minions, and take a '-a' option to list all minions now. This also needs to be fixed.
, Deyuan Deng wrote:
Yeah, the main concern is that minion status is not as clear as Pod, e.g. running minion may not be eligible to schedule a pod. I'm still trying to figure out the best way to convey the message to client.
Re-open as now list all minions, including down ones. We should probabaly first filter out unhealthy ones in kubectl, before we can show any status.
What do you mean by "filter out"? We should be caching minion status in the apiserver. As proposed, we should show all minions that exist, including unresponsive ones.
I mean do not show down minions for now for consistency (users do not expect down minion to be listed). I agree with what proposed, but I'm trying to figure out how / what we convey the status message to user. NodePhase + NodeConditions are essential for k8s components, but are we going to expose all such data to user?
Why wouldn't users need to see down minions? I would think as an admin i would want to see phase + conditions
nvm My original concern was that phase and conditions are meant to be used by k8s, so we may need some translation to make it easier to understand for admin. Also, they are not fully populated, so I thought we may delay showing status for now. I certainly have no problem showing down minions and adding status. I've created a PR
Change:
} return dynamicClient, nil } <ins> func DeleteCustomResourceDefinition(customResource *apiextensionsv1alpha1.CustomResourceDefinition, apiExtensionsClient clientset.Interface) error { if err := apiExtensionsClient.Apiextensions().CustomResourceDefinitions().Delete(customResource.Name, nil); err != nil { return err } err := wait.PollImmediate(30*time.Millisecond, 30*time.Second, func() (bool, error) { if _, err := apiExtensionsClient.Discovery().ServerResourcesForGroupVersion(customResource.Spec.Group + "/" + customResource.Spec.Version); err != nil { if errors.IsNotFound(err) { return true, nil } return false, err } return false, nil }) return err } func GetCustomResourceDefinition(customResource *apiextensionsv1alpha1.CustomResourceDefinition, apiExtensionsClient clientset.Interface) (*apiextensionsv1alpha1.CustomResourceDefinition, error) { return apiExtensionsClient.Apiextensions().CustomResourceDefinitions().Get(customResource.Name, metav1.GetOptions{}) } </ins>

Discussion:
Kubernetes version (use ): Kubernetes HEAD Environment: Cloud provider or hardware configuration: linux OS (e.g. from /etc/os-release): Kernel (e.g. ):NAME=Fedora25 What happened: apiserver panic What you expected to happen: No panic How to reproduce it (as minimally and precisely as possible): Testcase is going to be sent as a PR
Fixed by
Change:
--format "value(zone)" | wc -l) # In the replicated scenario, if there's only a single master left, we should also delete load balancer in front of it. <del> if [[ "${REMAINING_MASTER_COUNT}" == "1" ]]; then </del> <ins> if [[ "${REMAINING_MASTER_COUNT}" -eq 1 ]]; then </ins> if gcloud compute forwarding-rules describe "${MASTER_NAME}" --region "${REGION}" --project "${PROJECT}" &>/dev/null; then detect-master local REMAINING_REPLICA_NAME="$(get-all-replica-names)"

Discussion:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): upgrade test leak Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): 1.5 beta Environment: Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: kube- What happened: While doing manual upgrade testing, found that I couldn't start a new cluster as the existing firewall rules and external master ip address reservation where preventing kube-up from succeeding after running kube-down What you expected to happen: kube-down to clean up all cluster related resources How to reproduce it (as minimally and precisely as possible):
I tried this on a different GCP project and it didn't reproduce. I'm going to see if there's anything strange about my project.
Ack marking this as non-release-blocker
I think I found the problem. (from ) evaluates to false in bash on my mac. Changing it to fixes my issue. I'll send out a PR.