jiebi/CodeConvo huggingface dataset:
Change:
return "", msg, ErrImagePullBackOff } m.logIt(ref, v1.EventTypeNormal, events.PullingImage, logPrefix, fmt.Sprintf("Pulling image %q", container.Image), klog.Info) <ins> startTime := time.Now() </ins> pullChan := make(chan pullResult) m.puller.pullImage(spec, pullSecrets, pullChan, podSandboxConfig) imagePullResult := <-pullChan

Discussion:
What would you like to be : The 'Successfully pulled image' event should contain the duration for image pulling. Why is this needed: Currently the success event is in this form: User has to trace back to the corresponding event for the beginning of image pulling and calculate the duration him/herself:
/sig node /assign
Change:
func TestMonitorNodeStatusEvictPods(t *testing.T) { fakeNow := metav1.Date(2015, 1, 1, 12, 0, 0, 0, time.UTC) evictionTimeout := 10 * time.Minute <ins> labels := map[string]string{ kubeletapis.LabelZoneRegion:        "region1", kubeletapis.LabelZoneFailureDomain: "zone1", } </ins> // Because of the logic that prevents NC from evicting anything when all Nodes are NotReady // we need second healthy node in tests. Because of how the tests are written we need to update

Discussion:
<!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.0-alpha.1.51+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-06-20T10:51:10Z", GoVersion:"go1.8", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.0-alpha.1.51+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-06-20T11:29:14Z", GoVersion:"go1.8", Compiler:"gc", Platform:"linux/amd64"} What happened: After adding label to a node, node controller panics. What you expected to happen: Everything should still work. How to reproduce it (as minimally and precisely as possible): Run and wait for the node controller to panic: Anything else we need to know: I've checked the code and it looks like the node controller expects the label to be present during node registration and it can not be later. Even if the label can not be latter it shouldn't panic.
/sig node
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/assign let me try this :).
Change:
"//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/uuid:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/watch:go_default_library", </ins> "//staging/src/k8s.io/apiserver/pkg/apis/audit:go_default_library", "//staging/src/k8s.io/apiserver/pkg/apis/audit/v1:go_default_library", "//staging/src/k8s.io/apiserver/pkg/authentication/serviceaccount:go_default_library",

