search

kubernetes / test-infra

Test infrastructure for the Kubernetes project.
Apache License 2.0
3.85k stars 2.66k forks source link

etcd bbolt robustness tests fail to run #33737

Open ivanvc opened 1 month ago

ivanvc commented 1 month ago

What happened:

While migrating etcd bbolt ARM64 GitHub workflows to the prow infrastructure, we're facing issues trying to enable our robustness tests. Bbolt robustness tests require dm-flakey, which requires xfsprogs (XFS). I believe the problem is that the host machine doesn't have support/or uses that file system. Even though this is initially required for our ARM64 jobs, we would expect to have it working for the AMD64 architecture in the future.

What you expected to happen:

We should be able to run the robustness tests in the prow infrastructure.

How to reproduce it (as minimally and precisely as possible):

The pull request https://github.com/etcd-io/bbolt/pull/849 has the changes to attempt to run this prow job.

Please provide links to example occurrences, if any:

Refer to the Prow job logs:

Anything else we need to know?:

Thanks for your help.

k8s-ci-robot commented 1 month ago

There are no sig labels on this issue. Please add an appropriate label by using one of the following commands:

Please see the group list for a listing of the SIGs, working groups, and committees available.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
ivanvc commented 1 month ago

Link to https://github.com/etcd-io/bbolt/issues/848

BenTheElder commented 3 weeks ago

If you have strong requirements on the host kernel, the best approach is to spin up an external VM (in a project/account rented from https://github.com/kubernetes-sigs/boskos) and NOT depend on what the prow host machines have (and also avoid interacting with the host kernel, versus e.g. running unit tests).

Most subprojects are spinning up kubernetes clusters rather than individual VMs, but you might be able to reach out to folks in sig node about node e2e tests and how they're running those, as the most similar thing we run currently.