jiebi/CodeConvo huggingface dataset:
Change:
load( "@io_bazel_rules_go//go:def.bzl", "go_library", <ins> "go_test", </ins> ) go_library(

Discussion:
From in The most important things I want to see through node e2e tests: 1) the kubelet is started from last-known-good-config file 2) kubelet can download the new config properly to the node; and restart itself from the new config file 3) kubelet can mark the config bad properly after several round of crashing caused the bad config 4) Kubelet can roll back the last-known-good-config and restart itself from that good one 5) kubelet can properly reports its configuration status Note: (2) is covered by existing e2enode tests (1, 4, 5) were covered by the , all of which I plan to turn into automated tests after this PR merges - but I'm trying not to increase the size of this PR any further ~(3) we need to figure out how to test this. I don't want to rely on a "valid" config that causes a crash loop - because the very existence of such a config should be viewed as a bug. I also don't want to include a "please crash loop for our tests" field in the config, because that's an ugly API. The best solution is not clear here.~ We decided to remove crash-loop detection, see . Filing this issue to track this work: into e2e_node tests [x] remote config [x] local (from file) config [x] ~test the crash-loop detection~ removed, see above /cc
[MILESTONENOTIFIER] Milestone Removed Important: This issue was missing labels required for the v1.8 milestone for more than 7 days: kind: Must specify exactly one of [, , ]. priority: Must specify exactly one of [, , ]. Removing it from the milestone. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
The test cases in the OP have been covered by our e2e_node tests for a while.
Change:
load( "@io_bazel_rules_go//go:def.bzl", "go_library", <ins> "go_test", </ins> ) go_library(

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 tried to use  in a unit test, however I get a nil pointer panic when is invoked. What you expected to happen: would return a that doesn't panic on any method call. Ideally, it would allow me to interact with the client in someway for testing. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: client-go version: 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 testing
I believe this also impacts returning logs via a reactor as does not implement
Seems to be a problem with . Since we're creating the request with all empty fields. Not sure what the best way it to resolve this. The best thing I came up with is to use to return a request with everything set up. But I'm a noob here so that's just a shot in the dark :man_shrugging:
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
/remove-lifecycle stale
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
The request returned has a nil which is used in the
I have filed a PR trying to fix this issue.
Change:
<ins> apiVersion: v1 kind: ReplicationController metadata: name: test-rc labels: name: test-rc spec: replicas: 1 template: metadata: labels: name: test-rc spec: containers: - name: test-rc image: nginx ports: - containerPort: 80 </ins>

Discussion:
kubectl create, delete, etc. can already take a List object. kubectl apply can take the list object when it does creation, but it gives an (ugly) error when it's configuring the objects. Then... expected: Actual:
what's you ?
0-alpha.5
Sounds like a bug. Are you interested in taking a look
sure I will take a look during this weekend.
I think the root cause is , the actually is , in the origin , is not , but after the , this object is nil. Would you like to double check this?
I'll take a look.
if you have make sure about this, please let me know. Thanks :)
Is there any ways we could get this into 1.2? It's actually making our config generation quite painful to have to make a separate file for every object. It looks like got pretty far? would you like to make a PR that we can review?
I don't see how. It could have made 1.2 if a PR had been sent within a few days of the issue being filed.
I unassigned all issues assigned to you. Please only assign issues that are actively being worked on, so that others can know which issues are available to be picked up.
My apologies. If I'm not mistaken, this issue was filed after the code freeze for 1.2. I didn't realize that it was time critical or that it could make the release at that time. However, I should have asked. Sorry for the inconvenience. Thank you. I still plan to address those issues for the next release, as discussed, but will assign each one to myself as I work on it.
I created which fixes this. I'm really hoping we can get this into 1.2 since it's a pretty small, isolated fix but a pretty big bug that is complicating our config generation system. Let me know what else I can do to help.
Thanks for the PR. We're short on reviewer bandwidth at the moment. I assigned it to Clayton for review or delegation.
Change:
if !reflect.DeepEqual(stateData, item.wantStateAfterPreFilter) { t.Errorf("state got after prefilter does not match: %v, want: %v", stateData, item.wantStateAfterPreFilter) } <del> t.Logf("call Filter and check status") </del> <ins> t.Logf("Verify: call Filter and check status") </ins> gotStatus := p.Filter(ctx, state, item.pod, nodeInfo) if !reflect.DeepEqual(gotStatus, item.wantFilterStatus) { t.Errorf("filter status does not match: %v, want: %v", gotStatus, item.wantFilterStatus)

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: The unit test Which test(s) are flaking: Testgrid link: Reason for failure: In volume scheduling, we maintain internal caches that watch for PV/PVC events. However, we don't have a method to wait for them to be synced in UT. When the cache in the informer factory is synced but the execution of registered handlers may not finish. <!-- In production, this is not a problem. Even if the scheduler marks the pod uncacheable due to the stale cache in PVAssumeCache/PVCAssumeCache, the pod will be moved to the active queue later as the scheduler . related: --Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated
/sig scheduling /sig storage
Even if I check the PV/PVC assume cache and wait for PV/PVC objects to be into the cache, the PV/PVC objects may not be . It seems that the shared informer with the fake client has a bug that registered event handlers may not be called (or handlers are not registered successfully).
The share informer with the fake client may miss events of objects which are created before caches are synced. it's better to create testing objects before starting the informers
Although the event handlers may not finish when the caches were synced in theory, however, it seems it's not necessary to wait for PV/PVC assume cache to be synced practically. I've run a thousand times (parallel: 10) with locally and no failures.
Change:
) // SystemPriorityClasses defines special priority classes which are used by system critical pods that should not be preempted by workload pods. <ins> // NOTE: In order to avoid conflict of names with user-defined priority classes, all the names must // start with scheduling.SystemPriorityClassPrefix which is by default "system-". </ins> var SystemPriorityClasses = map[string]int32{ "system-cluster-critical": SystemCriticalPriority, "system-node-critical":    SystemCriticalPriority + 1000,

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:
import ( "fmt" <ins> "reflect" </ins> "testing" "github.com/GoogleCloudPlatform/kubernetes/pkg/api"

Discussion:
We have seen that on VirtualBox in particular kubelet picks first interfaces, which is usually NATed and is of no use. In particular the issue comes up with service IP, which gets mapped to endpoint on the NATed interface.
If this is still a problem, can you explain more - I don't quite understand - and suggest heuristics for better solutions?
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Change:
} return nil } <ins> func isNamespaced(gvr schema.GroupVersionResource, discoveryClient discovery.DiscoveryInterface) (bool, error) { if gvr.Resource == "*" { return true, nil } apiResourceList, err := discoveryClient.ServerResourcesForGroupVersion(schema.GroupVersion{ Group: gvr.Group, Version: gvr.Version, }.String()) if err != nil { return true, err } for _, resource := range apiResourceList.APIResources { if resource.Name == gvr.Resource { return resource.Namespaced, nil } } return false, fmt.Errorf("the server doesn't have a resource type '%s' in group '%s'", gvr.Resource, gvr.Group) } </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! If the matter is security related, please disclose it privately via --What you expected to happen: if returns true I expect to be able to perform the action without issue. Note in this case my service user has a rolebinding in a single namespace (and that is also what my kubecontext is set to.) if I change my default to a different namespace then the command returns false How to reproduce it (as minimally and precisely as possible): create a namespace (test) create a service account in that namespace create a role that gives get list and watch permissions to create a rolebinding from that role to the service account. Anything else we need to know?: this is special because namespaces are not scoped to a namespace. if you replace the command with then you get the exepcted result however this breaks the path of least suprise. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig auth
asks the authorization system if the given verb can be performed on the given noun at the given scope. It does not interpret whether the resource exists at that scope. We could warn if we find the specified resource and it does not exist at the specified scope (just like we warn if you ask about a resource that we can't find), but we would still interrogate the authorization system and return the results as we do today. /kind feature /remove-kind bug
/cc
Change:
recorder), NewRealStatefulSetStatusUpdater(kubeClient, setInformer.Lister()), history.NewHistory(kubeClient, revInformer.Lister()), <ins> recorder, </ins> ), pvcListerSynced: pvcInformer.Informer().HasSynced, queue:           workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), "statefulset"),

