jiebi/CodeConvo huggingface dataset:
Change:
f.PodClient().Delete(devicePluginPod.Name, &metav1.DeleteOptions{}) By("Waiting for GPUs to become unavailable on the local node") Eventually(func() bool { <del> return framework.NumberOfNVIDIAGPUs(getLocalNode(f)) <= 0 </del> <ins> node, err := f.ClientSet.CoreV1().Nodes().Get(framework.TestContext.NodeName, metav1.GetOptions{}) framework.ExpectNoError(err) return framework.NumberOfNVIDIAGPUs(node) <= 0 </ins> }, 10*time.Minute, framework.Poll).Should(BeTrue()) By("Checking that scheduled pods can continue to run even after we delete device plugin.") count1, devIdRestart1 = getDeviceId(f, p1.Name, p1.Name, count1+1)

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?: What happened: The test has been failing since Nov 22nd. Looks like it is because the test restarts Kubelet and then calls getLocalNode() which checks for node readiness. Not sure why this problem only started to show up recently. 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 ): 1.9 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): COS Kernel (e.g. ): Install tools: Others:
/sig node
Hi, Just FYI, . Maybe it is helpful for you.
Change:
func (b *downwardAPIVolumeMounter) SetUpAt(dir string, fsGroup *int64) error { glog.V(3).Infof("Setting up a downwardAPI volume %v for pod %v/%v at %v", b.volName, b.pod.Namespace, b.pod.Name, dir) // Wrap EmptyDir. Here we rely on the idempotency of the wrapped plugin to avoid repeatedly mounting <del> wrapped, err := b.plugin.host.NewWrapperMounter(b.volName, wrappedVolumeSpec, b.pod, *b.opts) </del> <ins> wrapped, err := b.plugin.host.NewWrapperMounter(b.volName, wrappedVolumeSpec(), b.pod, *b.opts) </ins> if err != nil { glog.Errorf("Couldn't setup downwardAPI volume %v for pod %v/%v: %s", b.volName, b.pod.Namespace, b.pod.Name, err.Error()) return err

Discussion:
Data as of June 3rd, 9:00 PM Eastern. Latest data can be found here: Prow link to the 2 jobs: * Additional Context:
/sig storage cc
I'm working on , it's hard to get a job yaml right at the first time. I'll check iscsi. /assign
/triage accepted /kind failing-test
ci-kubernetes-e2e-storage-kind-disruptive fixed: has 1 green run pull-kubernetes-e2e-storage-kind-disruptive fixed: , it fails when it should fail, it's green otherwise, I'll continue with iscsi.
/reopen it's still red, but at least it installs now:
Reopened this issue. <detailsIn response to : /reopen it's still red, but at least it installs now: 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
e2e-gce-iscsi-serial job passes now: e2e-gce-iscsi is getting greener: I'll let it run for few more days to see if today's failures are flakes. /reopen
Reopened this issue. <detailsIn response to : It's getting greener: /reopen </details
iscsi-serial is green:
Change:
expectedList := &unstructured.UnstructuredList{} expectedList.SetGroupVersionKind(listGVK) expectedList.SetResourceVersion("") // by product of the fake setting resource version <ins> expectedList.SetContinue("") </ins> if diff := cmp.Diff(expectedList, list); diff != "" { t.Fatal("unexpected diff (-want, +got): ", diff)

Discussion:
The fake dynamic client does not support mock pagination or the self link. Add ability to propagate the metadata fields from a mock unstructured list to the served list by the fake lister. Repro linked in the MR x-ref. No response <details</detailsN/A N/A <detailsN/A </details<detailsN/A </details<detailsN/A </details
/sig api-machinery
/cc /triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Change:
return errors.NewNotFound(gr, newMeta.GetName()) } <del> t.objects[gvr] = append(t.objects[gvr], obj) </del> <ins> t.objects[gvr][namespacedName] = obj </ins> for _, w := range t.getWatches(gvr, ns) { w.Add(obj)

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 used to fake a clientset to test my code. I found that it became very slow to init the clientset with a big number of objects when I was trying to simulate a large scale cluster, and the time seemed exponential increasing. For example: Initializing a clientset with: 5000 objects took 300ms objects took 2.58s objects took 11.82s objects took 54.64s. It's because the fake clientset used a slice to store each kind of objects, so it's quite slow to init the clientset with massive objects because it checked existence of an object by traversing all objects and comparing with them before adding one, which leads to O(n^2) time complexity. What you expected to happen: The fake clientset is very useful for development, it should have a reasonable time complexity to allow developers to use it for large scale scenario. How to reproduce it (as minimally and precisely as possible): Run this code: You would see the time spent on each operation, like: Anything else we need to know?: Environment: Kubernetes version (use ): 1.15.0-1.18.0 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:
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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 had PR that uses map to store objects, which can reduce the init time to a reasonable value (tens of ms for objects). /assign
Change:
} klog.V(verbosity).InfoS("Event occurred", "object", klog.KRef(event.Regarding.Namespace, event.Regarding.Name), "kind", event.Regarding.Kind, "apiVersion", event.Regarding.APIVersion, "type", event.Type, "reason", event.Reason, "action", event.Action, "note", event.Note) }) <ins> if err != nil { klog.Errorf("failed to start event watcher: '%v'", err) return func() {} } return stopWatcher </ins> } // StartEventWatcher starts sending events received from this EventBroadcaster to the given event handler function. // The return value is used to stop recording <del> func (e *eventBroadcasterImpl) StartEventWatcher(eventHandler func(event runtime.Object)) func() { </del> <ins> func (e *eventBroadcasterImpl) StartEventWatcher(eventHandler func(event runtime.Object)) (func(), error) { </ins> watcher, err := e.Watch() if err != nil { klog.Errorf("Unable start event watcher: '%v' (will not retry!)", err) <del> // TODO: Rewrite the function signature to return an error, for // now just return a no-op function return func() { klog.Error("The event watcher failed to start") } </del> <ins> return nil, err </ins> } go func() { defer utilruntime.HandleCrash()

