Bug 1810085 - buildah: Build of openshift/router project on 4.3 is not equivalent to 3.11, missing file
Summary: buildah: Build of openshift/router project on 4.3 is not equivalent to 3.11, ...
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Containers
Version: 4.3.z
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.5.0
Assignee: Daniel Walsh
QA Contact: weiwei jiang
Depends On:
TreeView+ depends on / blocked
Reported: 2020-03-04 14:22 UTC by Clayton Coleman
Modified: 2020-05-14 20:23 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-05-14 20:23:19 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Clayton Coleman 2020-03-04 14:22:56 UTC
The router build, when run against a 4.3 build cluster (instead of api.ci 3.11 cluster) failed to put a source file into the right path in the image.


STEP 4: COPY images/router/haproxy/* /var/lib/haproxy/

Should put conf/haproxy-config.template into /var/lib/haproxy/conf/haproxy-config.template (and does on 3.11)

But in 4.3:


error: open /var/lib/haproxy/conf/haproxy-config.template: no such file or directory

While inspecting the image the file is in /var/lib/haproxy/ instead.

This must be fixed before we can move jobs to 4.3 cluster.  It is also a serious regression and would block buildah use in osbs

Comment 1 Ben Parees 2020-03-04 14:30:03 UTC
the described behavior appears to be consistent with docker build:

$ tree
├── Dockerfile
└── foo
    └── dir
        └── file

2 directories, 2 files

$ docker build .
Sending build context to Docker daemon  4.096kB
Step 1/4 : FROM centos
 ---> 0f3e07c0138f
Step 2/4 : COPY foo/* /tmp
 ---> Using cache
 ---> 85811f7b6993
Step 3/4 : RUN cat /tmp/file
 ---> Using cache
 ---> cda4a2c1438a
Step 4/4 : RUN cat /tmp/dir/file
 ---> Running in 9c831ba73fba
cat: /tmp/dir/file: No such file or directory

so i'm surprised this would have behaved differently in 3.11 unless imagebuilder was behavior in a way that's not aligned w/ docker.

Comment 4 Tom Sweeney 2020-03-04 18:15:33 UTC
I'm going to assign this one to Dan to let him decide on how to proceed.

Comment 5 Ben Parees 2020-03-04 19:50:09 UTC
(for now we are proceeding w/ updating our dockerfiles that are impacted by this to not use wildcards, so that however this is resolved, they should work)

Comment 6 Daniel Walsh 2020-03-10 17:50:34 UTC
Tom this looks like a bug in Buildah?

Comment 7 Ben Parees 2020-03-10 17:59:42 UTC
it's debatable if it's a bug.  Buildah is matching Docker's behavior on this, so changing it could break people.

But Clayton has expressed an interest in at least having a buildah flag for choosing whether you want "proper" behavior or "broken docker compatible" behavior.

see also:

Comment 8 Tom Sweeney 2020-03-10 22:11:04 UTC
Dan I'm not sure I'd call this a bug, but to do the correction that Ben is talking about I'm pretty sure would have to happen in the Buildah space.

Comment 14 Tom Sweeney 2020-05-14 20:23:19 UTC
As the behavior in OCP 3.11 does not correlate with Docker's, and Buildah's design center is to not create a difference in runtime behavior between Docker and Buildah, we're considering this an RFE.  As such, we've created an internal card to track the work to add a flag to emulate the old behavior and it will be addressed in a future release.

Note You need to log in before you can comment on or make changes to this bug.