Make build layers read only for subsequent buildpacks

[sambhav]

Signed-off-by: Sambhav Kothari [email protected]

Readable

Related RFC #163

[hone]

I think this a good idea, but it does add both complexity and encourages coupling. Another buildpack needs to know how to fetch or find the directory. This can be done via an env var like the android SDK example or just accidental like the Python one. We have the working dir + slices which is the current place that shared writing can happen. I think being able to show why we don't want to pollute this directory could go a long way. There is an inherit idea today that a layer created by a buildpack is "owned" by it and this changes that.

[sambhav]

Per the last RFC deep dive meeting, I have converted this RFC to only cover the "layerization" part. I will create a sibling RFC for "shared-layers" which should be implemented as an atomic change along with this RFC.

[jkutner]

I'm removing my approval for now, because I thought we were working toward a solution that had an escape hatch.

[jkutner]

Can a buildpack indicate that a layer should not be layerized until all buildpacks have run?

If a subsequent buildpack modified a layer from an existing buildpack, can we save that as a new layer? This may be inefficient overall, but it makes it much easy to develop buildpacks in some cases.

[jkutner]

I'm revisiting this RFC as I'm struggling to get pip to install packages outside of PYTHONHOME, while keeping pip as a distinct buildpack. Is it possible? Yes absolutely, but this puts a lot of burden on new buildpack authors who are used to working with these tools (pip, etc) the way they are meant to be used. By forcing layers to be read-only we are going against the grain.

[hone]

When deemed "ready", a team member will propose a "motion for final comment period (FCP)" along with a disposition of the outcome (merge, close, or postpone).

The proposed changes due to perf reasons are pretty drastic. This RFC seems to have stalled without a decision one way or another. I propose we "postpone" this and create an issue on lifecycle to try to at least warn users when this is happening. It may be expensive perf wise, but it maybe worth spiking and measure how much it would cost. Thoughts @ekcasey @natalieparellano ?

[buildpack-bot]

Maintainers,

As you review this RFC please queue up issues to be created using the following commands:

/queue-issue <repo> "<title>" [labels]...
/unqueue-issue <uid>

Issues

(none)

[hone]

This is blocked currently on this spike: buildpacks/lifecycle#703.

[hone]

Since @ekcasey is on leave, I'd like to reassign this. Do you mind if I assign you @natalieparellano?

[sambhav]

Coverting this to a draft while it is still blocked.

[natalieparellano]

The proposed changes due to perf reasons are pretty drastic. This RFC seems to have stalled without a decision one way or another. I propose we "postpone" this and create an issue on lifecycle to try to at least warn users when this is happening. It may be expensive perf wise, but it maybe worth spiking and measure how much it would cost. Thoughts @ekcasey @natalieparellano ?

@hone just to clarify, the spike is measuring the performance impact of notifying or failing if mod times change? Or something else?

[mboldt]

I ran a couple experiments for buildpacks/lifecycle#703. Detecting which buildpacks modify which layers using a file system watcher was pretty efficient (added ~0.5 seconds to a ~12-second build of Spring Petclinic REST with Paketo buildpacks). More details and results in the experiment repo.

So, it seems feasible for lifecycle to detect and report a buildpack changing another buildpack's layer.

On the broader topic, I've had some conversations with @yaelharel who is interested and has some good ideas to explore for read-only layers and change detection.

[yaelharel]

While @mboldt ran some experiments with a hash function and a file system watcher (as described in this issue), we talked about some ideas for this RFC:

• Hash - although the experiment that Mikey ran took too long, maybe it’s worth trying a different hash function.
• Git - if we would have Git on our file system, and everything is committed, we would be able to run git diff and see if anything was changed after each buildpacks run.
• Virtualization - use it to run the buildpacks in a way so they won’t have write access to the layers.
• Copy on write - use this mechanism for each buildpack run and then delete the changes so the actual layers won’t change.
• Search based on timestamps - record the timestamp before a buildpack starts running. At the end of the run, check the timestamp of the relevant directories, and if they changed, we can do a BFS/DFS search in order to find out what directories have changed. Probably it’s not a very good idea since buildpacks can modify the mtime information on files.

One tricky part is knowing ahead of time which buildpack should “own” a given layer. From a fresh build, it’s easy to see which buildpack creates a layer. But, with caching/restore, it’s a bit trickier as the layers already exist. We would need to track that somewhere but we think it’s possible to do so.

Another concern about some of the hard-stop methods is that, although layers should be read-only per spec, it is not enforced today, and so could break some buildpacks. If we don’t want to create a breaking change, we think that we can create some kind of a flag that will tell us whether we should only warn or error based on the version.

[mboldt]

One tricky part is knowing ahead of time which buildpack should “own” a given layer. From a fresh build, it’s easy to see which buildpack creates a layer. But, with caching/restore, it’s a bit trickier as the layers already exist. We would need to track that somewhere but we think it’s possible to do so.

This was my ignorance...the platform API does include the buildpack ID in the layer path, so this is not a problem as I first thought.