Bug 1810085

Summary:	buildah: Build of openshift/router project on 4.3 is not equivalent to 3.11, missing file
Product:	OpenShift Container Platform	Reporter:	Clayton Coleman <ccoleman>
Component:	Containers	Assignee:	Daniel Walsh <dwalsh>
Status:	CLOSED NOTABUG	QA Contact:	weiwei jiang <wjiang>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	4.3.z	CC:	aos-bugs, bparees, dwalsh, jnovy, jokerman, mpatel, schoudha, tsweeney, wzheng
Target Milestone:	---
Target Release:	4.5.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-05-14 20:23:19 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.