jiebi/CodeConvo huggingface dataset:
Change:
var _ = SIGDescribe("Events", func() { f := framework.NewDefaultFramework("events") <del> /* Release: v1.9 Testname: Pod events, verify event from Scheduler and Kubelet Description: Create a Pod, make sure that the Pod can be queried. Create a event selector for the kind=Pod and the source is the Scheduler. List of the events MUST be at least one. Create a event selector for kind=Pod and the source is the Kubelet. List of the events MUST be at least one. Both Scheduler and Kubelet MUST send events when scheduling and running a Pod. */ framework.ConformanceIt("should be sent by kubelets and the scheduler about pods scheduling and running ", func() { </del> <ins> ginkgo.It("should be sent by kubelets and the scheduler about pods scheduling and running ", func() { </ins> podClient := f.ClientSet.CoreV1().Pods(f.Namespace.Name)

Discussion:
Related: Noticed this as part of Opened in response to: According to our , the e2e test is ineligible for Conformance. Specifically, the test in question is looking for guaranteed delivery of Events from specific sources (kubelet and default scheduler). This cannot be reasonably expected of all Kubernetes clusters, and thus the test should be demoted from Conformance. For historical context: It looks like this has been part of Conformance sometime since sometime prior to 2015-10-17 (we introduced the [Conformance] tag in 1.2, ref: We overhauled Conformance testing policy (including exclusion of Events) on 2018-10-08 (ref: ) If I wanted to be a language lawyer about this, I could say the policy covers ineligibility for promotion but said nothing about the existing corpus of tests. But I think this was just an honest oversight when we reviewed the existing Conformance tests. Due to the very nature of what this test is verifying, I don't think it's possible to rewrite to avoid Events. Thus, I think it should be demoted from Conformance. SIG Node is free to continue to treat this as release-blocking, but it's not something we can reasonably expect of any Kubernetes cluster /kind cleanup /priority important-soon /milestone v1.23 /sig architecture /area conformance because conformance /sig node because it's a sig-node test
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 Opened to address FYI Since y'all were commenting on
+1
Change:
awaiting <-chan interface{} finished *time.Time lock     sync.Mutex <del> notify   chan struct{} </del> <ins> notify   chan bool </ins> } // Operations tracks all the ongoing operations.

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: When trying to mount an Azure File mount it fails, it looks as though its putting a new line between the name of the Azure Storage Account and the Azure storage domain. There are no new line characters in the secret that holds the account name. The following is the secret: The following is the declaration within the section of the Kubernetes yaml: The following is the error that's shown in `kubectl describe po/pod_name: 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: azure OS (e.g. from /etc/os-release): Ubuntu 16.04.3 LTS Kernel (e.g. ): 4.13.0-1011-azure Install tools: Others:
/sig storage
/sig azure
It seems to me that does decode to , so it seems to be behaving correctly. Maybe it's a good idea to trim the return char for and fields after ?
is specified by user, so trim the is not a good idea in the code. Another simple way is to use kubectl create secret to create azure-secret, the accountname and key won't require base64 encoded, so you won't mess up with let me know if you have any question, thanks.
Thanks !
Bumped into this issue today too on our cluster. Can confirm command worked. Is there an easy way to time the /n off the end of the echo for before using base64? Thanks.
yes it's
Of course it is! Doh!
i think would've made better sense to trim the azurestorageaccountname value when receiving it... anyways the storage account name wont have n in them right? I think that just made better developer experience...
is not allowed in azure storage account name
so if azure storage account name does not allow in the name.. then why not just trim the name instead of error... Because devs would just and that would already have the n in the resulting base64-encoded string... right?
sounds reasonable /reopen
Reopened this issue.

<detailsIn response to : sounds reasonable /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
awesome. Thanks
so then this goes in to kube version 1.14.6 in AKS ? or how does this work?
It would only go into k8s v1.16.0 since it's not a critical bug, we don't want to do hot fix to the old release.
got it. thanks Andy.
Change:
visibility = ["//visibility:public"], deps = [ "//pkg/api/v1/pod:go_default_library", <del> "//pkg/apis/apps:go_default_library", </del> "//pkg/apis/core:go_default_library", <ins> "//pkg/apis/extensions:go_default_library", </ins> "//pkg/apis/scheduling:go_default_library", "//pkg/kubelet/apis:go_default_library", "//pkg/quota/evaluator/core:go_default_library",

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug We can see all related with test failed. and so on. I think it maybe relate with PR and . What happened: Always fails. What you expected to happen: Pass all.
/cc PTAL. Thanks.
Why did the not pass the test but was still merged?
/priority important-soon /kind e2e-test-failure
/area platform/gce
Looks like the fix is in
is not a blocking / required test (for merge) currently IIRC, kubernetes/kubernetes uses the "submit-queue" which will only pay attention to some tests.
i think this is true, as confirmed by the current state of this PR: it fails the test, but the CI says instead of is there are way to see which tests would cause a ?
off the top of my head the definitive way is this list: but note that is working on moving us to in the nearish future, and every other kubernetes repo besides this one is either not using merge automation or is using , which behaves differently and has seperate config integrated with the rest of test-infra.
thanks for the details! :+1:
Change:
go func() { err, _ := <-errOnce.Err() if err != nil { <del> t.Fatalf("delegate %d: unexpected error: %v", i, err) </del> <ins> t.Errorf("delegate %d: unexpected error: %v", i, err) </ins> } }() }

Discussion:
Can we get this fixed ASAP? Thanks!
yep, thanks for reporting , Brendan Burns wrote:
how reproduceable is this? I have some changes that I think will resolve it but I couldn't reproduce locally even when all my cpu's were pretty tied up and using a high GOMAXPROCS.
flakey label process?
the labelling is due to me failing @ github's label interface. Bulk editing labels removes them if any of the selected things have the label sigh Thanks for the quick fix.
Change:
defaultBinderPlugin framework.BindPlugin } <del> func newFirstFailBindPlugin(_ runtime.Object, handle framework.Handle) (framework.Plugin, error) { binder, err := defaultbinder.New(nil, handle) if err != nil { return nil, err } return &firstFailBindPlugin{ defaultBinderPlugin: binder.(framework.BindPlugin), }, nil } </del> func (*firstFailBindPlugin) Name() string { return "firstFailBindPlugin" }

Discussion:
pull-kubernetes-integration: scheduler TestRequeueByBindFailure Running with stress reproduces the flake Not sure, seeing a lot of retests on pull-kubernetes-integration Bind logic in scheduler integration tests just changed 3 days ago in , not sure if that's related No response No response /sig scheduling /priority important-soon cc
I doesn't look related to the latest change you were also looking at Bind. Any ideas?
It's a little strange because the error reports but since the bind-plugin will fail for the first calling time and there's no kubelet, that means the pod status will be kept since. I created another PR to help output the error message, which maybe helpful for analysis.
This test is very straightforward: the first try to bind "pod-1", the Pod is rejected by the binding plugin. () scheduling queue puts back this "pod-1" to activeQ/backoffQ directly, and "pod-1" will soon come back to the scheduling cycle. the second try to bind "pod-1", it's successful. And, means that (1) doesn't reject "pod-1" correctly. And I don't have any idea why it can happen. The only scenario I can think of is that there is somehow another Pod created before pod-1. When is executed , is it possible that any other Pods (like system ones) are created automatically?
/triage accepted current top flake of integration
/assign I've got one possible scenario, will have a quick fix.
Change:
if secureLocation != "" { secureServer := &http.Server{ Addr:           secureLocation, <del> Handler:        apiserver.RecoverPanics(m.Handler), </del> <ins> Handler:        apiserver.MaxInFlightLimit(sem, longRunningRE, apiserver.RecoverPanics(m.Handler)), </ins> ReadTimeout:    5 * time.Minute, WriteTimeout:   5 * time.Minute, MaxHeaderBytes: 1 << 20,

Discussion:
Related with issue , the API server should have a cap on the number of outstanding operations/requests it's handling, and return an error otherwise. A simple semaphore is an idea for this.
+1 !
The good news/bad news on this is that there is a rate limiter in the API server (), but the defaults for it seem too high: 10 qps average, 200 burst (). We could start by lowering the burst level to something smaller, like 30. It may be interesting to also differentiate between GET and PUT/POST requests.
I think that we need limits on the number of outstanding requests, not the number of QPS.
-An max outstanding would be useful. But it may force us to have separate buckets for different types of requests, i.e. a small number of long running requests causing API server to reject short requests. -Heard that you might be looking into adding support for flow control (or something like it?). We may need it soon to help avoid bugs like runaway node status updates (see issue ).
I had not - the things we were looking at were the bastion changes to apiserver which will break logs and proxying into their own rest resources so they can be granularly controlled. Being able to timebox and classify requests differently would be good. ----- Original Message -----
- Ah, np, I probably misheard.
What are our plans for handling this client side? Do we want clients to handle "you're being throttled" error themselves, or do we plan to handle it in the library? I'm asking because currently kubelet does not have a 'short' retry loop, hence it tries to report NodeStatus every X (2) seconds, whether it succeed or not. Neither we have a sidechannel for heartbeat messages. This would mean, that if API server will be under heavy load, and with not-negligible probability NodeStatus reporting will be throttled, we may incorrectly mark a Node as unreachable. Currently it's not a huge problem, because X << Y, where Y is the time we wait before we decide a Node is unreachable. But because of the effort somewhere close to it'll probably get worse.
The client library should have options for retry on client.Config which include the ability to disable the behavior. Automatic retry is probably an "opt-out" behavior.

----- Original Message -----
says there are people working on rate limiting client connections to API server.
I have in the past adjusted the rate limiter to support the creation of large clusters. I also the logic. If you adjust the rate limiter settings, please make sure it is still possible to create large clusters.
I'm closing this as fixed, given the original subject. If we want to expand client-side support for retry, please open a dedicated issue. (Also note that QPS based throttling was to the client recently too)
Change:
// Unmount removes the mount reference from the volume allowing it to be // re-mounted elsewhere. func (u *storageosUtil) UnmountVolume(b *storageosUnmounter) error { <ins> klog.V(4).Infof("clearing StorageOS mount reference for volume %q with namespace %q", b.volName, b.volNamespace) </ins> if err := u.NewAPI(b.apiCfg); err != nil { // We can't always get the config we need, so allow the unmount to // succeed even if we can't remove the mount reference from the API. <del> klog.V(4).Infof("Could not remove mount reference in the StorageOS API as no credentials available to the unmount operation") </del> <ins> klog.Warningf("could not remove mount reference in the StorageOS API as no credentials available to the unmount operation") </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: When a PVC is created and the PV mounted into a Pod using the StorageOS in-tree volume driver, the StorageOS CLI & UI do not report that the volume is mounted. The PV is created and mounted into the Pod successfully, and all k8s functionality works as expected. However, since the correct mount status is not visible to administrators using the StorageOS UI or CLI, they may make changes to or delete a mounted volume without realising, and the safeguards (must use to delete a mounted volume) do not trigger. This is a regression caused by , released in 1.14.0. What you expected to happen: The StorageOS CLI should report volume mount information (node name, mount timestamp). How to reproduce it (as minimally and precisely as possible): StorageOS node containers with CSI disabled: application Pod with a PVC using the StorageOS StorageClass: StorageOS to list volumes: Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.0 and later Cloud provider or hardware configuration: any OS (e.g: ): any linux (incl. Ubuntu 18.04) Kernel (e.g. ): any linux (incl. 4.15.0-33-generic) Install tools: any (incl. minikube) Network plugin and version (if this is a network-related bug): N/A Others: Requires StorageOS deployment /sig storage /assign
Change:
// that do not specify any priority class and there is no priority class // marked as default. DefaultPriorityWhenNoDefaultClassExists = 0 <ins> // SystemPriorityClassPrefix is the prefix reserved for system priority class names. Other priority // classes are not allowed to start with this prefix. SystemPriorityClassPrefix = "system-" </ins> ) // +genclient

Discussion:
In a recent discussion on , suggested to keep priority class names that start with "system-" for system use only and not allow user defined priority classes to start with this prefix. Given that we have reserved priority values 1 Billion for system use only, it makes sense to reserve a prefix as well to ensure that predefined priority classes won't conflict with user defined ones in the future. Is this a BUG REPORT or FEATURE REQUEST?: /kind feature /sig scheduling /assign ref
Change:
kubeclientset "k8s.io/kubernetes/pkg/client/clientset_generated/release_1_5" "k8s.io/kubernetes/pkg/client/record" "k8s.io/kubernetes/pkg/controller" <ins> "k8s.io/kubernetes/pkg/conversion" </ins> "k8s.io/kubernetes/pkg/runtime" "k8s.io/kubernetes/pkg/util/flowcontrol" "k8s.io/kubernetes/pkg/watch"

Discussion:
Unit tests on PR are failing due to data race in federation-controller/namespace unittest. More logs: https://k8s-
CC
Sent to fix this
Change:
"audit.go", "certificates.go", "framework.go", <ins> "node_authz.go", </ins> "service_accounts.go", ], tags = ["automanaged"],

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): TESTING REQUEST Spawned from: It would be nice with some e2e tests for the Node Authorizer so consumers of it (kubeadm, GCE, GKE, etc.) could easily make sure it's enabled and working, just by editing when running e2e's. I wrote a quick bash script of what it could do: The bash script above is in no way comprehensive enough, but on the other hand it took ~5mins to write :) For now (1.7), we might use something like this bash script in our kubeadm e2e CI job to make sure the Node Authorizer/Admission plugin is enabled correctly. cc
was assigned for triaging this... Does such an e2e test already exist somewhere? said that he could take this on if not...
no negative e2e test exists (make sure things the Node authorizer disallows fail) negative integration tests exist at negative e2e tests for this will be tricky, since you'll need node credentials and a specific authz and admission config.
See the above bash script, I was able to do it purely from kubectl by impersonating the group and node user... If we feature-gate this e2e test, we can run it for the deployments that actually have unique node credentials
cc this maybe could be a good task for you... :)
Cool, thanks for point me this.
You basically only have to implement these commands as an e2e test initially (by impersonating a node in the cluster). Then when that's done, we can check if there are more than these four cases that needs to be verified. This should go under a separate and be enabled in deployments (like kubeadm) where nodes have unique credentials.
I didn't find a way to simulate a node credential, do you have any good idea ? after reading the integration testing code, I fell it's enough the guarantee the quality, WDYT?
Change:
// DefaultEvictionHard includes default options for hard eviction. var DefaultEvictionHard = map[string]string{ <del> "memory.available":  "100Mi", "nodefs.available":  "10%", "nodefs.inodesFree": "5%", "imagefs.available": "15%", </del> <ins> "memory.available":   "100Mi", "nodefs.available":   "10%", "nodefs.inodesFree":  "5%", "imagefs.available":  "15%", "imagefs.inodesFree": "5%", </ins> }

Discussion:
It is possible to deploy Kubernetes with a separate filesystem. We default the settings for EvictionHard . A concern is that if users are using the default settings and separate filesystem for images, we are effectively turning off monitoring for INodes on the imagefs. This means that we won't have disk pressure if inodes run out on the ImageFs. The fix can be to add To default settings. This doesn't seem to be a regression as these defaults were 5 years ago (k8s 1.12) but this could be a potential bug if either users mount a separate filesystem to their container runtime storage or they configure their runtime to store their images on a separate filesystem.
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 node
/assign
/kind feature
Change:
translateTimestamp(e.FirstTimestamp), translateTimestamp(e.LastTimestamp), e.Count, <del> e.Source, </del> <ins> formatEventSource(e.Source), </ins> e.InvolvedObject.FieldPath, e.Type, e.Reason,

Discussion:
Greetings, currently, when doing then in column, the ui result is maybe can do something like this instead? remove then join it with
How about something like ?
Greetings, thanks for the interest, I thought I may throw hacking on it. btw, how about for ?
For we can just print since it's master's component.
Hi looks like there is the same issue reported on the OpenShift Origin github: It would make more sense to solve that upstream. Should we do something together to solve it?
There is a pull request for that:
Change:
Fail(fmt.Sprintf("Internal error: invalid parameters passed to deleteServiceOrFail: clientset: %v, namespace: %v, service: %v", clientset, namespace, serviceName)) } framework.Logf("Deleting service %q in namespace %v", serviceName, namespace) <ins> err := deleteService(clientset, namespace, serviceName, orphanDependents) if err != nil { framework.ExpectNoError(err, "Error deleting service %q from namespace %q", serviceName, namespace) } } func deleteService(clientset *fedclientset.Clientset, namespace string, serviceName string, orphanDependents *bool) error { </ins> err := clientset.CoreV1().Services(namespace).Delete(serviceName, &metav1.DeleteOptions{OrphanDependents: orphanDependents}) <del> framework.ExpectNoError(err, "Error deleting service %q from namespace %q", serviceName, namespace) </del> <ins> if err != nil { return err } </ins> // Wait for the service to be deleted. err = wait.Poll(5*time.Second, fedframework.FederatedDefaultTestTimeout, func() (bool, error) { _, err := clientset.Core().Services(namespace).Get(serviceName, metav1.GetOptions{})

Discussion:
In order to support running tests in parallel, we randomized NodePort selection. There appears to be some evidence that this is not sufficient and is causing e2e test flakes: https://k8s-
Hi, As a need contributor, I'm interesting of solving this issue. I already check the current code, and propose to retry the service creation until success or all possible ports (between FederatedSvcNodePortFirst and FederatedSvcNodePortLast) have been tried. If this approach is fine for you, I can submit a PR soon.
How do you plan to check if the NodePorts are available? In our presubmit test environment, tests run across many instances of federation control planes in parallel, but share the same underlying clusters. So this approach might be viable depending on how and where you plan to check for these used NodePorts.
my approach for getting an available port is a "Dummy" approach: create a list of possible available port, get one of them randomly, then try to create the Service. If Service creation failed. try to use another possible available port, until service creation success or all possible available ports have been tested.
Sounds reasonable to me. Go for it. A couple of caveats: need to create a real list, you could just use the range boundaries. careful about service creation failure. You need to check if the service shard creation failed in the underlying clusters and rollback all those shards before retrying.
thanks for the caveats, I will do soon a PR.
Hi, what is the state of this issue? Is working in this issues with the others issues related to e2e tests?
has a PR to fix this issue -
Change:
if set.Status.Replicas != 3 { t.Error("Falied to scale statefulset to 3 replicas") } <del> pods, err := spc.addTerminatedPod(set, 3) </del> <ins> pods, err := spc.addTerminatingPod(set, 3) </ins> if err != nil { t.Error(err) } <del> pods, err = spc.addTerminatedPod(set, 4) </del> <ins> pods, err = spc.addTerminatingPod(set, 4) </ins> if err != nil { t.Error(err) }

Discussion:
/assign flakes in PR jobs more than once per day The can filter down to searching for results for a single test:
This test continues to flake PRs at least once per day:
https://k8s-
looking at it