jiebi/CodeConvo huggingface dataset:
Change:
}) podUID := string(pod.UID) ginkgo.By("checking if the expected hugetlb settings were applied") <del> verifyPod := makePodToVerifyHugePages("pod"+podUID, resource.MustParse("50Mi")) </del> <ins> verifyPod := makePodToVerifyHugePages("pod"+podUID, resource.MustParse("6Mi")) </ins> f.PodClient().Create(verifyPod) err := e2epod.WaitForPodSuccessInNamespace(f.ClientSet, verifyPod.Name, f.Namespace.Name) framework.ExpectNoError(err)

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: -tests Since when has it been failing: Unsure Testgrid link: Reason for failure: Unable to pre allocate 50x2MiB huge pages, probably due to memory pressure caused by kernel level caching. If requesting an substantial amount of huge page memory (like the tests), it is recommended to to it as early after boot as possible, or by using the kernel cmd line. Eg. this one: Anything else we need to know: will fix this issue, but in awaiting for that, we can just decrease the page count in the tests.
/sig node /cc derekwaynecarr
I think the reason of railure should be because a single hugepage of x86 is 2MiB as and a single page is 4KiB, not 2KiB.
Yes, is correct. Thanks for catching the typo :smile:
Looks like we still have some flakes in the huge page test, even tho the test now only requests of huge page memory. Happens way less frequently than previously tho. This is probably because the kernel is caching a lot of stuff, making it hard for the kernel to fix it. Ill do some testing with dropping the caches (no user facing stuff will happen, only kernel level) before trying to pre allocate huge pages. /reopen
Reopened this issue. <detailsIn response to : Looks like we still have some flakes in the huge page test, even tho the test now only requests of huge page memory. Happens way less frequently than previously tho. 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
/close
Closing this issue. <detailsIn response to : /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:
} // However, "empty" preFilterState is legit which tolerates every toSchedule Pod. <del> if len(s.TpPairToMatchNum) == 0 || len(s.Constraints) == 0 { </del> <ins> if len(s.Constraints) == 0 { </ins> return nil }

Discussion:
What happened: I was testing out the pod topology spread functionality in a local k8s cluster. I noticed that when I set the constraint to be pods are still successfully scheduled. What you expected to happen: Reading the documentation on , I expected pods not to be scheduled since the node should be "bypassed due to the absence of label". Did I miss something here? How to reproduce it (as minimally and precisely as possible): Create a pod with topologySpreadConstraints[0].topologyKey that does not match to any node labels, and set to . Anything else we need to know?: Thank you Environment: Kubernetes version (use ):Cloud provider or hardware configuration: It's a kind cluster created with image . OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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
/sig scheduling
This sounds like a bug, I will look into it. /assign
Change:
}, }, } <del> glog.V(2).Infof("azureDisk - update(%s): vm(%s) - attach disk", nodeResourceGroup, vmName) </del> <ins> glog.V(2).Infof("azureDisk - update(%s): vm(%s) - attach disk(%s)", nodeResourceGroup, vmName, diskName) </ins> ctx, cancel := getContextWithCancel() defer cancel() <del> resp, err := as.VirtualMachinesClient.CreateOrUpdate(ctx, nodeResourceGroup, vmName, newVM) if as.CloudProviderBackoff && shouldRetryHTTPRequest(resp, err) { glog.V(2).Infof("azureDisk - update(%s) backing off: vm(%s)", nodeResourceGroup, vmName) retryErr := as.CreateOrUpdateVMWithRetry(nodeResourceGroup, vmName, newVM) if retryErr != nil { err = retryErr glog.V(2).Infof("azureDisk - update(%s) abort backoff: vm(%s)", nodeResourceGroup, vmName) } } if err != nil { glog.Errorf("azureDisk - azure attach failed, err: %v", err) </del> <ins> if _, err := as.VirtualMachinesClient.CreateOrUpdate(ctx, nodeResourceGroup, vmName, newVM); err != nil { glog.Errorf("azureDisk - attach disk(%s) failed, err: %v", diskName, err) </ins> detail := err.Error() if strings.Contains(detail, errLeaseFailed) || strings.Contains(detail, errDiskBlobNotFound) { // if lease cannot be acquired or disk not found, immediately detach the disk and return the original error <del> glog.Infof("azureDisk - err %s, try detach", detail) </del> <ins> glog.V(2).Infof("azureDisk - err %v, try detach disk(%s)", err, diskName) </ins> as.DetachDiskByName(diskName, diskURI, nodeName) } } else { <del> glog.V(4).Info("azureDisk - azure attach succeeded") </del> <ins> glog.V(2).Infof("azureDisk - attach disk(%s) succeeded", diskName) </ins> // Invalidate the cache right after updating as.cloud.vmCache.Delete(vmName) }

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: retry azure disk attach operation produce too many API calls Not the default value is 6 which means if AttachDisk operation failed, it will retry 6 more times, when disk quota is full on a VM, it produces too many API calls. Retry attach disk behavior is not necessary since it AttachVolume operation fails, k8s attachdetach-controller will retry once a minute until it succeeds. default setting in What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.10, v1.11, v1.12 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug /sig azure /assign
Change:
"Shell" "Daemonsset" "Deployment" <ins> "experimentalsresourcesusagestracking" # Expect --max-pods=100 </ins> ) <ins> # Tests which cannot be run on AWS. AWS_REQUIRED_SKIP_TESTS=( "experimentalsresourcesusagestracking" # Expect --max-pods=100 ) </ins> # The following tests are known to be flaky, and are thus run only in their own # -flaky- build variants. GCE_FLAKY_TESTS=(

Discussion:
For example: I'm disabling the test in But we need to re-enable it, or roll-back the test.
fyi
Shouldn't this is part slow test, and the fix should be either: 1) Increase Kubernetes-e2-gke-ci timeout value if decide to include slow to that project or 2) disable all slow tests on that project? cc/ Which one is required here?
The test runs 50 pods per node, which is over the default --max-pod limit of kubelet. The test relies on the flag --max-pods=100 being set in cluster/gce/config- I will disable it for all GKE tests in On the other hand, it's not clear to me where the timeout is set for a specific build. /cc
Timeouts for each Jenkins build are in the Jenkins project configurations themselves, which are not currently saved in version control anywhere. :
Discussed with about the test offline. There are several issues: Do we want to run any kind of kubelet resource monitoring test on GKE? Is it useful? We only override max-pods in GCE. Should the test itself figure out what platform it can run based on the #pods in the test (see ) Per-test configuration allows greater flexibility (e.g., we may run 100 pods on GCE to test kubelet's scalability), but it'd make the tests more complicated as they need to be aware of the test environment (which many e2e tests already do); there is also the burden of updating the tests once the max-pod value changes. Does this test belong to SLOW tests or should it belong to a new category? Not all slow tests have the same attributes. Arguably this test could be enabled only on selective builds. The downside would be more flags -- less readable/manageable e2e configs. Not all builds which run SLOW tests have the proper timeout value to run this test. We need to manually change them every time a slow test is . Re-assigning this back to since she has more concerns about the PR.
Had offline discussion with We are going to split current Kubelet resource usage tracking test into two, one is targeted for GCE, another one is for GKE. In this case, we won't mess up the test code itself by introducing knobs. Re-assign this back to
Change:
"x-kubernetes-patch-strategy": "merge" }, "hostAliases": { <del> "description": "HostAliases is an optional list of hosts and IPs that will be injected into the pod's hosts file if specified. This is only valid for non-hostNetwork pods.", </del> <ins> "description": "HostAliases is an optional list of hosts and IPs that will be injected into the pod's hosts file if specified.", </ins> "items": { "$ref": "#/definitions/io.k8s.api.core.v1.HostAlias" },

Discussion:
there is a note above hostAliases that this feature does not work with hostNework=true, yet it seems it does: when testing with a hostNetwork pod + hostAliases, there are no errors in kubelet logs at --v=10 related to this, in fact i don't see any hostAlias entries at all in there. i could not find anything blocking this in the kubelet, in fact there is normal handling of hostNetwork: i could not find any validation performed on the hostAliases field of PodSpec if hostNetwork is true on the API level. i could not find any unit tests or e2e tests related to this. the godoc should contain valid information if the feature is not supposed to work, it must be patched to not have the entries in the hosts file (perhaps?) we should have tests that ensure this type of requirement is guaranteed these steps confirm that a static pod with hostNework (deployed by kubeadm) does make use of hostAliases. create a kubeadm single node cluster directly with or one with modify the to include:wait some time for the new static pod spec to resync find the PID of the kube-apiserverget the hosts file n/a latest master 1.30.0-alpha.0 not applicable <details</detailskubeadm containerd v1.6.14 kindnet add test: update godoc:
/sig node network cluster-lifecycle /kind documentation
as reported by the hostAliases sometimes are not mounted for hostNetwork static pods, which is concerning: related slack thread:
At minimum the comment is wrong I need to be updated and we need e2e tests :/
found this, support was a while back: i will PR the API docs.
We identified an edge case here with Kubernetes v1.29. If a cloud provider did not yet initialise the node's , the code for creating the file including the hostAliases does not get run. To be concrete, in: is empty in this case which leads to to be . I was able to trace it back to this change which leads to this behaviour for static pods: For confirmation: I reverted the above commit, rebuilt kubelet and it got back to the old behaviour.

there is no perfect solution, but reverting is wrong because opens another bug, we need to study this more carefully but in the meantime installers that know the nodes addresses beforehand should set the --node-ip flag or not use cloud-provider external
yeah, as i mentioned downstream, revering is out of the question. it fixes some long standing problems. we might have to document somewhere this limitation in a cloud provider env.
i think it might be possible for us to special case this so that the hostAlias management does not wait for the node IP in a CP env, under certain conditions. just a speculation.
PRs add test: update godoc:
/triage accepted looks like it is being worked on already
Change:
--load  --pull  -t ${REGISTRY}/conformance-${ARCH}:${VERSION}  <del> --build-arg BASEIMAGE=$(BASEIMAGE)  </del> --build-arg RUNNERIMAGE=$(RUNNERIMAGE)  ${TEMP_DIR} rm -rf "${TEMP_DIR}"

Discussion:
N/A 07/18 02:38 PDT No response /sig release
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
Slack thread:
/sig cli
Change:
"path" "reflect" "regexp" <ins> "sort" </ins> "strconv" "strings" "sync"

Discussion:
Seeing random failures.
Looks like lately refactory makes docker API requests are not deterministic. Will look into it.
Any update? It seems to be failing a lot.
I just looked into this and found that is the only test that there are two pods in the which is fed to I think podworker was syncing the two pods in parallel, this causes non-deterministic behaviour I have tried , no errors. , error happens continuously. I can try to fix this :)
Yes, that is what I believe here, but never have time working on it. Thanks for looking into this, and re-assign it to you.
I saw your old PR for this, I think we still need to keep the parallel sync here. Just need to create a for this case :)
Change:
schedulerCPU = 0.75 schedulerMem = 500 * (1024 * 1024) } else if numNodes <= 500 { <del> apiserverCPU = 2.25 </del> <ins> apiserverCPU = 2.5 </ins> apiserverMem = 3400 * (1024 * 1024) controllerCPU = 1.3 controllerMem = 1100 * (1024 * 1024)

Discussion:
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
Change:
*3 These guide is tested OK on Ubuntu 14.04 LTS 64bit server, but it should also work on most Ubuntu versions* <del> *4 Dependences of this guide: etcd-2.0.9, flannel-0.4.0, k8s-0.15.0, but it may work with higher versions* </del> <ins> *4 Dependences of this guide: etcd-2.0.9, flannel-0.4.0, k8s-0.18.0, but it may work with higher versions* </ins> *5 All the remote servers can be ssh logged in without a password by using key authentication*

Discussion:
This flag is deprecated and no longer has any effect.
I wonder which version does this include.Now ubuntu approach is using ubuntu 0.15.0.
This change was checked in this week, so it will be true for clusters at 0.18.0+ (once the next release is cut next week). So the next time the ubuntu documentation is updated, this change should be reflected.
Ohit means that minion node can be automatically discovered by the master node when then kubelet set ? No other configuration is needed?
Yes, the kubelet, when passed the location of the apiserver, will register itself and then post node update messages. The only part that may depend on your deployment environment is the set of addresses that the kubelet passes to the apiserver. They will be based on the name of the node, reverse resolving the name of the node, or checking for addresses from the cloud provider.
Got it.I will include this when I updates the doc and scripts. Besides, I have a little questions here. Eric told me the addon services do not have service-account now.Will 0.18.0+ have it?
Service accounts will be included as part of 0.18.0 as well.
got it
- makes sense
Change:
pod.UID = types.UID(hex.EncodeToString(hasher.Sum(nil)[0:])) glog.V(5).Infof("Generated UID %q for pod %q from file %s", pod.UID, pod.Name, filename) } <ins> // This is required for backward compatibility, and should be removed once we // completely deprecate ContainerManifest. if len(pod.Name) == 0 { pod.Name = string(pod.UID) glog.V(5).Infof("Generated Name %q for UID %q from file %s", pod.Name, pod.UID, filename) } </ins> if len(pod.Namespace) == 0 { hasher := adler32.New() fmt.Fprint(hasher, filename)

