Bug 1443274
| Summary: | Using secrets in a build config invalidates cache | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Brennan Vincello <bvincell> |
| Component: | Build | Assignee: | Ben Parees <bparees> |
| Status: | CLOSED CANTFIX | QA Contact: | Wenjing Zheng <wzheng> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.4.0 | CC: | aos-bugs, bparees, bvincell, dyan, lucastetreault, shea.stewart |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| 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: | 2017-05-03 18:30:21 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: | |||
|
Description
Brennan Vincello
2017-04-19 01:43:44 UTC
The new-build command you're running should be producing an s2i build, not a docker-type build, so i'm not even sure why you're getting a docker build here. (And s2i builds don't care about layer caching because there is only one layer). Can you provide the full output of your new-build invocation? In any case when you are doing a docker build, we must copy the secret file into your buildcontext directory each time (the same as we must do w/ your git source code) since the buildcontext directory is not persisted between runs, so i'm not surprised that docker is going to treat those as new/invalidated files for caching purposes and short of getting to the point where builds can be run based on persistent volumes, there's no simple fix i'm afraid. ok, I see you're getting a docker type build because your repo contains a dockerfile. But in anycase my comment above still applies, there's really no way for us to fix this, since the mounted secret file is always going to be considered newer than the cached docker layer. Hey Ben, as of Docker 1.8 timestamps don't matter for cache invalidation: https://github.com/moby/moby/pull/12031 When I mount an secret .npmrc as described in the issue I get the following files in my docker image. /app $ ls -al total 2092 drwxrwxr-x 11 911 root 4096 Jun 13 15:57 . drwxr-xr-x 20 root root 243 Jun 13 00:21 .. drwxrwxr-x 2 911 root 20 Jun 13 00:12 ..6986_13_06_00_12_52.761028215 lrwxrwxrwx 1 911 root 31 Jun 13 00:12 ..data -> ..6986_13_06_00_12_52.761028215 lrwxrwxrwx 1 911 root 13 Jun 13 00:12 .npmrc -> ..data/.npmrc .npmrc is a symlink to ..data/.nprmc which in turn is a symlink to ..6986_13_06_00_12_52.761028215/.npmrc. 6986_13_06_00_12_52.761028215 appears to be a timestamp and changes every time we build the image. This means that metadata for .npmrc is changing and the cache invalidation should happen. In conclusion, the cache invalidation is caused by how the secret is mounted and this should be fixed by redhat. This is not a problem with docker. Thanks for the details Lucas. The mechanism by which secrets are mounted into the pod is defined by kubernetes(w/ the symlink structure) and it's unlikely to be changed, i believe it's done that way to allow/ensure atomic updates to the mounted secret content. However the way the docker build strategy works on openshift, that file you found is first copied into a working directory which becomes the context for the docker build. So i'm not sure what metadata you're referring to, but ultimately the docker build is going to be run in a directory containing a file named ".npmrc" on every build. If docker is ignoring the file timestamp, then I don't know what else about that file would be invalidating the cache. |