jiebi/CodeConvo huggingface dataset:
Change:
return result } <ins> func isJobFinished(j *experimental.Job) bool { for _, c := range j.Status.Conditions { if c.Type == experimental.JobComplete && c.Status == api.ConditionTrue { return true } } return false } </ins> // byCreationTimestamp sorts a list by creation timestamp, using their names as a tie breaker. type byCreationTimestamp []experimental.Job

Discussion:
Ran a test executable with more than 20,000 times and no failures. Any hints as to how to get it to show up? I'm running 100 jobs at a time, so my system is stressed already.
I to am unable to reproduce this. I get similar errors if I reduce the timeout at the top of the file. I spent a bit looking at how to rewrite the tests without the timeout, but nothing jumped out at me. Looking at it though, it's really just a 500ms timeout for the test to complete. I'm just going to remove them. Go has a default timeout of 10 minutes. If it's going to pass, it will pass then. If not, Go will give you a nice traceback where it deadlocked.
Change:
By("apply file doesn't have replicas") framework.RunKubectlOrDieInput(deployment2Yaml, "apply", "set-last-applied", "-f", "-", nsFlag) <del> By("check last-applied has been updated, annotations doesn't replicas") </del> <ins> By("check last-applied has been updated, annotations doesn't have replicas") </ins> output = framework.RunKubectlOrDieInput(deployment1Yaml, "apply", "view-last-applied", "-f", "-", nsFlag, "-o", "json") requiredString = ""replicas": 2" if strings.Contains(output, requiredString) { <del> framework.Failf("Missing %s in kubectl view-last-applied", requiredString) </del> <ins> framework.Failf("Presenting %s in kubectl view-last-applied", requiredString) </ins> } By("scale set replicas to 3")

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: At e2e test for kubectl above, success scenario is key is not contained in result of . But test failure message is , in spite of key is contained. What you expected to happen: When test for absence of key failed, correct message is . 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:none, hack/local-up- OS (e.g. from /etc/os-release):16.04.5 LTS (Xenial Xerus) Kernel (e.g. ):4.4.0-124-generic Install tools:hack/local-up- Others:
/sig cli
Change:
return fmt.Errorf("failed to create log directory %q: %w", logPath, err) } // Copy logs (if any) to artifacts/hostname <del> if _, err := SSH(host, "ls", fmt.Sprintf("%s:%s/results/*.log", GetHostnameOrIP(host), testDir)); err == nil { </del> <ins> if _, err := SSH(host, "ls", fmt.Sprintf("%s/results/*.log", testDir)); err == nil { </ins> if _, err := runSSHCommand(host, "scp", "-r", fmt.Sprintf("%s:%s/results/*.log", GetHostnameOrIP(host), testDir), logPath); err != nil { return err }