Discussion:
I'm trying containervm with kubelet built from head and this YAML file: The YAML file is v1beta2 and doesn't set a name to the Pod. When starting kubelet, it doesn't start the "nc" echo server and complains about this on the logs: Chatting with on IM she mentioned it might be due to a change from that now requires non-empty pod names (replaces random generation with validation for non-emptiness) but that means all existing YAML files (even the ones with an older version) will stop working... Is that expected? Thanks! Filipe
Yes, the latest kubelet call validation on all sources: etcd, file, http, etc. now, and PodName is a required field. One potential fix for this is also invoke conversion code before call validation, like what we have done at apiserver. Thoughts?
Just so I get unblocked... Do you have an example YAML file that will set the pod name and will work? Right now this is what I'm using: Should I bump up version to v1beta3 and include a new field somewhere? Thanks! Filipe
The type of that yaml is not pod, and the kubelet code doesn't know how to read pods from a file. So, I think change needs to be reverted before you can make the next ContainerVM release. The v1beta2 vs v1beta3 should not have anything to do with it, unless I'm misunderstanding.
Or will it work to do this:
Still, not sure if you want to release a containerVM version that doesn't accept the old format?
Thanks I made it work with the YAML above! I still have errors in the logs: But the docker containers are being brought up... It's weird that is the YAML field that is missing, considering the source seems to say it's a deprecated field that will be removed at some point... I agree with your point that this needs to be fixed at head before the next containervm release. I opened to increase test coverage of standalone kubelet since we have been seeing many changes break that model recently. Cheers, Filipe
id in v1beta2 maps to name in v1beta3 Tim's change made name required. The internal representation is like v1beta3.

