jiebi/CodeConvo huggingface dataset:
Change:
name: "v1.List in order", obj: &corev1.List{ Items: []runtime.RawExtension{ <del> {Raw: encodeOrDie(a)}, {Raw: encodeOrDie(b)}, {Raw: encodeOrDie(c)}, </del> <ins> {Object: a, Raw: encodeOrDie(a)}, {Object: b, Raw: encodeOrDie(b)}, {Object: c, Raw: encodeOrDie(c)}, </ins> }, }, sort: &corev1.List{ Items: []runtime.RawExtension{ <del> {Raw: encodeOrDie(a)}, {Raw: encodeOrDie(b)}, {Raw: encodeOrDie(c)}, </del> <ins> {Object: a, Raw: encodeOrDie(a)}, {Object: b, Raw: encodeOrDie(b)}, {Object: c, Raw: encodeOrDie(c)}, </ins> }, }, field: "{.metadata.name}",

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: seems to have regressed in v1.13.0 and no longer sorts by creation timestamp. What you expected to happen: should sort by creation timestamp. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: N/A Environment: Kubernetes version (use ): <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig cli
/assign
bisected to () /assign
opened to fix
/assign
Change:
return nil, err } <ins> systemUUID, err := getSystemUUID() if err != nil { return nil, err } </ins> return &cadvisorapi.MachineInfo{ NumCores:       runtime.NumCPU(), MemoryCapacity: p.nodeInfo.memoryPhysicalCapacityBytes, MachineID:      hostname, <ins> SystemUUID:     systemUUID, </ins> }, nil }

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: The windows kubelet does not set .status.nodeInfo.systemUUID on the node object. What you expected to happen: The windows kubelet sets the systemUUID from How to reproduce it (as minimally and precisely as possible): Start the windows kubelet and check for UUID: Anything else we need to know?: This will affect users running the out-of-tree vsphere CCM since that depends on the systemUUID, unlike the in-tree version. Also, looks like cAdvisor is the component responsible for providing the systemUUID so let me know if this issue needs to be moved to that repo. Environment: Kubernetes version (use ): Verified on 1.13.1 and 1.14 Cloud provider or hardware configuration: None OS (e.g: ): Windows Server 2019
/sig windows /sig vmware
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
Change:
# To bump the Zeppelin version, bump the version in # zeppelin/Dockerfile and bump this tag and reset to v1. <del> ZEPPELIN_TAG = v0.5.5_v1 </del> <ins> ZEPPELIN_TAG = v0.5.5_v2 </ins> spark: docker build -t gcr.io/google_containers/spark-base base

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:
// Check iptables chain and rules epIpt := netlinktest.ExpectedIptablesChain{ string(kubeServicesChain): {{ <ins> JumpChain: string(KubeMarkMasqChain), MatchSet: kubeClusterIPSet, }, { </ins> JumpChain: string(KubeNodePortChain), MatchSet: "", <ins> }, { JumpChain: "ACCEPT", MatchSet: kubeClusterIPSet, </ins> }}, string(KubeNodePortChain): {{ JumpChain: "RETURN", MatchSet: kubeNodePortLocalSetTCP, }, { JumpChain: string(KubeMarkMasqChain), MatchSet: kubeNodePortSetTCP, <ins> }, { JumpChain: "ACCEPT", MatchSet: kubeHealthCheckNodePortSet, </ins> }}, } checkIptables(t, ipt, epIpt)

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 --ipvs mode didn't preserve client IP for NodePort Service with protocol SCTP and ExternalTrafficPolicy Local. iptables mode works fine. ipvs mode with TCP and UDP protocol works fine. Client IP for NodePort Service should be preseved when ExternalTrafficPolicy is Local regardless of the mode and the protocol. kube-proxy mode to ipvs a NodePort service with protocol SCTP and ExternalTrafficPolicy Local the NodePort service, the client IP was not preserved This is caused by wrong order of iptables rules that match kubeNodePortLocalSetSCTP and kubeNodePortSetSCTP: Kubernetes version (use ): v1.22.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:
/sig network /assign
/triage accepted
Change:
if err := runtime.Convert_runtime_RawExtension_To_runtime_Object(&curr.Extension, &newExtension, s); err != nil { return err } <ins> if *out == nil { *out = make(map[string]runtime.Object) } </ins> if (*out)[curr.Name] == nil { (*out)[curr.Name] = newExtension } else {

Discussion:
What happened: I have a test case: This behaves different with different client-go versions. With , the test passes. This is using in with in With , this test panics. This is using in with in Panic logs: Basically it its creating an object to decode into, and this object has some maps. These are set to nil, so when we try to populate them we get a panic. What you expected to happen: Behavior remains the same as previous release, or at least have some alternative that works here? How to reproduce it (as minimally and precisely as possible): I pasted the test above that reproduces this. This can be reproduced with a project with just that file, and a file with only client-go. Using go 1.13
/sig api-machinery
/assign
Change:
err = WaitForPodSuccessInNamespace(client, injectPod.Name, injectPod.Namespace) Expect(err).NotTo(HaveOccurred()) } <ins> func CreateGCEVolume() (*v1.PersistentVolumeSource, string) { diskName, err := CreatePDWithRetry() ExpectNoError(err) return &v1.PersistentVolumeSource{ GCEPersistentDisk: &v1.GCEPersistentDiskVolumeSource{ PDName:   diskName, FSType:   "ext3", ReadOnly: false, }, }, diskName } </ins>

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --We should have an e2e to test issue . The test needs to delete a PVC while a pod is still using it, and then restart the controller manager. /kind bug /sig storage
CC
/assign unofficially so I can find this later.
Change:
if kl.resolverConfig == "" { hostDNS = []string{"127.0.0.1"} hostSearch = []string{"."} <ins> } else { hostSearch = kl.formDNSSearchForDNSDefault(hostSearch, pod) </ins> } return hostDNS, hostSearch, nil }