Discussion:
As we are debugging nodee2e tests, we realize that we are missing kubelet logs and services. Kubelet logs allow us to see problems with kubelet which would be useful for all nodee2e jobs. Services are the other components that are started. I saw some warnings related to startup of apiserver so it would be nice to have these logs to troubleshoot.
/sig node
/assign
/triage accepted /priority important-longterm was this changed recently? I remember having seen not so long ago
It depends what tests you are looking at. The Kind e2e one do have but I didn't see any in the node_e2e ones. I'll do some research into that.
you are correct. Some of the jobs do have I am still trying to find out why a select few tests have a lot more logs than others. One thing I am noticing is that the jobs that are migrated to the community cluster seem to have much fewer logs. For example, is not yet migrated to the community cluster and it looks like we get a bunch of logs. Job Config: is migrated to community cluster and I don't see any extra logs here. Job Config:
/assign
Change:
} } switch { <ins> case waiting > 0: // One or more containers has not been started return api.PodPending, nil </ins> case running > 0 && unknown == 0: <ins> // All containers have been started, and at least // one container is running </ins> return api.PodRunning, nil case running == 0 && stopped > 0 && unknown == 0: <del> return api.PodFailed, nil case running == 0 && stopped == 0 && unknown > 0: return api.PodPending, nil </del> <ins> // All containers are terminated if pod.Spec.RestartPolicy.Always != nil { // All containers are in the process of restarting return api.PodRunning, nil } if stopped == succeeded { // RestartPolicy is not Always, and all // containers are terminated in success return api.PodSucceeded, nil } if pod.Spec.RestartPolicy.Never != nil { // RestartPolicy is Never, and all containers are // terminated with at least one in failure return api.PodFailed, nil } // RestartPolicy is OnFailure, and at least one in failure // and in the process of restarting return api.PodRunning, nil </ins> default: return api.PodPending, nil }

Discussion:
I'm actually not sure if it's by design. But certainly replication controller doesn't behave like it expects this.
If restart policy is to restart always, they should be restarted, but in that case they shouldn't be reported as failed.
This is a known issue, and by design based on upper-level will observe the status reported from kubelet, but not check with RestartPolicy and generate PodCondition / PodStatus. When RestartPolicy is Always, even Kubelet reports all containers are at failed state, apiserver shouldn't mark Pod as failed state. This is why initially I want kubelet report Pod state / status / condiction.
As a quick fix, we could let apiserver populate the right state / status based on containerStatus and RestartPolicy for now. In a long term, I still think we should make kubelet smarter and atomic and self-contained component, not just a wrapper around docker.
Short term fix should be P1 then we can de-prio for a "realer" fix.
Yes, I am working on the short term fix, and should have it included in 0.6 cut.
are you still working on this?
Yes, I am working on this. Should finish it today.
Change:
<del> 1.2 </del> <ins> 1.3 </ins>

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!--What happened: The image used in the Statefulset e2e tests: doesn't work because is missing in the image and the entrypoint is a bash script (). What you expected to happen: The image should be able to execute the entrypoint. How to reproduce it (as minimally and precisely as possible): Run the image with the same args as used in the manifests: Anything else we need to know?: Can fix the issue by adding to the install command: and building a new image: But I don't know if this is the right way since I don't fully understand the whole BASEIMAGE infrastructure and what's supposed to go where. Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig testing
Change:
<del> 1.2 </del> <ins> 1.3 </ins>

Discussion:
<!-- STOP -- PLEASE READ! GitHub is not the right place for support requests. If you're looking for help, check the or our . You can also post your question on the or the forum. If the matter is security related, please disclose it privately via --s390x support for nonewprivs image was in and the commit from was cherry picked in to fix agnhost broken on s390x. However, the post merge job failed for both( ) as image builder was broken. Now that image builder has been fixed in , these jobs need to be restarted to push s390x tags of agnhost and nonewprivs in staging bucket. cc
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 testing
as you are on call this week, can you please run the CI job mentioned by hand?
, when I try to run the job with , it failed with . So I went over and looked at the history and found that this job was deleted by on 11/11. I don't think prow allows running a job that doesn't exist in its configmap, and searching the prow history with got: This is the list of jobs that have ever ran since prow keeps all history in GCS, which indicates that not all of the new jobs in has ran yet, can you take a look at and let us know which job is that you want?
thanks for looking. let's ask what jobs need to be triggered.
Hello, The post-kubernetes-push-e2e-test-images has been split into individual jobs for individual images and are now triggered by changes made in that image's folder. The jobs haven't been run yet since the split. You can trigger a job by sending a PR (e.g.: bumping the VERSION) and getting it merged.
/reopen Still failing according should fix it.
Reopened this issue. <detailsIn response to : /reopen Still failing according should fix 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
/close I am closing this issue as the agnhost job passed and the multiarch image is now available, it works fine for s390x as conformance job passed with the same
Closing this issue. <detailsIn response to : /close I am closing this issue as the agnhost job passed and the multiarch image is now available, it works fine for s390x as conformance job passed with the same 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:
tags = ["automanaged"], deps = [ "//pkg/apis/rbac:go_default_library", <ins> "//pkg/features:go_default_library", </ins> "//vendor/github.com/golang/glog:go_default_library", "//vendor/k8s.io/apimachinery/pkg/api/meta:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/runtime:go_default_library", "//vendor/k8s.io/apiserver/pkg/authentication/user:go_default_library", <ins> "//vendor/k8s.io/apiserver/pkg/util/feature:go_default_library", </ins> ], )