Discussion:
An issue to make bot happy for When StatefulSet finds any of its pods in phase Failed it will delete it and create it again. While doing so it will emit delete+create event which is really confusing for the user as he has no idea what's happening. /sig apps
Change:
package pidlimit import ( <ins> "fmt" </ins> "io/ioutil" "strconv" <ins> "strings" </ins> "syscall" "time" <del> "k8s.io/apimachinery/pkg/apis/meta/v1" </del> <ins> v1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> statsapi "k8s.io/kubelet/pkg/apis/stats/v1alpha1" )

Discussion:
Condition PIDPressure is not set to true when the system thread number exceeds even it's reaching the limit. Condition PIDPressure is set to true correctly See cause below The bug is due to , which truncates any process number greater than because of type conversion. See kernel code . Reading it from should be working. v1.23.1 <detailsNA </details<details</details<details</details<details</details<details</details
/sig node
/triage accepted /priority important-longterm
Change:
} pl, ok := obj.(*example.PodList) if !ok { <del> t.Fatalf("Expected PodList but got %t", pl) </del> <ins> t.Fatalf("Expected PodList but got %v", pl) </ins> } if len(pl.Items) != 3 { t.Errorf("Expected PodList of length 3 but got %d", len(pl.Items))

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: Unit tests are failing with the latest golang(1.12) What you expected to happen: Tests should pass without any fauilures. 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: Others:
/sig api-machinery
Change:
{% endif %} {% endif %} - logrotate <del> {% if grains['cloud'] is defined and grains['cloud'] == 'azure' %} - openvpn-client {% else %} - sdn {% endif %} </del> - monit 'roles:kubernetes-master':

Discussion:
On latest pull, the Vagrant kube- scripts completes successfully, but the Salt setup in the minion keeps going forever. End result is a cluster that is not useable. Looking at '/var/log/salt/minion' on the minion box, see lots of entries like: 2015-03-04 20:09:11,952 [ ][INFO ] Starting a new job with PID 2015-03-04 20:09:11,954 [ ][INFO ] Returning information for job: 2015-03-04 20:09:12,027 [ ][DEBUG ] Decrypting the current master AES key 2015-03-04 20:09:12,028 [ ][DEBUG ] Loaded minion key: 2015-03-04 20:09:12,217 [ ][INFO ] User vagrant Executing command with jid 2015-03-04 20:09:12,217 [ ][DEBUG ] Command details {'tgt_type': 'glob', 'jid': '', 'tgt': '*', 'ret': '', 'user': 'vagrant', 'arg': [], 'fun': ''} No other help looking at the master's salt log. This is Vagrant 1.7.2, with VirtualBox 4.3.20 on Mac OSX (Yosemite).
Is this repeatable for you if kube-down and kube-up?
Yes, this is reproducible on my laptop. But, I was able to get it up by doing a kube-push after the failed kube-up. , Eric Tune wrote:
Self assigning and will try to reproduce. Sent from my iPhone
I was able to reproduce. It appears that the Kubelet fails to start properly on first start:
The push basically caused the Kubelet to restart, and then it does work. Without the push, systemd would have eventually restarted the Kubelet. We need more investigation as to what was causing the Kubelet to fail on initial startup.
Change:
"finalizer.go", "io_util.go", "metrics.go", <ins> "nested_volumes.go", </ins> "resize_util.go", "util.go", ] + select({

Discussion:
This bug affects any pod that has a container with a nested volume (any type) beneath an API data volume, such as a secret, configMap, downwardAPI or projected volume. In the description and reproduction details below I use a secret volume, but any of the four will demonstrate this behavior. Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When creating a pod with nested secrets volumes (e.g. one volume mounted at and one mounted at ), the container fails to start with an error like: What you expected to happen: The container should start with both and mounted. How to reproduce it (as minimally and precisely as possible): out master, any version since a file with 2 secrets and a pod that makes volumes for the 2 secrets, with one of them mounted within the other: the 2 secrets and the pod. Assuming you named the above file : Anything else we need to know?: This may work for other runtimes if they create mountpoints outside of the sandbox. But it's definitely broken with Docker as the runtime.
This should be fixed by /sig storage /sig node /assign
Change:
fi else case "${KUBERNETES_PROVIDER}" in <del> gce|gke) </del> <ins> gce|gke|kubemark) </ins> files="${files} ${gce_logfiles}" ;; aws)

