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, ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Containers
Version: 4.3.z
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 4.5.0
Assignee: Daniel Walsh
QA Contact: weiwei jiang
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
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.

https://prow.svc.ci.openshift.org/view/gcs/origin-ci-test/pr-logs/pull/openshift_router/94/pull-ci-openshift-router-master-e2e-aws/333

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:

https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_router/94/pull-ci-openshift-router-master-e2e-aws/333/artifacts/e2e-aws/pods/openshift-ingress_router-default-6896776f44-58vn9_router.log

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:
https://bugzilla.redhat.com/show_bug.cgi?id=1810181
and
https://bugzilla.redhat.com/show_bug.cgi?id=1810709

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.