Discussion:
/kind feature From: Would it make sense to add these rules to the bootstrappolicy? To me they seem generic enough, and they wouldn't bind to something. Consumers can do the binding to their subjects as they like. I'm asking because it's already duplicated twice for two early adopters: I don't think those ClusterRoles are specific to kubeadm and GKE at all; but the ClusterRoleBindings will surely be, so therefore we'd create the roles but not the bindings.
Wouldn't we expect and encourage people using the CSR capability for their nodes to use node identities that match the node authorizer, in which case we won't need the client or server renewal CSR roles?
The node authorizer doesn't grant these, since otherwise you could never prevent a compromised node from renewing its credentials
Realistically, with these roles you still wouldn't. People would grant them to the node group, not each individual node, but I guess that would be a tradeoff for the deployment mechanism.
You could individually revoke this role from the group and stop renewals without disrupting regular operation
I can definitely see myself revoking a binding from to multiple specific bindings in case of a compromise. Anyway, this issue is more "should we create these by default or not". I've already mentioned my opinion.
Creating the roles seems reasonable. I don't think I want bindings. I think the binding should be up the particular deployer.
Perfect, that's exactly my proposal. I'll go ahead and make this change...
/assign
are you working on this or should I send a PR?
Change:
// FieldImmutableErrorMsg is a error message for field is immutable. const FieldImmutableErrorMsg string = `field is immutable` <del> const totalAnnotationSizeLimitB int = 256 * (1 << 10) // 256 kB </del> <ins> const TotalAnnotationSizeLimitB int = 256 * (1 << 10) // 256 kB </ins> // BannedOwners is a black list of object that are not allowed to be owners. var BannedOwners = map[schema.GroupVersionKind]struct{}{

Discussion:
Expose totalAnnotationSizeLimitB in the validation package: This value is useful for validating annotations outside of the validation package, such as in SSA: Otherwise, size validation on annotations outside of the package would diverge and cause issues later. /kind cleanup /wg api-expression cc
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:
<ins> all: push TAG = 0.1 container: docker build -t gcr.io/google_containers/kubekins-test . docker tag gcr.io/google_containers/kubekins-test gcr.io/google_containers/kubekins-test:$(TAG) push: container gcloud docker push gcr.io/google_containers/kubekins-test # Push image tagged as latest to repository gcloud docker push gcr.io/google_containers/kubekins-test:$(TAG) # Push version tagged image to repository (since this image is already pushed it will simply create or update version tag) clean: </ins>

Discussion:
In the pull request Jenkins, we're running up to 8 instances of verification checks, build, unit tests, integration tests, and e2e tests. Unfortunately, it seems like several of these components were not designed to run simultaneous to other tests on the same machine. In particular, several unit tests seem to write to static file names in /tmp (or equivalent), which is a fairly easy fix. Some of the verification checks and the integration test start up etcd, however, and the etcd helper checks that only a single etcd binary is running on the host (and uses a static port for it). For example: We might be able to fix the etcd issue separately, or we can just figure out how to containerize all of these tests so they can't possibly interfere with each other. Note that we're ignoring the exit status of the verification checks and unit/integration tests right now, so these etcd failures are effectively being ignored (though it is causing us to miss test coverage).
What percentage of tests are failing due to being non-hermetic like this?
I'm not sure about unit tests (I've anecdotally seen just a few fail), but the verification checks are failing fairly regularly, and the integration test is also similarly frequently not running due to this.
To be clear, I'm looking for real numbers, to decide whether it's feasible to temporarily disable a small number of tests until we can hermetify them. Otherwise we need to turn off all unit, integration and verification tests in Jenkins to avoid irritating invalid regression signals. We need to do one or the other this week.
I'll try to dig through the logs, figure out which ones have failed recently, disable them in Jenkins, and see whether the flakes abate.
I just turned off all unit, integration and verification checks in Jenkins, as a temporary measure to unstall the merge-bot.
As a point of information, I just found approximately 20 tests in which use a static tmp path with semi-random filenames which are highly likely to collide. We could keep searching for unit tests that are non-hermetic, but it'd probably be a better investment of time to fix the test infrastructure so test authors don't need to care (and so we don't need to go look at and fix ~2000 test cases).

Another few metrics, using the string "/tmp" as a likely anti-pattern: We'd need to update each of these 23 files to get them to use or if they aren't already.
Created to track cleaning up tempdir usage in unit tests.
cc
Change:
return f.waitingPods.get(uid) } <ins> // RejectWaitingPod rejects a WaitingPod given its UID. func (f *framework) RejectWaitingPod(uid types.UID) { waitingPod := f.waitingPods.get(uid) if waitingPod != nil { waitingPod.Reject("removed") } } </ins> // HasFilterPlugins returns true if at least one filter plugin is defined. func (f *framework) HasFilterPlugins() bool { return len(f.filterPlugins) > 0