Discussion:
Kubernetes version v1.3.0 Kubelet concatenates host and cluster domain entries for my pod, resulting in an invalid config (too many entries with duplicates). The max is only 6 search domains. Any more and DNS resolution breaks when trying to leverage search domains. The example below has only cluster DNS entries, but illustrates the issue: Host search nameserver 10.233.0.2 nameserver 10.90.0.1 options timeout:2 options attempts:2 Container kubectl run -i --tty busybox --image=busybox -- sh (skip waiting text) / # cat search nameserver 10.233.0.2 options attempts:2 options ndots:5 I should be enable cluster DNS config in my host DNS settings and still have functional pod DNS. Kubelet should be intelligent enough to filter out duplicate search domain entries (or drop search domains beyond the 6th entry)
I think some sane checks needs to be too. libc limits search field to 6 records and 255(?) characters. This limitation should be checked before creation.
Hey guys, I'm working on it.
Dup of
Change:
if len(s.Username) == 0 { return fmt.Errorf("username must be specified") } <del> if len(s.Email) == 0 { return fmt.Errorf("email must be specified") } </del> if len(s.Password) == 0 { return fmt.Errorf("password must be specified") }

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: When I create a docker registry secret, the is also a MUST, I think we should make this parameter as optional as there is no need always put when creating a docker registry secret. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know:
Agree it should not be required
Did this change get reverted? I do not see as optional on stable.
I feel that this code should be changed because "--docker-email flag" is no longer required.
error: flag docker-email is required. On kubenetes 1.10.3, the above error message still exists
The field is still required. This is very frustrating as does not require an email but Kubernetes does? Is there a good reason for this?
Why is this closed? As far as I can see it is still required?
Change:
func newCacheWatcher(copier runtime.ObjectCopier, resourceVersion uint64, chanSize int, initEvents []*watchCacheEvent, filter watchFilterFunc, forget func(bool)) *cacheWatcher { watcher := &cacheWatcher{ copier:  copier, <del> input:   make(chan *watchCacheEvent, chanSize), </del> <ins> input:   make(chan watchCacheEvent, chanSize), </ins> result:  make(chan watch.Event, chanSize), done:    make(chan struct{}), filter:  filter,

Discussion:
Our scalability tests started failing on Thu last week: https://k8s- [250 run passed, 251 failed and since then everything failed] I started looking into it and it seems that something happened to how we are handling watches (i.e. I'm seeing a huge number of watches failing with "err too old" errors (which I didn't see before).
As an example in run 258 of kubemark-scale, I'm seeing this log in the test (after 5 minutes of running test); This is extremely strange and unexpected. I looked into apiserver logs, and there is expected number of POST and PUT operations on pods (and no DELETE and PATCH operations until then). Until then, there were alltogethere ~60.000 operations on pods. However, in 5000-node cluster, the size of watchcache of pods is supposed to be 250.000, which means that at that moment we should have all the history from the beginning in watch cache. And still we are observing those errors. Something must have changed around that recently...
As an example, logs from apiserver from a given node: This means something is really wrong: the first watch started at 45, then after it finished, we tried starting watch from rv= and it failed with "rv too old" the list, returned rv= from which we started the next watch. If the watch cache size for pods would be 250.000 (50*cluster size), there there is no way that with current rv=, the rv= would be outside history window...
I had a hypothesis that it might be the problem of breaking watch to etcd. But in that case there should be a warning "Terminating all watchers" log in apiserver, and there is no such log. It also seems that the size of cache is being set correctly...
So I tried running large kubemark locally and it seems that the problem is that the size of cache is too small. I few more logs, and here is what I'm seeing: So it seems that we are correctly initializing cachesizes, but then watch cache capacity is 100 (which explains why we are seeing all those "rv too old" errors. I will try to debug why the capacity is so small.
OK - I found it. contains the fix.
Change:
return true, pod, err } if errs := validation.ValidatePod(newPod); len(errs) > 0 { <del> err = fmt.Errorf("invalid pod: %v", errs) return true, pod, err </del> <ins> return true, pod, fmt.Errorf("invalid pod: %v", errs) </ins> } v1Pod := &v1.Pod{} if err := k8s_api_v1.Convert_api_Pod_To_v1_Pod(newPod, v1Pod, nil); err != nil { <ins> glog.Errorf("Pod %q failed to convert to v1", newPod.Name) </ins> return true, nil, err } return true, v1Pod, nil

Discussion:
To read a pod manifest file from disk (or from the http source), kubelet execute the following code to Decode a on-disk v1 pod manifest to an internal pod object (the defaults are applied in this process). Validate the internal pod. Convert the internal pod back to a v1 pod. The downstream pod cache (which gets v1 pods from different sources) performs similar operations: Convert the v1 pod to an internal pod. Validate the internal pod. One of two conversion/validation should be removed, and some of them should be simplified.
/cc for suggestions on defaulting and conversion.
If no one is working on this, I will take it.
Change:
<del> /var/lib/docker/containers/*/*-json.log { rotate 5 copytruncate missingok notifempty compress maxsize 10M daily create 0644 root root } </del>

Discussion:
We have rotation of logs from docker containers, but not for logs from docker Without rotation, the logs may fill the root partition entirely.
I can add rotation (5 files, 100MB each) if you decide it goes for v1.0 (for me it's a blocker). I'm not sure which platforms are affected. For sure GCE. cc
Sure, send a PR and I'm sure we can merge it.
Change:
return err } <ins> func lookEmitSignalCommand() error { _, err := exec.LookPath("dbus-send") return err } </ins> func getNodeReadyStatus(f *framework.Framework) bool { nodeList, err := f.ClientSet.CoreV1().Nodes().List(context.TODO(), metav1.ListOptions{}) framework.ExpectNoError(err)

Discussion:
Failing on cri-o serial job. Looks like the dbus command isn't available for graceful shutdown tests that aren't running on Ubuntu. /assign /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
/triage accepted /priority important-soon
/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
hmm, is this still issue? The testgrid job is still failing even after the fix appears to be merged? !
Please take a look when you get a chance, the error still seems to be that dbus-send is unavailable... /cc
oops... I forgot to add this to the other
Change:
kindString = strings.ToLower(groupKind.Kind) } <ins> if gracePeriod == 0 { operation = "force deleted" } </ins> if shortOutput { // -o name: prints resource/name fmt.Fprintf(out, "%s/%sn", kindString, info.Name)

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:
AfterEach(func() { cleanupLocalVolume(config, testVol) }) <del> It("should be able to mount volume, write from pod1, and read from pod2 using one-command containers", func() { By("Creating pod1 to write to the PV") writeCmd, readCmd := createWriteAndReadCmds(volumeDir, testFile, testVol.hostDir /*writeTestFileContent*/) writeThenReadCmd := fmt.Sprintf("%s;%s", writeCmd, readCmd) podSpec1 := makeLocalPod(config, testVol, writeThenReadCmd) f.TestContainerOutput("pod writes to PV", podSpec1, 0, []string{testVol.hostDir}) By("Creating pod2 to read from the PV") podSpec2 := makeLocalPod(config, testVol, readCmd) f.TestContainerOutput("pod reads PV", podSpec2, 0, []string{testVol.hostDir}) }) </del> }) LocalVolumeTypes := []LocalVolumeType{DirectoryLocalVolumeType, TmpfsLocalVolumeType}

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /assign What happened: Looks like the event messaging has changed
Change:
if err != nil { klog.ErrorS(err, "Failed to get node ip address matching nodeport cidrs, services with nodeport may not work as intended", "CIDRs", proxier.nodePortAddresses) } <ins> // nodeAddresses may contain dual-stack zero-CIDRs if proxier.nodePortAddresses is empty. // Ensure nodeAddresses only contains the addresses for this proxier's IP family. isIPv6 := proxier.iptables.IsIPv6() for addr := range nodeAddresses { if utilproxy.IsZeroCIDR(addr) && isIPv6 == netutils.IsIPv6CIDRString(addr) { // if any of the addresses is zero cidr of this IP family, non-zero IPs can be excluded. nodeAddresses = sets.NewString(addr) break } } </ins> // Build rules for each service. for svcName, svc := range proxier.serviceMap {

