Code change:
Which jobs are failing: ci-kubernetes-e2e-kops-aws pull-kubernetes-e2e-kops-aws Which test(s) are failing: [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: block] [Testpattern: Pre-provisioned PV (xfs)] volumes should allow exec of files on the volume [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: block] [Testpattern: Pre-provisioned PV (xfs)] volumes should be mountable Since when has it been failing: Don't know.. as the job was down for a while due to Testgrid link: Reason for failure: To be found.. Anything else we need to know: This issue is a blocker for turning on the kops-aws presubmit, see - /cc /kind failing-test /sig storage
cc
By looking at the log this line is suspicious: Both testcases share similar error message. And that comes from when doing I guess its some mount client missing from the AMI so that the mount library can't find it.
Looks like the test needs to skip XFS on environments that do not support XFS
This is where the environment is checked to skip xfs:
Thanks Michelle! - Could you comment if we need to skip it in aws tests?
Looks like this was broken by - shall we revert? cc
Actually looking at the GCE tests for kops it was broken before . I'm wondering if we assumed xfs back in
/priority critical-urgent this is blocker for kops currently example of failing build
do you have idea could break this?
Yes, in , I tests for local volume which use . Because , PR is not blocked by gce e2e test. hi, Quick way to fix is to remove from supported types, I can submit a PR for this.
Alternatively, we can skip for environments which do not support XFS . What do you think?
I do not know what is the best solution in long term but in short term we should get kops e2e tests working. So if removing xfs from supported types is fastest solution - i would go with that. After that tests could be fixed how those should be. Could you do that PR and remove from supported types?
Hard-coding the knowledge which clusters or tests support XFS (because that's what it is - a dependency on a kernel feature, right?) in the test source code is just bound to fail eventually. What if the presence of xfs support depends on the "gci" version? This line doesn't cover that: I would prefer to mark tests which depend on XFS kernel support with or something like it (no idea how descriptive feature tags need to be) and then enable those test cases only in jobs where the target cluster is known to have XFS. If you extend that check as a short-term solution, then please file an issue about it and link to it next to the check. /cc
Agreeing with here... Isn't there a way to check if the kernel we test for/ against is supporting it more directly? Building a huge list of whats compatible and what's not sounds not perfect to me.
Long term we can enhance the check to ssh into a random node and see if the binary exists. Short term let's just remove xfs testing for local volumes.
If these two are newly tests, agree to skip (or remove) xfs testing to unblock PRs.
assuming all these in-tree tests will be less important over the course of the year as CSI moves forward... so should we assume that the XFS tests will never come back . ?
The local volume driver plan is to remain in-tree for the medium-term future. I think we should continue to add the environment check for xfs so we can add it back.

Related discussion:
text: "ext2", "ext3", "ext4", <del> "xfs", </del> <ins> //"xfs", disabled see issue https://github.com/kubernetes/kubernetes/issues/74095 </ins> ), } // max file size