jiebi/CodeConvo huggingface dataset:
Code change:
<ins> .generated_docs admin/ man/ user-guide/ yaml/ </ins>

Related discussion:
text: Instead, have a presubmit test that verifies that the docs can be generated. This will reduce the number of conflicts & rebases, therefore increase speed through the queue. Confirmed with that nothing depends on these docs at the moment. fyi, some manual process might have to change once this is in.
Yes, we want to generate the docs into , anyway. cc
Excellent. One closer step to YAML generation, I hope. :)
was interested in working on this.
Want to get started on this?
is this still a goal of ours?
I've seen a thread this week-end about that. I think docs have moved but we still need to generate them there.
can this issue be closed then?
related to ?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /lifecycle frozen There's still cruft in the docs directory.
/remove-help I don't think this meets . Please add back via if I'm incorrect
/sig docs /sig release /remove-area test-infra /area build-release /area kubeadm /area kubectl All of the following dirs/files have the following content. Do we need them? This file is autogenerated, but we've stopped checking such files into the repository to reduce the need for rebases. Please run hack/generate- to populate this file. docs/admin: .md files for kube components and kubeadm commands man/man1: .1 files for same user-guide/kubectl: .md files for kubectl commands yaml/kubectl: .yaml files for kubectl commands
/help Now that we have /good-first-issue, I think this does meet the criteria for help wanted. Probably need to talk to someone from sig-docs and figure out if/how these are used.
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command.
Code change:
<ins> .generated_docs admin/ man/ user-guide/ yaml/ </ins>

Related discussion:
text: <detailsIn response to : /help Now that we have /good-first-issue, I think this does meet the criteria for help wanted. Probably need to talk to someone from sig-docs and figure out if/how these are used. 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
/remove-priority important-soon /priority important-longterm This hasn't been committed to for any release cycle in a while. I hope someone does commit to it, but I personally cannot, so I'm bumping down to the "hopefully next time" priority. /kind cleanup in addition to docs This impacts merge velocity of any kubectl/kubeadm changes because the docs/OWNERS file is small. We're going to work around by adding OWNERS files for the relevant sigs to the relevant dirs. But if these files don't have to exist in the first place, that'd be even better.
as discovered today this would not work as OWNERS in sub-folders do not solve the problem with the /docs/.generated_docs file which is in the parent folder. i've been looking into a solution to remove the placeholders completely and make verify-docs only consist of kube::util::gen-docs. this will: ensure that godoc errors and such still block presubmits the contributors are not blocked having to commit placeholder files
/lifecycle active
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 /lifecycle active as PR is still in flight.
Code change:
} } <del> var insecurePort = 8081 </del> <ins> var insecurePort = 8082 </ins> var serverIP = fmt.Sprintf("http://localhost:%v", insecurePort) var groupVersion = fed_v1a1.SchemeGroupVersion

Related discussion:
text: Not much info on why or how it failed. cc
Cc On Apr 28, 2016 5:08 PM, "Mike Danese" wrote:
cc
cant open the link, would you mind paste the content?
can you access http://ci- ?
It failed due to bind address already in use. The same address were used in example/apiserver (which runs befor federated-apiserver) as well. I wonder if the tests are run in parallel? If it is the case, I can change the port to other values (8082 for example) Otherwise, it may indicate that the address:port was not proper released for some reason
Yes, tests run in parallel. Can you perhaps use a random port number each time? This will reduce the probability of collision to nearly zero (close enough to zero for practical purposes). See . also provides other background reading, but is focussed on end-to-end tests. Much of the discussion applies to unit tests also though.
I think changing the Insecure Port at from 8081 to some other value (say, 8082) should be fine.
Which should I use? 8082 or random? Personally I wouldn't be so optimistic about using random port number since no matter how small the probability is, it will happen eventually, which would be a surprise to those who's not aware of this.
Yes I am fine with changing the port to 8082. Feel free to send me the PR for review.
If you specify port 0 when you bind, the kernel will hand you an available port so there won't be a conflict.
We also want to know the port to be able to curl it in the test.
Code change:
return nil, err } <ins> for i := range table.Rows { row := &table.Rows[i] if row.Object.Raw == nil || row.Object.Object != nil { //if row already has Object.Object //we don't change it continue } converted, err := runtime.Decode(unstructured.UnstructuredJSONScheme, row.Object.Raw) if err != nil { //if error happens, we just continue continue } row.Object.Object = converted } </ins> return table, nil }

Related discussion:
text: <!-- 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: namespace disappears in the output of What you expected to happen: namespace exists How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: It is related to Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cli
Code change:
// Get returns the election record from a ConfigMap Annotation func (cml *configMapLock) Get(ctx context.Context) (*LeaderElectionRecord, []byte, error) { var record LeaderElectionRecord <del> var err error cml.cm, err = cml.Client.ConfigMaps(cml.ConfigMapMeta.Namespace).Get(ctx, cml.ConfigMapMeta.Name, metav1.GetOptions{}) </del> <ins> cm, err := cml.Client.ConfigMaps(cml.ConfigMapMeta.Namespace).Get(ctx, cml.ConfigMapMeta.Name, metav1.GetOptions{}) </ins> if err != nil { return nil, nil, err } <ins> cml.cm = cm </ins> if cml.cm.Annotations == nil { cml.cm.Annotations = make(map[string]string) }

Related discussion:
text: The lock acquired by tryAcquireOrRenew is released when the leader ends leadership. However, due to the cancellation of the context, the lock may be set as an empty lock, so the Update cannot be run normally, resulting in a failure to release the lock. The lock can be released every time the leader ends. run this: and then you can got a log like these: and you when you watch the leases at the same time: you can see that was failed to release because of No response <details</details<details</details<details</details<details</details<details</detailsrelated packages: v1.3.0 v0.25.0 v0.25.0 v2.70.1
/sig api-machinery
/triage accepted thanks!
/unassign
/assign
/unassign
/unassign me
Code change:
# Remove any existing mounts for block_device in ${block_devices}; do echo "Unmounting ${block_device}" <del> /bin/umount ${block_device} </del> <ins> /bin/umount ${block_device} || echo "Ignoring failure umounting ${block_device}" </ins> sed -i -e "|^${block_device}|d" /etc/fstab done <ins> # Remove any existing /mnt/ephemeral entry in /etc/fstab sed -i -e "|/mnt/ephemeral|d" /etc/fstab # Mount the storage </ins> if [[ ${docker_storage} == "btrfs" ]]; then apt-get-install btrfs-tools

Related discussion:
text: On AWS we (will) now run our bootstrap script on every boot. The function to initialize ephemeral volumes doesn't tolerate being re-run, and we probably shouldn't re-run it anyway for speed. This does preserve the contents, which may be a good thing to save user's data (it doesn't belong on ephemeral drives, but...). On the other hand, if the ephemeral drives are corrupted, we lose the opportunity to reformat them and recover. Arguably, if the ephemeral storage is corrupted the right thing to do is to terminate the instance entirely.
Code change:
Expect(err).NotTo(HaveOccurred()) sst.BreakProbe(ss, testProbe) <ins> sst.WaitForStatus(ss, 0) </ins> sst.WaitForRunningAndNotReady(3, ss) sst.UpdateReplicas(ss, 0) sst.ConfirmStatefulPodCount(3, ss, 10*time.Second)

Related discussion:
text: https://k8s- do you know the statefulset owners?
cc
I did not see this happening until recently.
The controller misses that the first pod transitioned to unready and proceeds to create the second pod. The test uses a client to hit the api server and will scale up the statefulset as soon as the broken pod is observed but the controller uses caches so it may observe the scaled up statefulset quicker than the updated pod.
I will update the test to ensure that we wait until the unreadiness is observed on StatefulSet.Status.Replicas field prior to the scaling operation
SGTM
Code change:
glog.V(2).Infof("ensure(%s) abort backoff: lb(%s) - updating", serviceName, lbName) return nil, err } <ins> if isInternal { // Refresh updated lb which will be used later in other places. newLB, exist, err := az.getAzureLoadBalancer(lbName) if err != nil { glog.V(2).Infof("getAzureLoadBalancer(%s) failed: %v", lbName, err) return nil, err } if !exist { return nil, fmt.Errorf("load balancer %q not found", lbName) } lb = &newLB } </ins> } }

Related discussion:
text: <!-- 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: Internal Load Balancer created and associated with availability set but no target network ip configurations on Azure. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Create Kubernetes service of type LoadBalancer, annotate with "". Anything else we need to know?: Refer Environment: Kubernetes version (use ): 1.9.1 Cloud provider or hardware configuration: azure OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig azure
/assign
/kind bug
Root cause: removes the logic for retrieve private ip. This is required however The controller-manager will crash every time new ilb was created, then will restart and get the IP then. Should get the ip in first round.
Code change:
"//pkg/kubelet/config:go_default_library", "//pkg/volume:go_default_library", "//pkg/volume/util:go_default_library", <ins> "//pkg/volume/util/types:go_default_library", </ins> "//pkg/volume/util/volumepathhandler:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library",

Related discussion:
text: What happened: An iSCSI PV with is mounted without these options. What you expected to happen: The volume is mounted with . Anything else we need to know?: iSCSI volume is mounted in and passes as : This can be fixed trivially, however, why is it mounted in at all? There is another mount attempt in , with correct mount options: This code is skipped, because the volume is already mounted. Environment: Kubernetes version (use ): today's master, v1.19.0-alpha.0.781+-dirty , do you remember why we mount stuff in ? iSCSI and FibreChannel does so, the others don't.
/sig storage
Code change:
expectedCode   int expectedError  error }{ <del> {`echo "Hello"`, true, "Hello", "", 0, nil}, // Same as previous, but useful for test output diagnostics. </del> <ins> // Keep this test first - this variant runs on all nodes. </ins> {`echo "Hello from $(whoami)@$(hostname)"`, false, "", "", 0, nil}, {`echo "foo" | grep "bar"`, true, "", "", 1, nil}, {`echo "Out" && echo "Error" >&2 && exit 7`, true, "Out", "Error", 7, nil}, } <del> // Run commands on all nodes via SSH. for _, testCase := range testCases { By(fmt.Sprintf("SSH'ing to all nodes and running %s", testCase.cmd)) for _, host := range hosts { </del> <ins> for i, testCase := range testCases { // Only run the first testcase against max 100 nodes. Run // the rest against the first node we find only, since // they're basically testing SSH semantics (and we don't // need to do that against each host in the cluster). nodes := len(hosts) if i > 0 { nodes = 1 } else if nodes > maxNodes { nodes = maxNodes } testhosts := hosts[:nodes] By(fmt.Sprintf("SSH'ing to %d nodes and running %s", len(testhosts), testCase.cmd)) for _, host := range testhosts { </ins> result, err := framework.SSH(testCase.cmd, host, framework.TestContext.Provider) stdout, stderr := strings.TrimSpace(result.Stdout), strings.TrimSpace(result.Stderr) if err != testCase.expectedError {

Related discussion:
text: On 2k nodes, this test took 53m. We should either do it in batches of nodes, or just subsample the nodes.
And it probably doesn't need to test 4 different variant command sets against all of the nodes, either. :P
When you asked me about the 2k node test, this was the test that was running. I'm not sure why other tests weren't also running in parallel or if this was just the final long pole, but it's a beastly test. PR incoming.
- thanks for looking into it. THe PR is already lgtm-ed by me.
Code change:
if err != nil { t.Errorf("unexpected error: %v", err) } <del> if !reflect.DeepEqual(fakeDocker.Removed, test.expectedRemoved) { t.Errorf("expected: %v, got: %v", test.expectedRemoved, fakeDocker.Removed) } </del> <ins> verifyStringArrayEqualsAnyOrder(t, test.expectedRemoved, fakeDocker.Removed) </ins> } }

Related discussion:
text: Successfully ran containers with "onFailure" restartPolicy are restarting after purging oldest docker containers. Kubelet purges/removes oldest containers periodically from docker. After purging, we loose the exit code and history of previously ran containers and restart containers as if they were never run.
Thanks & I can help fix this. Let me know. Thanks
Thanks for reporting Just to make sure I understand the issue: You ran some containers with an "onFailure" restartPolicy. When the Kubelet purged old containers the container was restarted (unexpectedly).
Ah, after reading again I think the issue is that after the containers are purged, when the container exits successfully it get restarted although it shouldn't. Is that correct?
After reading through the code I found a bug in the implementation that is most likely causing this error. Should have a PR soon.
Yes. Correct. After initial container run, it should never be run again, since it already ran to completion. Will wait for your PR.
PR is out. This should fix the issue. Feel free to test if you can :)
Code change:
fi mkfs -t ext4 ${block_devices[0]} <del> echo "${block_devices[0]}  /mnt/ephemeral  ext4     noatime  0 0" >> /etc/fstab </del> <ins> echo "${block_devices[0]}  /mnt/ephemeral  ext4     noatime,nofail  0 0" >> /etc/fstab </ins> mkdir -p /mnt/ephemeral mount /mnt/ephemeral

Related discussion:
text: On AWS we (will) now run our bootstrap script on every boot. The function to initialize ephemeral volumes doesn't tolerate being re-run, and we probably shouldn't re-run it anyway for speed. This does preserve the contents, which may be a good thing to save user's data (it doesn't belong on ephemeral drives, but...). On the other hand, if the ephemeral drives are corrupted, we lose the opportunity to reformat them and recover. Arguably, if the ephemeral storage is corrupted the right thing to do is to terminate the instance entirely.
Code change:
// matches NodeInfo.node and the pod is not found in the pods list. Otherwise, // returns true. func (n *NodeInfo) Filter(pod *v1.Pod) bool { <del> pFullName := util.GetPodFullName(pod) </del> if pod.Spec.NodeName != n.node.Name { return true } for _, p := range n.pods { <del> if util.GetPodFullName(p) == pFullName { </del> <ins> if p.Name == pod.Name && p.Namespace == pod.Namespace { </ins> return true } }

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --It is not a secret that . In my opinion the main reason for the slowness is the flexibility of the inter-pod affinity/anti-affinity rules. However, in most practical scenarios users do not need all the flexibility. For example, people often do not use arbitrary labels in topology key of the affinity rules. They often use node, zone, or region as the topology. Node in particular is used often. That's why I am proposing a fast path for the case that topology key is Node. Today, the affinity/anti-affinity predicate does not have any distinction for topology keys and in the cluster regardless. The logic should recognize "" and scan only pods on the same node for this topology key. Is this a BUG REPORT or FEATURE REQUEST?: FEATURE REQUEST /kind feature /sig scheduling cc/
ref/
/assign
GitHub didn't allow me to assign the following users: misterikkit. Note that only can be assigned. <detailsIn response to : /assign 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
We found some other simple optimizations that had a significant impact on the affinity predicate. I will upload PRs for those as well.
Reopening this as the performance of anti-affinity still doesn't seem to be satisfactory enough on large clusters (i.e 5k nodes) - and it's causing them to fail to startup. Ref: issue I can help with evaluating any performance improvements if needed.
The change sent improved performance of the predicate, but apparently it is not enough to make our large scale scalability tests happy.
This issue is not about general performance improvment of affinity/anti-affinity. It was to implement a particular improvment which is already implemented. There are other performance improvement issues. I am going to close this one.
Sounds good. Thanks.
How come with kops 1.10.0 I still see all kube-dns pods on the same node because the kube-dns deployment doesn't specify any anti-affinity rule?
I think you are correct. you can double-check with the option to . I have a v1.9 cluster in front of me, and kube-dns has no affinity rules. (I didn't use kops though)
Code change:
// TODO: the name/domain name pair should ideally be checked for naming convention // as done in kube-dns federation flags check. // https://github.com/kubernetes/dns/blob/master/pkg/dns/federation/federation.go <del> util.FedDomainMapKey: fmt.Sprintf("%s=%s", name, dnsZoneName), </del> <ins> // TODO v2: Until kube-dns can handle trailing periods we strip them all. //          See https://github.com/kubernetes/dns/issues/67 util.FedDomainMapKey: fmt.Sprintf("%s=%s", name, strings.TrimRight(dnsZoneName, ".")), </ins> }, }, Spec: extensions.DeploymentSpec{

Related discussion:
text: Looking at our latest e2e CI , they appear to be due to the fact that the "federations value" for kube-dns install a domain with a trailing dot. The trailing period does not appear when I bring up the cluster manually with I suspect that somewhere we are reconstructing a FEDERATIONSDOMAINMAP when it is unset and a trailing period gets there.
is this blocking for 1.6?
Fixed by
Code change:
if isHTEnabled() { cpuList = cpuset.MustParse(getCPUSiblingList(0)).ToSlice() cpu1 = cpuList[1] <ins> } else if isMultiNUMA() { cpuList = cpuset.MustParse(getCoreSiblingList(0)).ToSlice() cpu1 = cpuList[1] </ins> } expAllowedCPUsListRegex = fmt.Sprintf("^%dn$", cpu1) err = f.PodClient().MatchContainerOutput(pod1.Name, pod1.Spec.Containers[0].Name, expAllowedCPUsListRegex)

Related discussion:
text: Which jobs are failing: N/A - AFAICT CI jobs works fine Which test(s) are failing: Since when has it been failing: no historical record on CI Testgrid link: N/A Reason for failure: I believe the tests make too many assumptions around the hardware, and the code is actually OK. to be confirmed. Anything else we need to know:
/sig node /sig testing
also affects the recently topology manager e2e tests. My PR uses a different approach to check resource alignment so is not affected. /cc
I'll work on a PR to fix this issue ASAP
Thanks for opening this issue. We knew about this, just had not opened an issue to track it, so thanks for doing that! Deepthi has been looing at CPU Manager tests, not sure if she has some PR in progress or not. I'll make sure to forward this to her (can find her user id here ....) in case she has something in progress
Code change:
} } } <ins> func TestInlineReadOnly(t *testing.T) { g := NewGCEPersistentDiskCSITranslator() pv, err := g.TranslateInTreeInlineVolumeToCSI(&v1.Volume{ VolumeSource: v1.VolumeSource{ GCEPersistentDisk: &v1.GCEPersistentDiskVolumeSource{ PDName:   "foo", ReadOnly: true, }, }, }) if err != nil { t.Fatalf("Failed to translate in tree inline volume to CSI: %v", err) } if pv == nil || pv.Spec.PersistentVolumeSource.CSI == nil { t.Fatal("PV or volume source unexpectedly nil") } if !pv.Spec.PersistentVolumeSource.CSI.ReadOnly { t.Error("PV readonly value not true") } ams := pv.Spec.AccessModes if len(ams) != 1 { t.Errorf("got am %v, expected length of 1", ams) } if ams[0] != v1.ReadOnlyMany { t.Errorf("got am %v, expected access mode of ReadOnlyMany", ams[0]) } } </ins>