Discussion:
I've been following the official docs for kubeadm and how to set up a new cluster. The cluster is up and running but I noticed warning events when creating node port services: However, the node port does work (I see the output when accessing node ip:nodeport). Might it be related to something else than Kubernetes? There is no such warning event. Set up a fresh cluster with kubeadm and then create a service of nodeport type. No response <details</details<detailsHetzner cloud </details<details</details<detailscloud-init </details<detailscontainerd </details<detailscni=cilium csi=hetzner </details
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
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
check with netstat or ss if there is a process listening on that port
no, I specified exact random port e.g. and checked it before with ss - it was not being used. Then I created the service, the warning occured, and after that the port was taken:
kube-proxy binds the NodePort to warn users that they may be shadowing a process, but it logs the errors if it can not bind the port
I met the same error and I confirmed the node port was not used by any other process. After looking into the code, I think this is a bug in kube-proxy that it would try to open a node port twice with same (empty) IP and port when is empty. contains and in below code.: I have created to fix it.
Awesome find. Did you figure out a work around?

I am encountering this issue with this version of the image:
The error looked scaring but the nodePort should be working, as it was just caused by a duplicate port opening attempt. v1.23.5 and later releases have the fix.
Change:
KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. <del> KUBE_COVER=" " KUBE_RACE=" " "${KUBE_ROOT}/hack/test-go.sh" "" -test.run="^X" -benchtime=1s -bench=. -benchmem </del> <ins> KUBE_COVER="" KUBE_RACE=" " "${KUBE_ROOT}/hack/test-go.sh" -- -test.run="^X" -benchtime=1s -bench=. -benchmem </ins>

Discussion:
Our test- script invokes 'go test' serially for each pkg - currently taking 2 minutes on my laptop. Running a single 'go test' for all pkgs cuts the time down to 45 seconds. Even running with -race is only 1:15. As far as I can tell, the only time we HAVE to run serially is when coverage is on. Does anyone have time to fix this?
I'd created on Friday to fix this, though it's not yet been reviewed.
I cobbled together but I'll review yours since it is probably better :) , Jeff Grafton wrote: