Build Observability via OpenTelemetry Traces #299
Conversation
|
Maintainers, As you review this RFC please queue up issues to be created using the following commands: Issues(none) |
joshwlewis
force-pushed
the
build-observability
branch
from
9bea68a
to
b327ca9
Compare
Signed-off-by: Josh W Lewis <josh.lewis@salesforce.com>
joshwlewis
force-pushed
the
build-observability
branch
from
b327ca9
to
e34a900
Compare
joshwlewis
changed the title
joshwlewis
changed the title
Co-authored-by: Natalie Arellano <narellano@vmware.com> Signed-off-by: Josh W Lewis <josh.w.lewis@gmail.com>
| ### Access | ||
|
|
||
| The telemetry files should be readable so that they may be analyzed by | ||
| the user and/or platform. However, they should be write protected |
There was a problem hiding this comment.
How will we accomplish this if buildpacks all run as the same user?
There was a problem hiding this comment.
During build, each buildpack runs synchronously, so we could prep the files/permissions prior to bin/build, so that each buildpack can only write to the expected files.
During detect, many buildpacks will be running at the same time, and all under the same user. I can't think of a way to do block one buildpack from writing to another buildpack's detect telemetry.
To be fair, buildpacks can write to other buildpacks' /layers today. So maybe this section is a little overzealous.
Maybe instead of blocking writes, we say something about the intent - buildpacks shall write only to their own telemetry files.
text/0000-build-observability.md
Outdated
| 2) This functionality emits telemetry data only to the build file system. For | ||
| `pack` users, the telemetry files are stored in docker volumes on the local | ||
| machine. Neither `pack` nor `lifecycle` will "phone home" with telemety data. | ||
| 3) Neither `pack` nor `lifecycle` collect user-identifiable data (no emails, |
There was a problem hiding this comment.
Should image/registry names be considered sensitive?
There was a problem hiding this comment.
Hmm - tough question. Yeah, I suppose some folks would consider the resulting image name/registry sensitive. I'll update.
text/0000-build-observability.md
Outdated
| - Does `lifecycle` emit files in other places that should be matched? | ||
|
|
||
| - What file paths should be used for buildpack telemetry? | ||
| - `/layers` paths are not availble during detect, but `detect` tracing is |
There was a problem hiding this comment.
Actually /layers is available during detect, I think it is so we can write /layers/group.toml
Edit: that is from the platform perspective ^^; we would have to think about how to expose a "buildpack layers dir" to buildpacks during detect; the directory structure (/layers/buildpack-id) from the build phase might not work because we assume that only ONE version of a single buildpack-id can detect, whereas multiple versions might be running in parallel during detect.
There was a problem hiding this comment.
I've updated the location to /layers/#{buildpack-id}.jsonl. That shouldn't require /layers/buildpack-id to exist.
Given multiple versions of a buildpack could be running simultaneously during detect, maybe the version should be included in the filename to prevent multiple buildpacks from writing to the same file simultaneously?
|
@joshwlewis can you DCO those last commits (and maybe squash em) |
This RFC introduces a solution to build observability via OpenTelemetry Traces and the OpenTelemetry File Export format.
Readable