jiebi/CodeConvo huggingface dataset:
Change:
return nil } <del> func cascadingDeleteResource(info *resource.Info, out io.Writer, shortOutput bool) error { </del> <ins> func cascadingDeleteResource(info *resource.Info, out io.Writer, shortOutput bool, gracePeriod int) error { </ins> falseVar := false deleteOptions := &metav1.DeleteOptions{OrphanDependents: &falseVar} <del> return deleteResource(info, out, shortOutput, deleteOptions) </del> <ins> return deleteResource(info, out, shortOutput, deleteOptions, gracePeriod) </ins> } <del> func deleteResource(info *resource.Info, out io.Writer, shortOutput bool, deleteOptions *metav1.DeleteOptions) error { </del> <ins> func deleteResource(info *resource.Info, out io.Writer, shortOutput bool, deleteOptions *metav1.DeleteOptions, gracePeriod int) error { </ins> if err := resource.NewHelper(info.Client, info.Mapping).DeleteWithOptions(info.Namespace, info.Name, deleteOptions); err != nil { return cmdutil.AddSourceToErr("deleting", info.Source, err) } <del> printDeletion(info, out, shortOutput) </del> <ins> printDeletion(info, out, shortOutput, gracePeriod) </ins> return nil } // deletion printing is special because they don't have an object to print.  This logic mirrors PrintSuccess <del> func printDeletion(info *resource.Info, out io.Writer, shortOutput bool) { </del> <ins> func printDeletion(info *resource.Info, out io.Writer, shortOutput bool, gracePeriod int) { </ins> operation := "deleted" groupKind := info.Mapping.GroupVersionKind kindString := fmt.Sprintf("%s.%s", strings.ToLower(groupKind.Kind), groupKind.Group)

Discussion:
IMO it's surprising that does not force delete a resource. only takes effect when . The description of reads this: We should make it more clear what does and even print warnings when is specified without .
Changing the meaning of force to actually break cluster consistency be default could lead to data loss, which is why we haven’t changed it so far. agree we should print more info and clarfiy
Change:
done set -- "${testcases[@]+${testcases[@]}}" <ins> # TODO: this should probably be refactored to avoid code duplication with the # coverage version. </ins> if [[ $iterations -gt 1 ]]; then if [[ $# -eq 0 ]]; then set -- $(kube::test::find_dirs)

Discussion:
Right now, we execute unit tests in Travis with , and you can see the results on each line: but we don't have an easy place to go browse our code and figure out what's covered and what isn't. Is there some awesome way to do this? At the very least, can we get the actual line-by-line coverage results integrated into our CI build process so we can poke at these somehow?
cc
I'm willing to take a look into this to at least see if something is possible.
Looking into using Coveralls; there are a few other teams at Google already using this. Integration with Travis and Go are supported with the goveralls package:
Unit test coverage can now be viewed at - both master push builds and PRs will be shown there; additionally, Coveralls will update the status and post comments on PRs with coverage stats. (If we find these too spammy, we can disable either or both.) The top-level also has a badge/link to the coverage dashbaord.
Change:
"k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" <ins> "k8s.io/apimachinery/pkg/runtime/schema" </ins> "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/intstr" "k8s.io/apimachinery/pkg/util/wait"

Discussion:
Which jobs are failing: ci-kubernetes-e2e-gce-new-master-upgrade-master-parallel Which test(s) are failing: [sig-apps] Deployment deployment should support rollback Since when has it been failing: 06-22 - 17:13 PDT Testgrid link: Reason for failure: Anything else we need to know: /priority critical-urgent /kind failing-test /sig apps
I will look in test together with
/milestone v1.16
stopped serving those APIs in 1.16. The test in the release-1.15 branch should skip if the server it is testing against does not serve the deprecated extensions/v1beta1 API
closing
and did not completely resolve the failing tests here or in /reopen
Reopened this issue. <detailsIn response to : and did not completely resolve the failing tests here or in /reopen </details
this job is running 1.14-level tests against master (1.16). the test should be updated to run 1.15 against master
Possible issue here is that we may have misconfigured upgrade/downgrade jobs (upgrading/downgrading to incorrect k8s versions). For full discussion see
/assign
Ultimately, the issue with this and was the the Kubernetes release markers did not point to the releases we expected. This was fixed during the recent 1.16 alpha release. /close
Closing this issue. <detailsIn response to : Ultimately, the issue with this and was the the Kubernetes release markers did not point to the releases we expected. This was fixed during the recent 1.16 alpha release. /close 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:
normalizeTimeStamp(&condition.LastTransitionTime) } <del> // update container statuses for i := range status.ContainerStatuses { cstatus := &status.ContainerStatuses[i] normalizeContainerState(&cstatus.State) normalizeContainerState(&cstatus.LastTerminationState) </del> <ins> normalizeContainerStatuses := func(containerStatuses []v1.ContainerStatus) { for i := range containerStatuses { cstatus := &containerStatuses[i] normalizeContainerState(&cstatus.State) normalizeContainerState(&cstatus.LastTerminationState) } </ins> } <del> // Sort the container statuses, so that the order won't affect the result of comparison </del> <ins> normalizeContainerStatuses(status.ContainerStatuses) </ins> sort.Sort(kubetypes.SortedContainerStatuses(status.ContainerStatuses)) <del> // update init container statuses for i := range status.InitContainerStatuses { cstatus := &status.InitContainerStatuses[i] normalizeContainerState(&cstatus.State) normalizeContainerState(&cstatus.LastTerminationState) } // Sort the container statuses, so that the order won't affect the result of comparison </del> <ins> normalizeContainerStatuses(status.InitContainerStatuses) </ins> kubetypes.SortInitContainerStatuses(pod, status.InitContainerStatuses) <ins> normalizeContainerStatuses(status.EphemeralContainerStatuses) sort.Sort(kubetypes.SortedContainerStatuses(status.EphemeralContainerStatuses)) </ins> return status }

Discussion:
is not normalized in in the status manager: This does not seem to cause any user facing problem because is sorted before passed to the status manager and timestamps are normalized at marshaling to create a patch: However, an unexpected behavior is caused internally because timestamps are not normalized. If the log verbosity is 3 or larger, the following messages are logged periodically in kubelet when an ephemeral container exists: This message is emitted here: After returns , is called. This does not look so harmful because gets eventually: API is called once unnecessarily in , though: It might be better to normalize ephemeral container statuses, at least timestamps, in the status manager to avoid this unexpected behavior. Set the log verbosity of kubelet to 3 or larger. Then, create an ephemeral container like . No response <details</details<detailsNone </details<details</details<details</details<details</details<details</details
/sig node
This is a bug. Can you submit a PR to fix it? If not, I'd be happy to work on it
If you are interested, please feel free to assign yourself.
thx
/assign
/triage accepted /priority important-longterm
Change:
return false, nil } <del> completionMode := string(batch.NonIndexedCompletion) if isIndexedJob(&job) { completionMode = string(batch.IndexedCompletion) } </del> <ins> completionMode := getCompletionMode(&job) </ins> action := metrics.JobSyncActionReconciling defer func() {

Discussion:
Occasionally job completions are counted twice (or potentially multiple times?) in the metric. This happens for about 20% of jobs, but may depend on the Job specificity, which results in an overestimation of the number of finished jobs. The metric reflects the actual number of completed jobs. a kind cluster with prometheus monitoring stack (for example follow this: ). the number of completed jobs by inspecting the metric and delete a job multiple times in a loop Example job: Example repro script: . Check the number of completed jobs by inspecting the metric and the job Yes, in the kube-controller-logs we find the following log lines which are related and probably indicate repeated updated which results in double counting. <details</details<detailsReproducible with kind </details<details</details<details</details<details</details<details</details
/assign
FYI
/sig apps
/triage accepted
Change:
select { case event := <-eventChan: return event == expected <del> case <-time.After(2 * time.Second): </del> <ins> case <-time.After(wait.ForeverTestTimeout): </ins> t.Fatalf("Timed out while waiting for registration status %v", expected) }

Discussion:
What happened: A race condition in the plugin watcher might happen when a is created, started and immediately stopped and cleaned up. If executed several times, the unit test will expose this issue. The PR addressed part of the problem by serializing the handling of CREATE and DELETE events. However, a race might still happen in the function. describes in detail the problem. How to reproduce it (as minimally and precisely as possible): /sig storage /sig node
/assign
Change:
func getObjectKind(object interface{}) (schema.GroupVersionKind, []error) { var listErrors []error <del> fields := object.(map[string]interface{}) if fields == nil { </del> <ins> fields, ok := object.(map[string]interface{}) if !ok || fields == nil { </ins> listErrors = append(listErrors, errors.New("invalid object to validate")) return schema.GroupVersionKind{}, listErrors }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig cli What happened: I accidentally tried to apply an invalid v1.List with : kubectl responded by crashing with a panic: What you expected to happen: An error message to be printed, perhaps of the "invalid List item: []". How to reproduce it (as minimally and precisely as possible): See description. Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: GCE OS (e.g. from /etc/os-release): CentOS 7.4 (1708) Kernel (e.g. ): Linux staging-head-2 3.10.0-693.2.2.el7.x8664 SMP Tue Sep 12 22:26:13 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Custom scripts Others:
I would try to fix it.
Can you add --validate=true in command line, then have a try?
cc
Change:
} // Start resourceMonitor only in small clusters. <del> if len(nodes.Items) <= maxNodesToCheck { </del> <ins> if numNodes <= maxNodesToCheck { </ins> resourceMonitor = e2ekubelet.NewResourceMonitor(f.ClientSet, e2ekubelet.TargetContainers(), containerStatsPollingInterval) resourceMonitor.Start() }

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: https://k8s- Which test(s) are failing: [] [sig-node] kubelet [] [sig-node] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. Since when has it been failing: 2019-09-26 Testgrid link: Reason for failure: Anything else we need to know: /cc
is there someone who can pick this up since it's constantly failing in the master-informing? Thanks :)
Could you help us here?
Looked into the test logs, and it seems like the in was accidentally removed in , which caused its value to be 0. As the current log is showing: And last succeeded test log is: I'll send a PR to fix this. /cc
It seems that this PR didn't help. This run already contains this PR and it failed:
/milestone v1.17 /priority critical-urgent
I0926 12:39:42.660] I0926 12:35:26. ] Trace[]: "Reflector ListAndWatch" (started: 2019-09-26 12:33:26. +0000 UTC m=+1132.) (total time: 2m0.000301191s):
Seems like the test is timing out creating the pods and reflector to watch those pods.
Looks like the section of code taking a long time is
Checked KAS log and seeing about 7000 requests of the form I1010 12:26:59. 1 ] GET /api/v1/nodes/gce-scale-cluster-minion-group-1-4p2m:/proxy/stats/summary: (9.753712ms) 200 [ (linux/amd64) kubernetes/ -- [] [sig-node] kubelet [] [sig-node] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. 146.148.73.158:] between replicationcontroller being created and the pod list/watch request.
The is only supposed to run if there are less than 10 nodes in the cluster. However, the situation doesn't hold with this change: (or ) was changed to .