Discussion:
Follow-up cleanup work for: Most of the information about this issue can be found in , where the work merged with a to change the function signature of to return a func() as well as an error. This issue will help to track that. All TODOs introduced in are resolved. N/A N/A <detailsN/A </details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority low 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
/cc /triage accepted
/priority important-longterm
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Change:
PREEMPTIBLE_NODE=${PREEMPTIBLE_NODE:-false} PREEMPTIBLE_MASTER=${PREEMPTIBLE_MASTER:-false} <del> # Today the cluster startup scripts asssume the master and the nodes use the # same OS distro, thus same set of initialization instructions (e.g., metadata, # startup scripts, etc.). The current workaround is the hack in util.sh that # reloads <os_distro>/helper.sh in the gap between when the master is created # and when the nodes are created. </del> # TODO(#26183): Provide a way to differentiate master OS distro and node OS # distro. OS_DISTRIBUTION=${KUBE_OS_DISTRIBUTION:-gci} <del> # For GCI, leaving it blank will auto-select the latest GCI image on the `dev` # channel. </del> <ins> # By default a cluster will be started with the master on GCI and nodes on # containervm. If you are updating the containervm version, update this # variable. CVM_VERSION=container-v1-3-v20160517 </ins> MASTER_IMAGE=${KUBE_GCE_MASTER_IMAGE:-} MASTER_IMAGE_PROJECT=${KUBE_GCE_MASTER_PROJECT:-google-containers} <del> NODE_IMAGE=${KUBE_GCE_NODE_IMAGE:-container-v1-3-v20160517} NODE_IMAGE_PROJECT=${KUBE_GCE_NODE_PROJECT:-google-containers} </del> <ins> NODE_IMAGE=${KUBE_GCE_NODE_IMAGE:-"${MASTER_IMAGE}"} NODE_IMAGE_PROJECT=${KUBE_GCE_NODE_PROJECT:-"${MASTER_IMAGE_PROJECT}"} </ins> CONTAINER_RUNTIME=${KUBE_CONTAINER_RUNTIME:-docker} RKT_VERSION=${KUBE_RKT_VERSION:-0.5.5}

Discussion:
As of (specifically ), running against GCE without setting a node image defaults it to containervm, whereas before it defaulted it to the master image. For example, my config of: brings up a coreos master and then launches nodes with images. Before the above-referenced change this gave me my expected coreos nodes. Was this change intentional? The easiest fix that comes to mind for me is only doing the new containervm defaulting if is gci. cc
Yeah, this was something I was concerned too while making the change. However, the decision seems to have been that we decided to default to GCI, yet still default to the debian based containervm. Also, if we are to seriously start supporting hybrid clusters, i.e., master and nodes run on different OS distros, which seems true according to , this old assumption of defaults to needs to disappear anyways. cc/ Thoughts?
That sounds reasonable to me. We clearly didn't think about your use case whilst making this change.
I don't see the issue with defaulting to non-hybrid while supporting hybrid.. Defaulting seems totally reasonable even in a world where hybrid support is possible. A user could explicitly control that they want hybrid via setting them to different values regardless of the defaulting, or wherever hybrid is toggled on different defaulting could be done. I left a few questions on the referenced original issue which, if/when answered, might help me in making a PR to fix this for my usecase more cleanly.
Agreed. I am making a fix to this.
Change:
if err != nil { if apierrors.IsNotFound(err) { _, err := schedClientSet.PriorityClasses().Create(pc) <del> if err != nil { </del> <ins> if err != nil && !apierrors.IsAlreadyExists(err) { </ins> return false, err } else { glog.Infof("created PriorityClass %s with value %v", pc.Name, pc.Value)

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?: What happened: When I start the apiserver, found apiserver crased due to the priority class already exists. 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 ): 1.11.1 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): ubuntu 16.04 Kernel (e.g. ): Install tools: Others:
/sig api-machinery
hi do you happen to have multiple apiservers start at the same time?
yes, I have a HA environment which have 3 apiserver.
sadly, it's the racing then. might launch your servers one-by-one to avoid it for now.
/sig scheduling /priority important-soon
I think is working on PR . As mentioned, following change should be able to fix this:
Yes, and should be picked to release branches once complete
fixed it in as said. Thanks
FWIW, this is a "me too" for a multi-master environment. I've set up a sync-based start-up to prevent multiple API server processes from launching at the same time. Thanks for the fix!
Change:
The `Restart Count:  5` indicates that the `simmemleak` container in this pod was terminated and restarted 5 times. <del> Once [#10861](http://issue.k8s.io/10861) is resolved the reason for the termination of the last container will also be printed in this output. Until then you can call `get pod` with the `-o template -t ...` option to fetch the status of previously terminated containers: </del> <ins> You can call `get pod` with the `-o template -t ...` option to fetch the status of previously terminated containers: </ins> ```console [13:59:01] $ ./cluster/kubectl.sh  get pod -o template -t '{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"rnLastState: "}}{{.lastState}}{{end}}'  simmemleak-60xbc

Discussion:
Problem When a container is killed and restarted because, for example, it hit memory limits, the output only shows an increasing but no reason for why the container was killed: We can find the reason by inspecting the pod object ( shows as with ): Suggested Solution Modify to print termination reason, if available.
When this merges, need to update Search for in that doc.
Solved with .
Change:
}) ginkgo.It("after restart dbus, should be able to gracefully shutdown", func() { <ins> // allows manual restart of dbus to work in Ubuntu. err := overlayDbusConfig() framework.ExpectNoError(err) defer func() { err := restoreDbusConfig() framework.ExpectNoError(err) }() </ins> ginkgo.By("Restart Dbus") <del> err := restartDbus() </del> <ins> err = restartDbus() </ins> framework.ExpectNoError(err) ginkgo.By("Emitting Shutdown signal")

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node /cc
The failure should be caused by
/assign
/triage accepted /assign
Change:
) DEEPCOPY_FILES := $(addsuffix /$(DEEPCOPY_FILENAME), $(DEEPCOPY_DIRS)) <ins> # Shell function for reuse in rules. RUN_GEN_DEEPCOPY =                                                           function run_gen_deepcopy() {                                            if [[ -f $(META_DIR)/$(DEEPCOPY_GEN).todo ]]; then                   ./hack/run-in-gopath.sh $(DEEPCOPY_GEN)                          --v $(KUBE_VERBOSE)                                          --logtostderr                                                -i $$(cat $(META_DIR)/$(DEEPCOPY_GEN).todo | paste -sd, -)   --bounding-dirs $(PRJ_SRC_PATH)                              -O $(DEEPCOPY_BASENAME)                                      "$$@";                                                       fi                                                                   };                                                                       run_gen_deepcopy </ins> # This rule aggregates the set of files to generate and then generates them all # in a single run of the tool. .PHONY: gen_deepcopy <del> gen_deepcopy: $(DEEPCOPY_FILES) if [[ -f $(META_DIR)/$(DEEPCOPY_GEN).todo ]]; then                   ./hack/run-in-gopath.sh $(DEEPCOPY_GEN)                          --v $(KUBE_VERBOSE)                                          --logtostderr                                                -i $$(cat $(META_DIR)/$(DEEPCOPY_GEN).todo | paste -sd, -)   --bounding-dirs $(PRJ_SRC_PATH)                              -O $(DEEPCOPY_BASENAME);                                     fi </del> <ins> gen_deepcopy: $(DEEPCOPY_FILES) $(DEEPCOPY_GEN) $(RUN_GEN_DEEPCOPY) .PHONY: verify_gen_deepcopy verify_gen_deepcopy: $(DEEPCOPY_GEN) $(RUN_GEN_DEEPCOPY) --verify-only </ins> # For each dir in DEEPCOPY_DIRS, this establishes a dependency between the # output file and the input files that should trigger a rebuild.

Discussion:
Right now on head () if you run it will end up having a modified file. This happened because some type has been changed and this file should have been generated before commit, and verification should have failed but they didn't.
This is not only a problem with openapi-gen. deepcopy-gen also has the same problem. I've a field to a type (autoscaling/v1) and verify-all passed for the commit (without adding generated code to it). those files will be generated on verify-codegen and it will not fail and the commit can be merged without generated code.
Yeah. So when the Makefile stuff originally went in those files were not checked in. Then we un-did that part, but I didn't re-add them to verify...
Change:
readOnly: true - name: etcd image: quay.io/coreos/etcd:v2.3.3 <ins> command: - /etcd - --data-dir - /var/etcd/data volumeMounts: - mountPath: /var/etcd name: varetcd </ins> volumes: - name: federation-apiserver-secrets secret: secretName: federation-apiserver-secrets <ins> - name: varetcd persistentVolumeClaim: claimName: {{.FEDERATION_APISERVER_DEPLOYMENT_NAME}}-etcd-claim </ins>

Discussion:
As mentioned in , the federation etcd will lose its state any time the pod dies, unless we modify to add a PVC. We'll also need to create a PV and modify the turnup script to create the backing volume in the cloud provider.
FYI I believe this is a showstopper.
OK. implied I could use to get this provisioned on-demand. AFAICT, , and since it makes our life easier I am trying to get this to work in my test cluster, but so far no joy. Any obvious mistake?
I needed to not specify a .
whew! , Matt Liggett wrote:
Change:
"//staging/src/k8s.io/client-go/informers/core/v1:go_default_library", "//staging/src/k8s.io/client-go/kubernetes:go_default_library", "//staging/src/k8s.io/client-go/rest:go_default_library", <ins> "//staging/src/k8s.io/component-base/metrics/legacyregistry:go_default_library", </ins> "//test/integration/util:go_default_library", <ins> "//vendor/github.com/prometheus/client_model/go:go_default_library", "//vendor/k8s.io/klog:go_default_library", </ins> ], )

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We should allow collecting both default scheduler metrics (Prometheus) and custom metrics easily. At a high level, these collectors should produce a json formatted result which will then be consumed by perf-dash to present in the dashboard. Prometheus metrics We should provide a metrics collector that collects and summarizes default scheduler metrics defined in . To begin with, we can manually pick a list of interesting metrics. Longer term, we could allow configuring the metric list in test definition. already had a PoC . As a reference, is how clusterloader collects scheduler latency metrics. Custom metrics The most important metric is scheduling throughput. is how clusterloader calculates the throughput. We can start with just calculating the average throughput without the percentiles. We may want other custom metrics that are either common to all tests or specific to certain tests. We should allow these custom collectors to be easily and ideally configurable. Why is this needed: Give more insights into scheduler performance. Part of /sig scheduling /assign
/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
Change:
// RecordNodeStatusChange records a event related to a node status change. (Common to lifecycle and ipam) func RecordNodeStatusChange(recorder record.EventRecorder, node *v1.Node, newStatus string) { ref := &v1.ObjectReference{ <del> Kind:      "Node", Name:      node.Name, UID:       node.UID, Namespace: "", </del> <ins> APIVersion: "v1", Kind:       "Node", Name:       node.Name, UID:        node.UID, Namespace:  "", </ins> } klog.V(2).Infof("Recording status change %s event message for node %s", newStatus, node.Name) // TODO: This requires a transaction, either both node status is updated

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'm attempting to use an watcher to better re-act to cluster modifications. I've received the below event: What you expected to happen: I would expect the to include attribute. Not sure if it's all node events or just this particular one. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.16 Cloud provider or hardware configuration: bare metal, rancher's rke OS (e.g: ): centos host nodes Kernel (e.g. ): 3.18, 4.4 Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
Just got another from kubelet..
/remove-sig api-machinery /sig node
recording code is here:
Change:
"k8s.io/kubernetes/cmd/kube-apiserver/app" "k8s.io/kubernetes/cmd/kube-apiserver/app/options" <del> "k8s.io/kubernetes/cmd/kubeadm/app/util/pkiutil" </del> testutil "k8s.io/kubernetes/test/utils" )

Discussion:
found this by running tests on this PR: it's problematic for a couple of reasons: prevents kubeadm from moving out (eventually) there are no API guarantees in the given code/structs/functions in pkiutils the logic in cmd/kube- must be reworked to generate cert/key pair without using kubeadm. originally in pending fix PR
/sig api-machinery cluster-lifecycle architecture /area code-organization
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig api-machinery sig-cluster-lifecycle architecture /area code-organization </details
/assign
cc
Please make sure to add an import restriction to prevent a regression in the future.
/triage accepted