Related discussion:
text: When running CSI migration tests focussing on multi-attach scearnios with GCE PD inline volumes that are read-only, the following error pops up in the logs and the second attachment takes 6 mins: For read-only inline volumes, the above warning/error around is unexpected with CSI migration enabled and needs to be root-caused/resolved. What happened: CSI migration tests for read-only inline GCE PD volumes occasionally fails with the above messages in the logs when executing tests like What you expected to happen: The tests and multi-attach scenarios to execute smoothly with no warnings in the logs. How to reproduce it (as minimally and precisely as possible): Execute with focus set to and run a few times. Anything else we need to know?: This has been observed with CSI migration enabled and the tests exercising read-only inline volume scenarios. Environment: Kubernetes version (use ): v1.16 Cloud provider or hardware configuration: GCE OS (e.g: ): Kernel (e.g. ): Install tools: kube- Network plugin and version (if this is a network-related bug): Others:
/cc
/sig storage
Looks like hard coding access modes to ReadWriteOnce during translation for GCE PD at is causing isMultiAttachForbidden to return leading down to We need to set the access mode to ReadOnlyMany for in-tree inline volumes like in GCE PD (as well as others like EBS that support multi-attach) depending on instead of always setting it to ReadWriteOnce.
I can pick up this fix /assign
Code change:
actualEvent := <-createEvent validateEvent(strconv.Itoa(index), actualEvent, item.expect, t) } <del> logWatcher1.Stop() logWatcher2.Stop() </del> <ins> logWatcher.Stop() </ins> } sinkWatcher.Stop() }

Related discussion:
text: I wasn't able to find automatically create issue for this, but I may not know what to search for. Is our bot creating issues for unit test failures? - this failure looks to me as something in client testing libraries.
If it's exposed in JUnit output, then the bot should be making issues for it.
It's not exposed in junit due to :(
Lots of failures in , probably all this bug.
Yeah this seems to be happening a lot. Raising priority.
I thought was reverted but it's not. I'll revert it.
golang 1.6 doesn't fix the race:
Sent .