Discussion:
What would you like to be : When the pod is scheduled to the phase and I delete the pod, the pod still remains in the until the plugin allow/reject/timeout(Especially when waiting for a long time). Why is this needed: We need to take the initiative to delete the data in the and terminate the process in waiting state of plugin to ensure data accuracy, if the pod has been deleted /cc /priority important-soon /assign /sig scheduling
I think we can update the event handler for deleting pods to reject the pod. Can you send a PR for that?
OKI will send a pr for it.
Change:
} if o.GracePeriod == 0 && !o.ForceDeletion { // To preserve backwards compatibility, but prevent accidental data loss, we convert --grace-period=0 <del> // into --grace-period=1 and wait until the object is successfully deleted. Users may provide --force // to bypass this wait. o.WaitForDeletion = true </del> <ins> // into --grace-period=1. Users may provide --force to bypass this conversion. </ins> o.GracePeriod = 1 } <del> if b, err := cmd.Flags().GetBool("wait"); err == nil { o.WaitForDeletion = b } </del> includeUninitialized := cmdutil.ShouldIncludeUninitialized(cmd, false) r := f.NewBuilder().

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 /sig CLI What happened: Running leads to nil pointer dereference: What you expected to happen: is expected to run delete with wait in that case How to reproduce it (as minimally and precisely as possible): (with any valid resource yaml) Anything else we need to know?: Discovered in when accidentally enabled wait for deletion from other commands than and saw failing integration tests in https://k8s- Environment: Kubernetes version (use ): latest master Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
This bug was introduced in : is set in that requires to be non-nil flag is being set in is normally being set in method which is not invoked in . a result, the invocation of resource finder leads to nil pointer dereference (see stack trace in the description).
/cc
Change:
hash := HashControllerRevision(revision, collisionCount) // Update the revisions name and labels clone.Name = ControllerRevisionName(parent.GetName(), hash) <del> created, err := rh.client.AppsV1().ControllerRevisions(parent.GetNamespace()).Create(clone) </del> <ins> ns := parent.GetNamespace() created, err := rh.client.AppsV1().ControllerRevisions(ns).Create(clone) </ins> if errors.IsAlreadyExists(err) { <ins> exists, err := rh.client.AppsV1().ControllerRevisions(ns).Get(clone.Name, metav1.GetOptions{}) if err != nil { return nil, err } if bytes.Equal(exists.Data.Raw, clone.Data.Raw) { return exists, nil } </ins> *collisionCount++ continue }

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: What happened: When a statefulset object is created, a lot of controllerrevisions are created at the same time. the controllerrevisions have differenct hash value but the same Data.Raw. How to fix it: two controllerrevisions are seen as the same , when [ControllerRevisionHashLabel] , Controllerrevision.Data.Raw , Controllerrevision.Data.Object are strictly the same // this line shoud be to fix the bug like below: Anything else we need to know?: Environment: Kubernetes version (use ): 1.7.8 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I would help fix it
/kind bug /sig apps
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 stale
StatefulSet uses the following code to construct its history object (controllerrevision): However, collisionCount shouldn't be blindly increased when there's name collision. Because controller uses a cache store, the name collision could be due to a controllerrevision created but not yet observed by the controller. The right way to handle it is to first check if the controllerrevision with the same name has the same content as the one we're going to create, like how DaemonSet controller handles it:
Change:
<ins> # How to become a contributor and submit your own code ## Contributor License Agreements We'd love to accept your patches! Before we can take them, we have to jump a couple of legal hurdles. Please fill out either the individual or corporate Contributor License Agreement (CLA). * If you are an individual writing original source code and you're sure you own the intellectual property, then you'll need to sign an [individual CLA](http://code.google.com/legal/individual-cla-v1.0.html). * If you work for a company that wants to allow you to contribute your work, then you'll need to sign a [corporate CLA](http://code.google.com/legal/corporate-cla-v1.0.html). Follow either of the two links above to access the appropriate CLA and instructions for how to sign and return it. Once we receive it, we'll be able to accept your pull requests. ## Contributing A Patch 1. Submit an issue describing your proposed change to the repo in question. 1. The repo owner will respond to your issue promptly. 1. If your proposed change is accepted, and you haven't already done so, sign a Contributor License Agreement (see details above). 1. Fork the desired repo, develop and test your code changes. 1. Submit a pull request. </ins>

Discussion:
When one of the aggregated API servers returns a different definition of an object than what the other servers return, the merged openapi schema may contain multiple identical copies of the object definition (they differ only in the name). Is this a BUG REPORT or FEATURE REQUEST?:BUG /kind bug What happened: After changing the definition of the RawExtension type in one of the aggregated API servers, the aggregator returned the following openapi schema (note that v2, v3 and _v4 are identical; don't mind the actual new definition of RawExtension - it's incorrect): What you expected to happen: The merged schema should only contain two different RawExtension object definitions instead of 4. Environment: Kubernetes version (use ):
/sig api-machinery
/assign