Discussion:
[ ] Promotion created According to this APIsnoop query, there are still some remaining ServiceAccount endpoints which are untested. Create a ServiceAccount with a static label Create a Secret Patch the ServiceAccount with a new Label and a new Secret Get the ServiceAccount to ensure it's patched List all ServiceAccounts in all Namespaces find the ServiceAccount(1) ensure that the ServiceAccount is found and is patched Delete Namespaced ServiceAccount(1) via a Collection with a LabelSelector Delete the Secret Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
Fine with moving forward You don't need to check the status of the secret as part of the test. In other places we check that the resource in question happens, we don't have to follow.
/reopen
Reopened this issue. <detailsIn response to : /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
/retitle Write CoreV1ServiceAccount resource lifecycle test+promote - +3
/close close this Issue in favour of and place in In Progress Issues on org dashboard
Closing this issue. <detailsIn response to : /close close this Issue in favour of and place in In Progress Issues on org dashboard </details
Change:
if err := verifyKubectlExplain(f.Namespace.Name, crd.Crd.Spec.Names.Plural+".spec", `(?s)DESCRIPTION:.*Specification of Foo.*FIELDS:.*bars.*<[]Object>.*List of Bars and their specs`); err != nil { framework.Failf("%v", err) } <del> if err := verifyKubectlExplain(f.Namespace.Name, crd.Crd.Spec.Names.Plural+".spec.bars", `(?s)FIELD:.*bars.*<[]Object>.*DESCRIPTION:.*List of Bars and their specs.*FIELDS:.*bazs.*<[]string>.*List of Bazs.*name.*<string>.*Name of Bar`); err != nil { </del> <ins> if err := verifyKubectlExplain(f.Namespace.Name, crd.Crd.Spec.Names.Plural+".spec.bars", `(?s)(FIELD|RESOURCE):.*bars.*<[]Object>.*DESCRIPTION:.*List of Bars and their specs.*FIELDS:.*bazs.*<[]string>.*List of Bazs.*name.*<string>.*Name of Bar`); err != nil { </ins> framework.Failf("%v", err) }

Discussion:
master-informing kubeadm-kinder-upgrade-1-26-latest kubeadm-kinder-latest 03-15 04:46 IST No response /sig api-machinery
this is a conformance test, so something has to happen with this specific environment, or it should be failing in all jobs The fact that the job name has upgrade in the name indicates that there can be some skew problem, which e2e test run this job and against which version?
Confirmed this is passing in other jobs This is related to this specific job
Can we add to the conformance test? I tried a fix like
/triage accepted
Change:
import ( "fmt" <ins> "sort" </ins> "time" "k8s.io/kubernetes/pkg/api"

Discussion:
I've noticed at least 10 separate test flake issues open in which at least one failure looks like this: Current list: &q=is%3Aissue%20label%3Akind%2Fflake%20is%3Aopen%20%22was%20not%20deleted%20within%20limit%22 The 10 current issues (note that some are 'broken test run' issues and might have multiple failure causes): cc
Just to clarify, the pods were deleted in the test (hence the message). I mentioned this before in
I was chasing down another p0 but now that that is resolved will try to look for more that we can do here. On Wednesday, July 27, 2016, Yu-Ju Hong wrote:
- why did you close this - this is happening quite frquently.
Thanks for reopening! We will now automatically choose and owner for auto-opened flake issues. I closed a bunch of old flakes that were created with no assignee. I want them to get recreated with an assignee. The hope is someone will actually look at these.
is another example of this flake.
has the same symptom too.
One more example: would it help if we bump the timeout from 5 min to N (e.g., 8) min? or should we ask tests that create significant number of pods to clean up after themselves?
I am going to try and look at optimizing the requeue behavior for tests that have a lot of pods and we are waiting for them to delete. Looks like once they delete, we don't observe their deletion until the next resync
Opened a PR to improve e2e framework ns deletion to avoid duplicate ns delete operations, and to give more detailed information on what content did not actually get deleted.
Change:
return true, nil } <ins> // check if a Pod is controlled by a Replication Controller in the List func hasReplicationControllersForPod(rcs *api.ReplicationControllerList, pod api.Pod) bool { for _, rc := range rcs.Items { selector := labels.SelectorFromSet(rc.Spec.Selector) if selector.Matches(labels.Set(pod.ObjectMeta.Labels)) { return true } } return false } </ins> // waitForPodsRunningReady waits up to timeout to ensure that all pods in <del> // namespace ns are running and ready, requiring that it finds at least minPods. // It has separate behavior from other 'wait for' pods functions in that it re- // queries the list of pods on every iteration. This is useful, for example, in // cluster startup, because the number of pods increases while waiting. </del> <ins> // namespace ns are either running and ready, or failed but controlled by a // replication controller. Also, it ensures that at least minPods are running // and ready. It has separate behavior from other 'wait for' pods functions in // that it requires the list of pods on every iteration. This is useful, for // example, in cluster startup, because the number of pods increases while // waiting. </ins> func waitForPodsRunningReady(ns string, minPods int, timeout time.Duration) error { c, err := loadClient() if err != nil {

Discussion:
On a healthy test cluster the health check looks like this: On a failed cluster it looks like this:
Possibly related to ?
this has elasticsearch logging failing.
As per discussion with I think that the solution here is to ignore failed pods for these test cluster health checks. The failed pods were all correctly restarted by the relevant replication controllers, so the tests should have been able to proceed in this and all the other similar cases that we looked at. Why the pods failed is a separate question, which will hopefully be detected and fixed elsewhere.
It might be due to
Just waiting for oncall to merge
Change:
// restart iptables"?). So instead we just manually delete all "KUBE-" // chains. <del> ginkgo.By("dumping iptables rules on a node") </del> <ins> ginkgo.By("dumping iptables rules on node " + host) </ins> result, err := e2essh.SSH("sudo iptables-save", host, framework.TestContext.Provider) <ins> e2essh.LogResult(result) </ins> if err != nil || result.Code != 0 { <del> e2essh.LogResult(result) </del> framework.Failf("couldn't dump iptable rules: %v", err) }

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: ci-kubernetes-e2e-gci-gce-alpha-features Which test(s) are failing: Networking should recreate its iptables rules if they are deleted [Disruptive] Since when has it been failing: Commit Testgrid link: Reason for failure: Anything else we need to know: Possibly related to this? It's listed in the git diff /sig network
/assign /cc Thanks for detecting it so quicklly
most probably is related to
/unassign /assign he has already submitted a fix
/triage accepted
Reviewed. Marking as resolved on the CI Signal Board. Once was merged, failures stopped and they have not re-occurred in the last 8 days (Oct 10th)
Yay
Change:
} mapper, typer := f.Object() <del> b := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand(cmd)). </del> <ins> b := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand()). </ins> ContinueOnError(). NamespaceParam(cmdNamespace).DefaultNamespace(). SelectorParam(selector).