Discussion:
It seems that we stopped uploading logs to GCS around Friday/Saturday. As examples, this is the first kubemark-scale run that doesn't have logs: But we also don't have any logs e.g. for kubernetes-gce-e2e suite (which seems to be our main suite), e.g.: This seems to be the last run, for which we have logs: which suggests that it was broken around 2016-10-08 01:00:00
P0 - because it makes any debugging roughly impossible.
is working on this
It seems that after fixes from yesterday, we are still lacking logs from all kubemark runs.
Lack of kubemark logs is significantly slowing down any scalability-related work, which is our P0 goal for this quarter, so please prioritize it. - FYI ^^
As an example: [is a run from an hour ago] and it contains only file.
I'm going to migrate this job over to where our code (rather than a jenkins plugin) captures and uploads logs, which we want to do anyway and will hopefully resolve this. Odd... if we look at job/kubernetes-e2e-gce/configure we will a bunch of conditional build steps in the post-build actions configuration, which matches what is specified in yaml: We also have this specified in kubemark yaml: However I don't see where this is applied in the actual configuration: /job/kubernetes-kubemark-gce-scale/configure
I suspect that the job updater ran at some point this weekend while the conditional build step plugin wasn't working, so it wasn't able to add that step. I'm not sure why it hasn't rectified it since.
That seems to be the problem. I've cleared the job cache and done a full rebuild, so gce-scale and anything else that was updated why the postbuild plugin was missing should be fixed now.
Hmm - it doesn't seem to be fully fixed. Basically, we used to have logs from kubemark master machine, e.g.: (there is this kubemark-500-kubemark-master/ directory) However, even now (this is the last run), we no longer have those logs: So something is still broken...
Any thoughts about it? The logs are still missing, e.g.:
All the files in _artifacts are being properly uploaded.

Something else is failing to copy the logs onto the node. In In , it seems to be copying more: Did something else change in kubemark between these time periods? Is scp from the master broken now? This is a separate issue.
I'm not aware of any other changes. - we should try to debug it tomorrow.
We did touch recently in . Might be related.
Yeah, I was just trying to work out if it was. I tried to keep the fake path alive as best I could.
- if you could figure out if it was because of your PR (timing matches) that would be great...
I confirm that this is fixed now. - thanks a lot for fixing this!
Change:
"involvedObject.namespace": f.Namespace.Name, "reason":                   "Failed", }.AsSelector().String() <del> err = framework.WaitTimeoutForPodEvent(f.ClientSet, pod.Name, f.Namespace.Name, selector, errorMsg, framework.PodEventTimeout) </del> <ins> err = framework.WaitTimeoutForPodEvent(f.ClientSet, pod.Name, f.Namespace.Name, selector, errorMsg, framework.PodStartTimeout) </ins> Expect(err).NotTo(HaveOccurred(), "while waiting for failed event to occur") }

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: From , it took around a minute for the CSI plugin to register. It would be good to understand why it took so long and if it's normal/expected. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
is this a blocker for 1.13? do we have a baseline of how long its expected to take for the registration?
I took a look at this. Looks like the external sidecar causes the delay (see ): So, failed to connect to CSI driver, and took a minute to fail. Here are the logs from the host path CSI driver side (see ): So it looks like the tries to open a connection a split second before the CSI hostpath driver starts listening: And the takes a minute to fail/recover from that. Based on this, the issue does not seem to be due to any code in . And is not a blocker for 1.13. I will open an issue on the driver-registrar to track if this delay can be reduced.
Opened Closing this.
Good investigation! Then, should we add some codes to check if driver-registrar complete driver registration with more than 1 minute timeout? IIUC, tests may flake by trying to attach volume before driver become ready in any tests, unless we don't add this kind of logic. To achieve it, I think that we would be able to check string from driver-registrar pod by the same way to , at the end of each driver's .
Can we try the grpc options used in other spots? Looks like the current options for the connect are here: cadvisor for example has and
will do!
Change:
registry                = initReg() dockerLibraryRegistry   = registry.DockerLibraryRegistry e2eRegistry             = registry.E2eRegistry <ins> e2eGcRegistry           = "gcr.io/kubernetes-e2e-test-images" </ins> gcAuthenticatedRegistry = registry.GcAuthenticatedRegistry gcRegistry              = registry.GcRegistry googleContainerRegistry = registry.GoogleContainerRegistry

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: All sig-windows jobs (master): Which test(s) are failing: [] Container Runtime blackbox test when running a container with a new image should be able to pull from private registry with secret [NodeConformance] [] Container Runtime blackbox test when running a container with a new image should be able to pull image from [NodeConformance] Since when has it been failing: Since this PR merged: Testgrid link: Reason for failure: The mentioned PR removed hardcoded image names from tests, centralizing them into , but there were a few omissions: entry was written for. registry set for ` is because that registry contains the Windows images needed for all the Kubernetes E2E tests. Anything else we need to know: /sig testing /sig windows /area conformance /priority important-soon