While the e2e test only uses 10 () nodes from the cluster, the resource monitor is querying all the nodes in the cluster. Thus the client qps limit was exceeded and caused the reflector to be throttled. I'll send a fix
/assign
Change:
if disk.Lun != nil && (disk.Name != nil && diskName != "" && strings.EqualFold(*disk.Name, diskName)) || (disk.Vhd != nil && disk.Vhd.URI != nil && diskURI != "" && strings.EqualFold(*disk.Vhd.URI, diskURI)) || (disk.ManagedDisk != nil && strings.EqualFold(*disk.ManagedDisk.ID, diskURI)) { <del> // found the disk klog.V(2).Infof("azureDisk - find disk: lun %d name %q uri %q", *disk.Lun, diskName, diskURI) return *disk.Lun, nil </del> <ins> if disk.ToBeDetached != nil && *disk.ToBeDetached { klog.Warningf("azureDisk - find disk(ToBeDetached): lun %d name %q uri %q", *disk.Lun, diskName, diskURI) } else { // found the disk klog.V(2).Infof("azureDisk - find disk: lun %d name %q uri %q", *disk.Lun, diskName, diskURI) return *disk.Lun, nil } </ins> } } return -1, fmt.Errorf("cannot find Lun for disk %s", diskName)

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: We found that cloud provider tries to attach a disk, it totally costs 121s in the end one minute(disk still in being detaching state), azure cloud provider tries to delete that disk and it succeeded 121s, attach disk operation succeeded and finally azure vm has attached one non-existing disk What you expected to happen: should not delete an azure disk when that disk is being attached How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: The difficulty here is when a disk is being attached or detached, the disk state is still "unattached", would be the reason why delete disk at that time would succeed: Azure disk RP would have two options to fix this issue: a new disk state: , disk delete operation when disk is being attached or detached Otherwise on azure provider(client) side, we cannot know whether that disk is being attached or detached since the second delete disk operation is done after 1 min 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: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure
Change:
func (util *GCEDiskUtil) DetachDisk(pd *gcePersistentDisk) error { // Unmount the global PD mount, which should be the only one. globalPDPath := makeGlobalPDName(pd.plugin.host, pd.pdName) <ins> glog.V(5).Infof("DetachDisk(pd) where pd is %#v and the globalPDPath is %qrn", pd, globalPDPath) // Terminate any in progress verify detach go routines, this will block until the goroutine is ready to exit because the channel is unbuffered detachCleanupManager.Send(pd.pdName, true) </ins> if err := pd.mounter.Unmount(globalPDPath); err != nil { return err }

Discussion:
The "" E2E test will sometimes fail because it fails to delete the PD used in the test after the test is finished. The error: Detailed test log: The disk that fails to delete still shows up in : My attempts to manually try to delete the PD fail with: (the work around for ) doesn't change anything here:
is the disk still mounted ? It looks like the detach call did not succeed for some reason
I'll have to get another repro and verify.
okay cool. If you get a repro check to see if the disk is still mounted. If so then the cleanup code is not being called. If not then the clean up started, detach was called but failed for some reason; look in the logs for something like "googleapi: some error about detaching". It can also just be a race condition. That is, detach was called but is taking too long; if the disk does not detach then you cannot delete it.
Change:
"k8s.io/api/core/v1" rbacv1beta1 "k8s.io/api/rbac/v1beta1" storagev1 "k8s.io/api/storage/v1" <ins> "k8s.io/apimachinery/pkg/api/errors" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/apimachinery/pkg/util/sets"

Discussion:
Failing on gke only: https://k8s- https://k8s-
/assign
Unfortunately the exact error message that its failing with is lost due to a typo: I have fixed that typo locally and am running the tests repeatedly to try to reproduce the flake. have been unable to reproduce the flake on HEAD of Kubernetes in GKE in 15 runs so far. Running 150 tests overnight.
Unable to repro on my own GKE cluster. Merged the error message fix, will monitor for the next flake to debug more
Change:
"os" "time" <del> kube_client "github.com/GoogleCloudPlatform/kubernetes/pkg/client" </del> <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/client" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/registry" "github.com/GoogleCloudPlatform/kubernetes/pkg/util" "github.com/coreos/go-etcd/etcd"

Discussion:
It would be great to have an easy way to run a kubernetes master/minion locally. Currently, it's not that easy to set up. We should have a convenient script to make it work.
The integration test binary is pretty close. It'd be pretty simple to glue in the kubelet to that binary. Brendan On Jun 10, 2014 2:53 PM, "Daniel Smith" wrote:
I'll take a look.
+1 for this -- especially in script form rather than a go executable.
what exactly do you mean by "script form"? Were you thinking of something like a version of cloudcfg that can be run without needing to have started up a daemon first?
Basically, what I had in mind, is a shell script that looks something like
Ah, ok. That's very similar to local-; the only difference is that everything is packaged into a single go binary. We probably will switch to using individual binaries for this when we start running our components inside docker containers.
The script just makes things more obvious how to run things for those who are looking to integrate them into non-GCE environments.
That's a good point. I'll look into this some more later.
Create a pad as follows: Name: non-persistent-redis Container image: redis Named-volum with name: cache-control Mount path: /data/redis It should launch in the pre-prod namespace and the volume MUST NOT be persistent. apiVersion: v1 kind: Pod metadata: name: non-persistent-redis namespace: pre-prod spec: containers: name: non-persistent-redis image: redis volumeMounts: name: cache-control mountPath: "/data/redis" volumes: name: cache-control emptyDir: {}

I cannot find such a service when . Same thing applies for . My cluster runs fine. cc:
Ah, good catch... everything is run as a container now, will update the documentation on where to get the logs.

When I'm accessing persistentVolumes and persistentVolumeClaims, I'm getting nil instead of empty list of items, as happening in other entities when there are no items. { "kind": "PersistentVolumeList", "apiVersion": "v1", "metadata": { "selfLink": "/api/v1/persistentvolumes", "resourceVersion": "" } }
Yes, this seems like a bug. I see an empty list when I access pods: And items is nil when I access persistent volumes:
Items shouldn't be tagged with omitempty:
cc
PersistentVolumeList and PersistentVolumeClaimList appear to be the only resource types with this problem.
Please see for fix.
Change:
# TODO: split this out into args when we no longer need to pipe stdout to a file #6428 - sh - -c <del> - '/glbc --verbose=true --default-backend-service=kube-system/default-http-backend --sync-period=600s --running-in-cluster=false --use-real-cloud=true --config-file-path=/etc/gce.conf --healthz-port=8086 1>>/var/log/glbc.log 2>&1' </del> <ins> - '/glbc --verbose=true --apiserver-host=http://localhost:8080 --default-backend-service=kube-system/default-http-backend --sync-period=600s --running-in-cluster=false --use-real-cloud=true --config-file-path=/etc/gce.conf --healthz-port=8086 1>>/var/log/glbc.log 2>&1' </ins> volumes: - hostPath: path: /etc/gce.conf

Discussion:
This leads to the following errors when running the example Guest Book application: If the proxy and the endpoint are on the same machine then the proxy works because everything defaults to 127.0.0.1 Successful proxy logs
I have this problem too. I think this has something to do with not having pod_registry/fillPodInfo called on the pods, but I'm not sure how to get the code where it needs to be.
I have repro-d this, I should be able to close it down soon. Sorry! --brendan , Ryan Fowler wrote:
please see for the fix. Sorry for the issue!
This issue is resolved. Closing.
Change:
panic(err) } <ins> mismatchErrorMessage := "ERROR: %v indicates that %v should be at version %v, but the following files didn't match:nn" + "%vnnif you are changing the version of %v, make sure all of the following files are updated with the newest version including %vn" + "then run ./hack/verify-external-dependencies-version.shnn" </ins> externalDeps := &dependencies{} <ins> var pathsToUpdate []string </ins> err = yaml.Unmarshal(externalDepsFile, externalDeps) if err != nil { panic(err)

Discussion:
What would you like to be : The current error message is vague and could be improved. (credit to Why is this needed: Improve contributor experience, make it easier to identify change to be fixed. /cc
/assign
Change:
"    VolumeHandle:t%vn"+ "    ReadOnly:t%vn", csi.Driver, csi.VolumeHandle, csi.ReadOnly) <ins> printCSIPersistentVolumeAttributesMultiline(w, "VolumeAttributes", csi.VolumeAttributes) } func printCSIPersistentVolumeAttributesMultiline(w PrefixWriter, title string, annotations map[string]string) { printCSIPersistentVolumeAttributesMultilineIndent(w, "", title, "t", annotations, sets.NewString()) } func printCSIPersistentVolumeAttributesMultilineIndent(w PrefixWriter, initialIndent, title, innerIndent string, attributes map[string]string, skip sets.String) { w.Write(LEVEL_2, "%s%s:%s", initialIndent, title, innerIndent) if len(attributes) == 0 { w.WriteLine("<none>") return } // to print labels in the sorted order keys := make([]string, 0, len(attributes)) for key := range attributes { if skip.Has(key) { continue } keys = append(keys, key) } if len(attributes) == 0 { w.WriteLine("<none>") return } sort.Strings(keys) for i, key := range keys { if i != 0 { w.Write(LEVEL_2, initialIndent) w.Write(LEVEL_2, innerIndent) } line := fmt.Sprintf("%s=%s", key, attributes[key]) if len(line) > maxAnnotationLen { w.Write(LEVEL_2, "%s...n", line[:maxAnnotationLen]) } else { w.Write(LEVEL_2, "%sn", line) } i++ } </ins> } type PersistentVolumeDescriber struct {

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: kubectl describe pv doesn't show the volume attributes
If there was no one working on this, I can help do it.
/assign
/remove-help
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : New functionality. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details