Discussion:
I think the need for this argument to the factory methods has passed - it means that callers who want to provide configurable behavior have to do it through the factory itself, which is acceptable. We can remove it whenever.
I removed most of the unused arguments. But, There are a few methods still using the argument. Namely, , , and . Before proceeding any further I wanted to ask what should be done about these methods? Deprecated/Refactored/Removed ?
The factory methods were the most important. The pattern before was people using the flags by name (cmd.Flags().Get("foo")), but now factory methods must use pointer flag vars, so there's nothing that should need the command there. The printer methods are optional units that can be used when you add the flags for them to your command. Unless we refactor the definition of those flags to use pointers and return a printer struct (something I had started a while back and never finished), it's not worth changing them right now. The other consumer of factory is OpenShift - we wrap the factory to add our additional types (implementations of things like describers, action verbs, etc): - but we will pick up and remove use of cmd when we rebase.
Thanks for the explanation. I've cleaned the as well. Print method APIs are untouched as you suggested.
cc
Looks like this was done by PR
Change:
return fmt.Sprintf("%d-%d", pr.Base, pr.Base+pr.Size-1) } <del> // Set parses a string of the form "min-max", inclusive at both ends, and </del> <ins> // Set parses a string of the form "value", "min-max", or "min+offset", inclusive at both ends, and </ins> // sets the PortRange from it.  This is part of the flag.Value and pflag.Value // interfaces. func (pr *PortRange) Set(value string) error { <del> value = strings.TrimSpace(value) </del> <ins> const ( SinglePortNotation = 1 << iota HyphenNotation PlusNotation ) </ins> <del> // TODO: Accept "80" syntax // TODO: Accept "80+8" syntax </del> <ins> value = strings.TrimSpace(value) hyphenIndex := strings.Index(value, "-") plusIndex := strings.Index(value, "+") </ins> if value == "" { pr.Base = 0

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Implement this TODO: What you expected to happen: Start kube-proxy with a 'beginPort+offset' format port range configuration. This is needed when I want to allocate specific numbers of port from a host without extra manual calculation. Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig api-machinery
/sig network Does anyone besides kube-proxy use this?
/assign
Change:
srcs = [ "active_deadline.go", "doc.go", <ins> "errors.go", </ins> "kubelet.go", "kubelet_getters.go", "kubelet_network.go",

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Pods are synchronized by kubelet before network is ready. Synchronization in such case fails and pod is synchronized after 10 seconds. What you expected to happen: Kubelet should wait until network is ready before starting synchronizing pods. How to reproduce it (as minimally and precisely as possible): Configure cluster with Cluster Autoscaler enabled. Start pod so cluster is scaled up. In logs you might find following error: E0907 13:18:49. 972 ] Error syncing pod xxxxxx ("xxxxxxxxx(xxxxxxxxxxx)"), skipping: network is not ready: [runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: Kubenet does not have netConfig. This is most likely due to lack of PodCIDR] Environment: Build from HEAD Cloud provider or hardware configuration: GKE
/kind bug /sig node
Change:
<ins> # Copyright 2017 The Kubernetes Authors. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. FROM alpine:3.5 RUN apk add --no-cache redis COPY redis.conf /etc/redis.conf EXPOSE 6379 VOLUME /data CMD ["redis-server", "/etc/redis.conf"] </ins>

Discussion:
Kubernetes version (use ): master What happened: Pulling the redis image takes a while, like 30 seconds in GCE. This might be leading to periodic timeouts in tests like . What you expected to happen: Tests shouldn't depend on large images that take a potentially long time to pull. proposed fix to reduce flakiness we can increase the replica count on this test to 2 or make the redis image we use smaller (or not use redis at all and just use a simpler smaller image)
cc (considering this as a bug since we shouldnt need a 500MG image just to test kubectl :))
This should be as simple as changing the current to use alpine and install redis, instead of basing it off debian, installing gcc, and compiling redis from source :-) The image should be ~10MB.
Change:
if selector.Empty() || !selector.Matches(labels.Set(pod.Labels)) { continue } <ins> // Existing in DisruptedPods means it has been processed in API server, // we don't treat it as a violating case. if _, exist := pdb.Status.DisruptedPods[pod.Name]; exist { continue } // Only decrement the matched pdb when it's not in its <DisruptedPods>; // otherwise we may over-decrement the budget number. pdbsAllowed[i]-- </ins> // We have found a matching PDB. <del> if pdbsAllowed[i] <= 0 { </del> <ins> if pdbsAllowed[i] < 0 { </ins> pdbForPodIsViolated = true <del> } else { // Only decrement the matched pdb when it's not in its <DisruptedPods>; // otherwise we may over-decrement the budget number. if _, exist := pdb.Status.DisruptedPods[pod.Name]; !exist { pdbsAllowed[i]-- } </del> } } }

Discussion:
In one recent fix (), we enhanced the preemption logic to respect . But there is a glitch: if we changed the DisruptedPods in L1499 from "a" to "b", the test would fail it would also fail if we change the pods (i.e., []Pod{"b", "a"}) ordering in L1496~L1497 This is a problem we need to fix. On the other hand, I'm thinking about the real semantics of . According to the docs, if a pod is matched by the "DisruptedPods" list, it denotes the pod is about to be evicted by API server as it at least has violated one disruption budget. Given this fact, IMO in scheduler preemption, we should treat this kind of pod as "nonViolating" in all cases - no matter the current is negative or not. So that the scheduler would treat them as preemption candidates. /sig scheduling
/assign
cc/
Change:
for _, endpointSlice := range slicesToCreate { addTriggerTimeAnnotation(endpointSlice, triggerTime) <del> _, err := r.client.DiscoveryV1beta1().EndpointSlices(service.Namespace).Create(context.TODO(), endpointSlice, metav1.CreateOptions{}) </del> <ins> createdSlice, err := r.client.DiscoveryV1beta1().EndpointSlices(service.Namespace).Create(context.TODO(), endpointSlice, metav1.CreateOptions{}) </ins> if err != nil { // If the namespace is terminating, creates will continue to fail. Simply drop the item. if errors.HasStatusCause(err, corev1.NamespaceTerminatingCause) {

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: With EndpointSlice feature enabled, after EndpointSliceController creates or updates an EndpointSlice when reconciling a Service, the Service would always be processed one extra time, which is triggered by the EndpointSlice /updated event made by itself during the first processing. What you expected to happen: EndpointSliceController shouldn't reprocess a Service due to the EndpointSlice update made by itself. How to reproduce it (as minimally and precisely as possible): EndpointSlice feature, improve kube-controller-manager log to 5. a nginx deployment a Service backed by the above deployment. kube-controller-manager log: the service will be processed twice in succession. Anything else we need to know?: It's because EndpointSliceController tracks stale resource version after creating/updating an EndpointSlice. Environment: Kubernetes version (use ): v1.18.0-alpha.3 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/assign
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
return } <ins> const containerNamePrefix = "k8s" </ins> // Creates a name which can be reversed to identify both manifest id and container name. func manifestAndContainerToDockerName(manifest *api.ContainerManifest, container *api.Container) string { // Note, manifest.Id could be blank. <del> return fmt.Sprintf("%s--%s--%x", escapeDash(container.Name), escapeDash(manifest.Id), rand.Uint32()) </del> <ins> return fmt.Sprintf("%s--%s--%s--%x", containerNamePrefix, escapeDash(container.Name), escapeDash(manifest.Id), rand.Uint32()) </ins> } // Upacks a container name, returning the manifest id and container name we would have used to

Discussion:
release-master-blocking Conformance-GCE-master-kubetest2Kubernetes e2e suite.[It] [sig-network] Services should be able to change the type from ExternalName to ClusterIP [Conformance] ci-kubernetes-gce-conformance-latest-kubetest2.Overall kubetest2.Test 07-11 15:51 EEST No response /sig cloud-provider 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
I remember some timeout has changed with ginkgo2 and something moved from 24hours to 1 hours, or something like that, is it possible that this is the problem here, in this job?
The Grinko timeout change could also be the root problem with this job:
hmm, we have to revisit the flags
hmm, this seems correct
that was a good observations, seems that job is failing because gathering the logs takes too much time !
there is no timeout set in the kubetest2 command here (not sure if this would be the place to set a timeout)
it seems kubetest has to be migrated to ginkgov2 it should use this as basis I'm on vacation this week, can somebody take over and open the issue and patch kubetest2?
looks like this file needs to get updated: add line 72:
oh, you already commented this :D
I will have a look later
Related: umbrella issue:
last testgrid run passed :)