Fix remote Quarkus builds failing on s390x and ppc64le clusters#3665
Fix remote Quarkus builds failing on s390x and ppc64le clusters#3665Itx-Psycho0 wants to merge 1 commit intoknative:mainfrom
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Itx-Psycho0 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Welcome @Itx-Psycho0! It looks like this is your first PR to knative/func 🎉 |
knative-prow
Bot
added
size/L
|
Hi @Itx-Psycho0. Thanks for your PR. I'm waiting for a knative member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
Hi @lkingland @jrangelramos @gauron99 I've implemented a fix for issue #3515 where remote Quarkus builds fail on s390x and ppc64le clusters due to FSGroup permissions not being honored on the build PersistentVolume. The solution adds proper security context configuration to the Tekton PipelineRun podTemplate for both Pack and S2I builders. This ensures all task pods inherit the correct security context for volume access on architectures that require explicit FSGroup configuration. All unit tests pass, linting is clean, and I've added a test to verify the podTemplate with securityContext is present in generated PipelineRuns. Would appreciate your review and any feedback. Thanks! |
|
/ok-to-test |
knative-prow
Bot
added
ok-to-test
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3665 +/- ##
==========================================
+ Coverage 56.61% 56.63% +0.02%
==========================================
Files 181 181
Lines 20853 20853
==========================================
+ Hits 11806 11811 +5
+ Misses 7833 7830 -3
+ Partials 1214 1212 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…support Fixes knative#3515 Remote Quarkus builds were failing on s390x and ppc64le clusters due to FSGroup permissions not being honored on the build PersistentVolume. This fix adds a podTemplate with securityContext (including fsGroup) to both Pack and S2I PipelineRun templates. This ensures all Tekton task pods inherit proper security context for volume access on architectures where FSGroup permissions need explicit configuration. Changes: - Add podTemplate with securityContext to packRunTemplate - Add podTemplate with securityContext to packRunTemplatePAC - Add podTemplate with securityContext to s2iRunTemplate - Add podTemplate with securityContext to s2iRunTemplatePAC - Add test to verify podTemplate with securityContext is present Security context values: - runAsUser: 1001 (matches Tekton buildpack task) - runAsGroup: 0 (matches Tekton buildpack task) - fsGroup: 1002 (ensures volume ownership for non-root users)
Itx-Psycho0
force-pushed
the
fix/3515-quarkus-s390x-fsgroup
branch
from
450c963 to
abd0b7d
Compare
|
Have you tested this on an OCP cluster? |
|
Hi @matejvasek, Thanks for the review! I haven't tested this on an actual OCP cluster yet as I don't currently have access to an s390x/ppc64le environment. However, the fix follows the same pattern used in other Kubernetes projects for handling FSGroup permissions on these architectures. The changes add:
The implementation is based on the standard Kubernetes security context approach documented here: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ If you have access to an OCP cluster with s390x/ppc64le, I'd be happy to help test this. Alternatively, if there's a specific test scenario you'd like me to verify, please let me know. The unit tests pass and the code follows the existing patterns in the codebase. Would you be able to test this on an OCP cluster, or should I look into getting access to one for testing? |
|
@jrangelramos would you mind giving this a try on a OCP cluster? |
2 participants
This fix addresses the issue where remote Quarkus builds fail on s390x and ppc64le clusters.
The problem was that FSGroup permissions were not being honored on the build PersistentVolume, which prevented the build process from accessing its workspace correctly.
The solution adds a podTemplate with proper security context settings to both the Pack and S2I PipelineRun templates. This ensures that all Tekton task pods inherit the correct security context for volume access. On s390x and ppc64le architectures, some storage backends require explicit FSGroup configuration to properly handle volume permissions.
What changed:
The security context is configured with:
All tests pass and linting checks are clean. This fix is compatible with all architectures and will not affect existing functionality on amd64 systems.
Fixes #3515