Bug 1694859
| Summary: | image source extraction w/ symlink fails | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Ben Parees <bparees> | ||||||||||||||
| Component: | Build | Assignee: | Adam Kaplan <adam.kaplan> | ||||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | wewang <wewang> | ||||||||||||||
| Severity: | high | Docs Contact: | |||||||||||||||
| Priority: | unspecified | ||||||||||||||||
| Version: | 4.1.0 | CC: | aos-bugs, ccoleman, sponnaga, wzheng | ||||||||||||||
| Target Milestone: | --- | Keywords: | NeedsTestCase | ||||||||||||||
| Target Release: | 4.1.0 | ||||||||||||||||
| Hardware: | Unspecified | ||||||||||||||||
| OS: | Unspecified | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Fixed In Version: | Doc Type: | No Doc Update | |||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||
| Last Closed: | 2019-06-04 10:46:44 UTC | Type: | Bug | ||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||
| Embargoed: | |||||||||||||||||
| Attachments: |
|
||||||||||||||||
fyi we hit this because i was using an old ci-operator binary which referenced content via the symlink location. The new ci-operator binary uses the paths to the real files and thus works on 4.x clusters. But this is still a valid bug/regression in behavior (well actually maybe we need to confirm what the 3.x behavior was...I had assumed ci-operator was always doing this and it worked on 3.x but perhaps that assumption is not valid). Regardless it does not appear to block api.ci from moving to 4.x. (unless there are specific build configurations that do use symlinks in a way that breaks here) specifically this change in ci-operator moved from symlink to real file: https://github.com/openshift/ci-operator/commit/35523cc58ae1674fec3791656759eb1d6c039f60#diff-dd3690bad12236edb7359fb0e2df4ccd Testing this on a local 3.11 cluster - looks like COPYing symlinks only works if: a) The symlink and target are extracted. b) The relative paths between the symlink and target are preserved. I suspect this is because the source is TARed and sent as input to the docker daemon. In 4.0 this doesn't work - buildah mounts in the local filesystem as the context for its build. So if our local file system contains a symlink with an absolute path, it will likely break. Created attachment 1553922 [details]
relative symlink bc with source
BuildConfig with symlink image source that works on 3.11. Uses relative paths.
Created attachment 1553923 [details]
relative symlink bc no source
Build config with symlink, but only copies the link. Fails on 3.11.
Created attachment 1553925 [details]
abs symlink bc source
BuildConfig with source using absolute symlinks. Fails on 3.11, though there may be some edge cases where this succeeds.
Created attachment 1553927 [details]
abs symlink bc link only
BuildConfig with absolute symlink, no source copied. Always fails on 3.11.
Created attachment 1553931 [details]
symlink bc test case
Attached bc succeeds on 3.11, breaks on 4.1.
This is a blocker IMO - developers will extract a parent directory and not care about the content within.
Created attachment 1554339 [details]
source Dockerfile
Dockerfile for source, symlink uses a relative path
Add a test case:OCP-23174 for the bug PR to ensure we're extracting symlinks in images correctly: https://github.com/openshift/origin/pull/22456 Moving this to MODIFIED. Origin PR [1] verifies that the copy behavior is correct if the source image contains a relative symlink. Related bug 1698152 [2] contains the actual code fix. [1] https://github.com/openshift/origin/pull/22456 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1698152 Verified in version: 4.1.0-0.nightly-2019-04-22-005054 payload: registry.svc.ci.openshift.org/ocp/release@sha256:3f3628cd9b694705cb0627ce72e61932df5d9938a291fabba1ed691230f7b548 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:0758 |
Description of problem: Performing a build where the image source input path specified is a symlink. The extraction process appears to copy the symlink, not the content referenced by the symlink, meaning the build ultimately fails when it can't find the expected content. This appears to be a regression from the behavior we had in 3.x when extracting image content to use for build inputs. How reproducible: Always Steps to Reproduce: 1. Create an input image with a symlink like "/symlink" that points to "/some/file" 2. Create a build that uses the input image: images: - as: someimage from: kind: DockerImage name: docker.io/my/symylink:image paths: - destinationDir: . sourcePath: /symlink 3. Make the build try to use the referenced input content as "./some/file" Actual results: build fails, "./some" is not a valid path in the input content Expected results: build succeeds, ./some/file is a valid file because the symlink was followed during content extraction/copying. Additional Info: Should first confirm the behavior on 3.11 but we are seeing this as a difference in behavior when moving CI from 3.x to 4.x.