But v1beta3 is not officially stable so we don't want to use it in the GKE or containerVM docs.
The issue is caused by , and affect both v0.8 and v0.9 release for standalone kubelet to support old format ContainerManifests.
Ugh, I thought ID was really required. I spoke with Dawn a bit, and here's my thinking. 1) update all our docs and examples to include ID 2) in file and HTTP config sources, check for Name = "" and apply a default, maybe log a warning that this is deprecated 3) wait for the ContainerManifest -Pod conversion to really make it required
Change:
servicecontroller "k8s.io/kubernetes/pkg/registry/core/service/ipallocator/controller" portallocatorcontroller "k8s.io/kubernetes/pkg/registry/core/service/portallocator/controller" "k8s.io/kubernetes/pkg/util/async" <ins> netutils "k8s.io/utils/net" </ins> ) const (

Discussion:
Clusters created with kubeadm using DualStack are not able to work, because CoreDNS pods never get ready Seeing one failed job logs It seems that the pod is "waiting for the kubernetes service"?? coredns version seems the same as in the working jobs CoreDNS pod should be ready Instal a Dual-stack cluster using master with kubeadm (or kind ) ! It started to fail on Oct12 <details</details<details</details<details</details<details</details<details</details<details</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
/cc I didn't notice it was failing for more than 1 month :facewithhead_bandage: I didn't have time to dig into it yet, but this PR landed just that day how is that the pods running has the version 1.8.4 but the PR seems to update kubeadm to 1.8.6?
Looking into this today. The error from CoreDNS should only happen when the kubernetes plugin fails to sync with the Kubernetes API, either because it can’t connect, or it can’t sync the lists of services/endpointslices. There were changes and fixes to the API connection code, so it could be a regression.
Actually no. The changes I was thinking of were already in 1.8.4.
How can we reproduce it : Instal a Dual-stack cluster using master with kubeadm (or kind ) I was unable to reproduce this issue in a kind dual stack cluster.

After upgrading coredns to 1.8.6 (from 1.8.0 installed by kind), and adding list/watch permission for endpointslice, the pods were ready. edit: It also works for coredns 1.8.4 - I'm unclear as to which version I should be checking.
let me check if is a regression in kind :thinking:
working with 1.8.6 and yesterdays kubernetes podIPs
This is weird, I hit a similar issue in openshift, endpoints doesn't match the IP family of the kubernetes.default service apiserver service is single stack, at least until this KEP fixes it What I don't understand is why the order of the IPs in kind is different let me try to fix both things /assign
my fault, sorry for the noise :sweat_smile:
Change:
"fmt" "io/ioutil" "os" <ins> "path/filepath" </ins> "reflect" "runtime" "strings"

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: make test is failing due to build failure What you expected to happen: make test should be successful How to reproduce it (as minimally and precisely as possible): clone kubenetes git and run make test Anything else we need to know?: Environment: OS (e.g. from /etc/os-release):Kernel (e.g. ): GO Version: Other:
/sig testing
does help? are you out of space or have write permission problems in your /tmp directory?
this is happening in a clean environment and I hope got enough disk space! do you see golang/linker issues here?
All I see are missing files, not linker errors.
found the culprit, @ test is deleting the which is actually a - which is removing some of the files which are created by go compile process and failing because of this. Other places in kubernetes used and same logic needs to be used here as well.
good catch. yeah, each test should make its own tmp dir with . can you open a PR sweeping for that?
Just wanted to confirm I'm also experiencing the same build failure on HEAD ().
yes, will be out soon for review.
here is the PR to fix this issue -
Change:
"fmt" v1 "k8s.io/api/core/v1" <ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> "k8s.io/apimachinery/pkg/runtime" <del> "k8s.io/kubernetes/pkg/scheduler/algorithm/priorities" "k8s.io/kubernetes/pkg/scheduler/framework/plugins/migration" </del> <ins> v1helper "k8s.io/kubernetes/pkg/apis/core/v1/helper" </ins> framework "k8s.io/kubernetes/pkg/scheduler/framework/v1alpha1" )

Discussion:
/sig scheduling /priority important-soon See as an example. Part of This shouldn't need a PostFilter Plugin, it is not worth caching the result of metav1.GetControllerOf. /assign