jiebi/CodeConvo huggingface dataset:
Change:
flags := NewEventsFlags(restClientGetter, streams) cmd := &cobra.Command{ <del> Use:                   fmt.Sprintf("events [(-o|--output=)%s] [--for TYPE/NAME] [--watch] [--event=Normal,Warning]", strings.Join(flags.PrintFlags.AllowedFormats(), "|")), </del> <ins> Use:                   fmt.Sprintf("events [(-o|--output=)%s] [--for TYPE/NAME] [--watch] [--types=Normal,Warning]", strings.Join(flags.PrintFlags.AllowedFormats(), "|")), </ins> DisableFlagsInUseLine: true, Short:                 i18n.T("List events"), Long:                  eventsLong,

Discussion:
The seems to be wrong, should be instead of No response <details</details<detailsI am running local Kubernetes cluster using kind. </details<details</details<detailsDocker Desktop for Mac Kind Kubernetes Cluster </details<detailsDocker </details<detailskindnet </details
/sig cli
/triage accepted /priority backlog would you like to fix this mistyping?
Yes Sir! Abid
Hello, can i work on this as my first contribution pls ?
Actually this will be first for me also
please assign yourself and work on it
/assign
/assign
I will assign it to myself once I get home, I am away right now. Thanks
- How unethical it is that you are assigning an issue that you have not pointed out. It is much better that you find a issue and repot it and then assign it. Please go ahead and unassign it, I will assign it and will work on it. CC
/assign
As you opened issue and said that you are planning to work on this, you fully deserve to work on that issue. I'm sorry that I did not check the assignee and approved the PR fixing this. next time, I highly suggest that check if there is assignee or not and only start work on it, only if there is noone.
Oh sorry I thought you said 'please assign yourself and work on it'. I will cancel my PR. I am really sorry.
I was on my phone and i received a mail, so I though it was you who said that ... I cancelled the PR.
Change:
# Kubectl diff # ################ record_command run_kubectl_diff_tests <ins> record_command run_kubectl_diff_same_names </ins> ############### # Kubectl get #

Discussion:
What happened: I get a diff, when I specify a file directly, but on recursive mode, no diff is shown anymore: What you expected to happen: Recursive mode should work How to reproduce it (as minimally and precisely as possible): Have a bunch of YAML manifest, but with name collisions, e.g. Service , Deployment , etc Anything else we need to know?: I think the problem is that all objects have the same name, which should not be a problem per se. Only heapster-binding has a different name, and looking at the generated temp files, only and are present: Environment: Kubernetes version (use ): $ kubectl version --short Client Version: v1.13.0 Server Version: v1.13.0 <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig cli
I think the files are overwriting each other?
Yeah, good catch, I'll try to fix that asap
Thanks! By the way, very nice work with dry-run and diff. I was waiting for this.
Feel free to look at the PR and give your opinion!
Change:
triggerFunc storage.TriggerPublisherFunc) (storage.Interface, factory.DestroyFunc) { s, d := generic.NewRawStorage(storageConfig) <del> if capacity == 0 { </del> <ins> if capacity <= 0 { </ins> klog.V(5).Infof("Storage caching is disabled for %T", objectType) return s, d }

Discussion:
Currently we signal undecorated storage by simply affecting the undecoratedStorage to the decorator. This is a blocker for kubernetes/enhancements as we need to enable watch cache for events (which currently hardcoded and not configurable) cc /assign /sig api-machinery
Change:
Name:  "remove-etcd-member", Short: "Remove a local etcd member.", Long:  "Remove a local etcd member for a control plane node.", <del> Run:   runPreflight, </del> <ins> Run:   runRemoveETCDMemberPhase, </ins> InheritFlags: []string{ options.KubeconfigPath, },

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: Running fails to remove etcd member. What you expected to happen: I expect to remove the node from the etcd cluster. How to reproduce it (as minimally and precisely as possible): From a working 1.15.0 cluster, run on a control plane node. Anything else we need to know?: I think the issues is due to the wrong function being used here: Environment: Kubernetes version (use ): 1.15.0 Cloud provider or hardware configuration: OS (e.g: ): Talos Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /cc
/area kubeadm
/sig cluster-lifecycle
Change:
// New creates a new Kubelet for use in main func NewMainKubelet( <del> hn string, dc dockertools.DockerInterface, ec tools.EtcdClient, rd string, ni string, ri time.Duration, </del> <ins> hostname string, dockerClient dockertools.DockerInterface, etcdClient tools.EtcdClient, rootDirectory string, networkContainerImage string, resyncInterval time.Duration, </ins> pullQPS float32, pullBurst int, minimumGCAge time.Duration, maxContainerCount int, sourcesReady SourcesReadyFn, clusterDomain string, <del> clusterDNS net.IP) *Kubelet { </del> <ins> clusterDNS net.IP) (*Kubelet, error) { if resyncInterval <= 0 { return nil, fmt.Errorf("invalid sync frequency %d", resyncInterval) } if minimumGCAge <= 0 { return nil, fmt.Errorf("invalid minimum GC age %d", minimumGCAge) } </ins> return &Kubelet{ <del> hostname:              hn, dockerClient:          dc, etcdClient:            ec, rootDirectory:         rd, resyncInterval:        ri, networkContainerImage: ni, </del> <ins> hostname:              hostname, dockerClient:          dockerClient, etcdClient:            etcdClient, rootDirectory:         rootDirectory, resyncInterval:        resyncInterval, networkContainerImage: networkContainerImage, </ins> podWorkers:            newPodWorkers(), dockerIDToRef:         map[dockertools.DockerID]*api.ObjectReference{}, <del> runner:                dockertools.NewDockerContainerCommandRunner(dc), </del> <ins> runner:                dockertools.NewDockerContainerCommandRunner(dockerClient), </ins> httpClient:            &http.Client{}, pullQPS:               pullQPS, pullBurst:             pullBurst,

Discussion:
Things like SyncFrequency should have a lower-bound of acceptable, and that really should be 0ns.
The main point of this is now fixed, though we could be better about input checking all over
Change:
// TestRequeueByBindFailure verify Pods failed by bind plugin are // put back to the queue regardless of whether event happens or not. func TestRequeueByBindFailure(t *testing.T) { <ins> fakeBind := &firstFailBindPlugin{} </ins> registry := frameworkruntime.Registry{ <del> "firstFailBindPlugin": newFirstFailBindPlugin, </del> <ins> "firstFailBindPlugin": func(o runtime.Object, fh framework.Handle) (framework.Plugin, error) { binder, err := defaultbinder.New(nil, fh) if err != nil { return nil, err } fakeBind.defaultBinderPlugin = binder.(framework.BindPlugin) return fakeBind, nil }, </ins> } cfg := configtesting.V1ToInternalWithDefaults(t, configv1.KubeSchedulerConfiguration{ Profiles: []configv1.KubeSchedulerProfile{{ SchedulerName: pointer.String(v1.DefaultSchedulerName),

Discussion:
pull-kubernetes-integration: scheduler TestRequeueByBindFailure Running with stress reproduces the flake Not sure, seeing a lot of retests on pull-kubernetes-integration Bind logic in scheduler integration tests just changed 3 days ago in , not sure if that's related No response No response /sig scheduling /priority important-soon cc
I doesn't look related to the latest change you were also looking at Bind. Any ideas?
It's a little strange because the error reports but since the bind-plugin will fail for the first calling time and there's no kubelet, that means the pod status will be kept since. I created another PR to help output the error message, which maybe helpful for analysis.
This test is very straightforward: the first try to bind "pod-1", the Pod is rejected by the binding plugin. () scheduling queue puts back this "pod-1" to activeQ/backoffQ directly, and "pod-1" will soon come back to the scheduling cycle. the second try to bind "pod-1", it's successful. And, means that (1) doesn't reject "pod-1" correctly. And I don't have any idea why it can happen. The only scenario I can think of is that there is somehow another Pod created before pod-1. When is executed , is it possible that any other Pods (like system ones) are created automatically?
/triage accepted current top flake of integration
/assign I've got one possible scenario, will have a quick fix.
Change:
pendingActionSet.Insert( strings.Join([]string{"delete-collection", "daemonsets", ""}, "-"), strings.Join([]string{"delete-collection", "deployments", ""}, "-"), <ins> strings.Join([]string{"delete-collection", "replicasets", ""}, "-"), </ins> strings.Join([]string{"delete-collection", "jobs", ""}, "-"), strings.Join([]string{"delete-collection", "horizontalpodautoscalers", ""}, "-"), strings.Join([]string{"delete-collection", "ingresses", ""}, "-"),

Discussion:
The delete command for a replicaset hangs forever. This then manifests as phantom RSs when I delete and recreate a namespace.
- delete is the gift that keeps on giving
cc
Had you already deleted the corresponding Deployment?
I am still seeing this problem. Deployments and replica sets are sticking.
From what I can tell, calling DELETE_COLLECTION on Deployments is returning: And since the controller assumes not found errors are equivalent to already deleted, it thinks the content is deleted. When I manually inspect, I still see the deployment and replica set laying around... //cc
holding on this while i debug some more...
This was a false alarm, apologies.
Change:
<del> #!/bin/bash # Copyright 2014 The Kubernetes Authors All rights reserved. # # 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. # Deletes pod, deletes secret set -o errexit set -o nounset set -o pipefail ORIGIN=$(dirname "${BASH_SOURCE}") KUBE_ROOT=$(dirname "${BASH_SOURCE}")/../.. ## Delete the services ${KUBE_ROOT}/cluster/kubectl.sh delete services origin-api ${KUBE_ROOT}/cluster/kubectl.sh delete services origin-ui ## Delete the pod ${KUBE_ROOT}/cluster/kubectl.sh delete pods openshift ## Delete the secret ${KUBE_ROOT}/cluster/kubectl.sh delete secrets kubernetes-secret </del>

Discussion:
This PR was prematurely merged: Need to update the PR based on the actual steps that were needed to get what was demonstrated at the public Kubernetes meet-up last week.
Any chance you can get rid of the hostPort from the example?
- depending on the Kubernetes provider, yes. For Vagrant based provider, I think I still need the hostPort because I do not have routes. For the GCE provider, I should be able to get rid of it because I have routes. In both providers, there were a number of setup steps that did not make the merged PR. For those that are tracking this issue (which I know folks have pinged me on separately) needs to be configured to allow privelaged containers needs to be configured to allow pushing to an insecure registry (this is point in time) Ideally, I could use a ReplicationController in the example to load balance OpenShift, but until we can provide a pattern to run etcd as a pod, I am unable to do this and need to use the embedded etcd we end up running.
Note: I will resolve this issue in 2 phases. Vagrant (which was demonstrated) to document using GCE (which has some additional steps on firewall rules)
Turns out OpenShift Origin is too secure now ;-) This is blocked until OpenShift Origin allows you to mint certs on the client, and then supply the certs on startup as a secret to the pod. This feature is coming soon. /cc
I now have all the required pieces to get this to work. I hope to get a PR submitted to fix this issue by end of this week.
Change:
// that associates usage of the specified resource based on the number of items // returned by the specified listing function. type objectCountEvaluator struct { <del> // allowCreateOnUpdate if true will ensure the evaluator tracks create // and update operations. allowCreateOnUpdate bool </del> // GroupResource that this evaluator tracks. // It is used to construct a generic object count quota name groupResource schema.GroupResource

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig api-machinery What happened: The that we use to make a create validation function is given admission.Update as its operation field. In the create validation we then use the provided operation (admission.Update) , when we call the admission controllers, even though a new object is being created. A similar thing is happening with the mutating admission. This means that when an objects is created on update, the admission controllers will see this as an update request. Meaning there could be an objects in storage which never passed create admission validation and were never modified by create admission mutation. I think this is a bug. What you expected to happen: Admission controllers would handle a create-on-update exactly the same as a normal create
I think the solution to this would be to separate the static admission attributes into one for the create validation and one for the update validation. Also, the function which performs the mutating admission needs to determine whether or not it is an actual update or if the old object doesn't exist (probably by checking uid) and then call the mutating admission correctly based on which operation is being performed.
/assign I might be interested to give it a try.
How to reproduce this bug?
Instead of a reproduceable BUG, I think it's like a mismatch of conceptual design and actual implementation. If a resource allows create-on-update in its strategy e.g.: Then admission plugins would receive operations (CREATE/UPDATE) on UPDATE requests. Some problems might happen the admission plugin is written without considering the circumstances that admitting a UPDATE operation might result a object creation into the storage. Risky and confusing, WDYT?
With the current build in admission controllers, I'm not sure if there are any bugs. Maybe something with resource quota? The real problem is that there is no way to know which webhook authors will have a dependency on seeing a "create" operation for every object put into storage. If a webhook relies on creates to implement its custom logic (which should be allowed), then objects created with an update would currently be missed by the webhook.
Change:
func (BasicReplicationController) ParamNames() []GeneratorParam { return []GeneratorParam{ {"labels", false}, <del> {"default-name", true}, {"name", false}, </del> <ins> {"default-name", false}, {"name", true}, </ins> {"replicas", true}, {"image", true}, {"port", false},

Discussion:
I execute:
Appears to be related to changes made in this PR:
Looks like the change here: should have a different set of param names than
Looks like they do have a different set of names, but for the wrong default was set.
Change:
- name: SchedulingMigratedInTreePVs featureGates: <del> CSIMigration: true </del> CSIMigrationAWS: true workloadTemplate: - opcode: createNodes

Discussion:
/sig scheduling in the job is failing. success run Due to this failure, we cannot see any scheduler metrics results from the perf-dash. master
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
/remove-kind bug /kind flake /kind failing-test
/assign /remove-kind flake
will fixed by
Change:
case newer.PodRunning: *out = PodRunning case newer.PodSucceeded: <del> *out = PodTerminated </del> <ins> *out = PodSucceeded </ins> case newer.PodFailed: *out = PodTerminated case newer.PodUnknown:

Discussion:
This happened to me several times while debugging an e2e test. My branch was based on commit and had changes only to
docker inspect says the container exited 0
kubelet HTTP says the pod exited 0:
kubectl says it failed:
Events does not show any success or failure even. Seems like it doesn't show that for any pods, succeeded or failed.
Apiserver sees the exit code 0:
The problem might be related to there being zero values for startedAt or finishedAt. The command may have exited so quickly that docker could not record these values, and we may be somehow treating unset values for these as failure.
adding sleep 5 to my command causes docker to set the startedAt and finishedAt to reasonable values, but the pod still shows up as failed. Note that I use a different pod name each time I try to avoid that sort of obvious mistake.
So, the apiserver v1beta1 message knows that it is terminated with exit code 0. But, both kubectl and my go code in my go e2e test thing this means failed. I'm starting to suspect the conversion code.
The problem is that a v1beta1 pod can never see that a pod is failed or succeded. So it defaults to PodFailed. Grrrrrrraaaaahhhhhh!
In line 184 of
This is going to be confusing for people unless we change this.
I believe the latest fix for PodStatus should resolve the issue here. I will double confirm it before closing it.

We should do this after 1.7. xref /sig testing cc
Is this the task that needs completed - Add support to Ubuntu e2e test-infra
That is different, this is about running GPU tests as part of PR pre-submit tests. Right now we skip them because they are "[Serial]".
I can work on this issue in conjunction with . Is this issue just a matter of adding GPU tests to a different suite or are there more subtasks?
Anymore progress on this?
Thanks for the reminder. I just submitted an internal request for quota to run these tests. Once that is approved, I will add a PR in test-infra to run GPU tests on all k/k PRs. It will be non-blocking initially and then become blocking later on.
Awesome, thanks!
Change:
all: push push: push-spark push-zeppelin <del> .PHONY: push push-spark push-zeppelin spark zeppelin </del> <ins> .PHONY: push push-spark push-zeppelin spark zeppelin zeppelin-build </ins> # To bump the Spark version, bump the version in base/Dockerfile, bump # the version in zeppelin/Dockerfile, bump this tag and reset to

Discussion:
The image by is over a gig. Investigate how to trim this down. (Cut out interpretters? Make them more modular somehow, possibly composing them once we have some solution like ?) It's not even clear there's upstream support for making this more modular, though.
cc
remove mvn tooling and all the extra steps, once upstream releases 's like the rest of apache.
I can look at that, but I think I can actually just strip the image of the dev tooling right now. Right now I think the Zeppelin deps themselves are a ridiculous portion of this, though. (I'll poke at it.)
(3) is an install of [bzr git mercurial openssh-client subversion] in the base java image, which seems wasteful to me. you'll have to switch base images to get rid of this. (2) is your install of [curl net-tools build-essential git wget unzip python python-setuptools python-dev python-numpy libfontconfig]. i expect curl is at least redundant, as is git if your using the java image. you should merge this layer w/ (1) and do an uninstall of [python-setuptools python-dev etc] & deps at the end. of course, those are less significant than (1), which is the mvn build. the long term solution here is to use the upstream binaries, when they exist. in the meantime, you should clone zeppelin into tmp, copy out the resulting build artifact and delete the clone. that should at least cut the size of this layer in half, as all the intermediate build artifacts are likely still present and in the final tarball/jar.
I can trim it down some by cutting out the build machinery (and I'll put up a PR shortly), but here's what the looks like: And expanded: (Instead of just deleting, it's actually easy to build, copy out, compose, too.)
Is it me or are all the containers rather large. For example, does spark itself need to be a gig? 1.5.1v3 6 weeks ago 989.7 MB There's some spark binary package that's 73M uncompressed:
Java runtime + baseimage + transitive closer is what is causing most of the bloat. But as we have discussed on other tickets, these images need to move out of the main repository.

I'm afraid I don't understand "transitive closer". For example I see my JDK is around 280M, and the Spark binary is 73M. Then that leaves another 636M for base + whatever. I guess I'll have to look at the imagelayers if I'm really curious.
he means all the dependencies and their dependencies. if you'd like to tackle shrinking the spark image, please open an issue for it. we've done some work on this and you can use the example investigation above to help improve image sizes.
Change:
cadvisorInterface := &cadvisortest.Fake{ NodeName: config.NodeName, } <del> containerManager := cm.NewStubContainerManager() </del> <ins> var containerManager cm.ContainerManager if config.ExtendedResources != nil { extendedResources := v1.ResourceList{} for k, v := range config.ExtendedResources { extendedResources[v1.ResourceName(k)] = resource.MustParse(v) } containerManager = cm.NewStubContainerManagerWithDevicePluginResource(extendedResources) } else { containerManager = cm.NewStubContainerManager() } </ins> endpoint, err := fakeremote.GenerateEndpoint() if err != nil {

Discussion:
A kubernetes cluster is normally constructed from a variety of machine templates. Different instance groups may have different CPU, memory capacity. They may be equipped with specialized accelerators, network devices. I think we should have an extensible way for users to custom node configuration to simulate real production cluster states. Currently, nodelabel and nodetaints are supported. I am consider to accept a template with more configuration like resources so we won't grow option list in the future. Without this feature, it's hard for users to simulate heterogeneous cluster.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/sig scalability
Change:
return strings.HasPrefix(media, "text/") } <ins> // checkWait returns true along with a number of seconds if the server instructed us to wait // before retrying. func checkWait(resp *http.Response) (int, bool) { if resp.StatusCode != errors.StatusTooManyRequests { return 0, false } i, ok := retryAfterSeconds(resp) return i, ok } </ins> // retryAfterSeconds returns the value of the Retry-After header and true, or 0 and false if // the header was missing or not a valid number. func retryAfterSeconds(resp *http.Response) (int, bool) {

Discussion:
Storing r.req / r.resp internally (for use from DoRaw and Do) is probably not the right factoring. There should be a common method doRaw that returns request and body.