Add spec changes for image extensions

[natalieparellano]

Supersedes #267

[natalieparellano]

This is still a bit rough... I'm going to add some comments to call out things that might be interesting for the reader. This branch includes commits from buildpack/0.8, which makes the diff harder to read, but the buildpack api changes more coherent. I'll rebase this branch once buildpack/0.8 is merged.

[natalieparellano]

This sentence (while "accurate", I think) doesn't make much sense... I am not sure how to improve it without re-working the entire section.

[BarDweller]

"During detection, order definitions MUST be resolved into individual buildpack implementations. If present, Image Extensions MAY provide an order definition. Buildpacks MUST provide an order definition."

Not sure if that covers the intent.. which itself kinda hints the original still has wiggle room.. (It's possible in my rephrasing to interpret that each extension would supply an order definition, or that there would be one for all extensions).

The original leaves bare the possibilty that an order defintiion for extensions is required, although the extensions themselves remain optional (as the binding of the 'if present' can be made to 'image extensions' rather than 'order definition').

[natalieparellano]

This almost certainly needs more changes but I am marking it ready for review in the interest of getting feedback.

[sclevine]

Can we stop using the term "buildpack implementation"? Or at least swap the word order to "implementation buildpack" if we can't think of a better term for a non-meta-buildpack? Meta-buildpacks are still implementations of buildpacks, so I think it's difficult to understand these sections.

This could be a separate PR, but I feel like adding image extensions makes this even more confusing.

Some name ideas:

• atomic buildpacks
• executable buildpacks
• concrete buildpacks

[BarDweller]

I like concrete buildpacks.. has a nice construction theme to it ;p

[natalieparellano]

Please see #300 - I went with "executable buildpack" because that seemed most natural according to the definition I used.

[sclevine]

Suggested change

	During detection, an order definition for image extensions (if present) and an order definition for buildpacks MUST be resolved into individual buildpack implementations.
	During detection, order definitions for image extensions and buildpacks MUST be resolved into a single order definition containing only atomic buildpacks.

[sclevine]

Suggested change

	Order definitions for image extensions MUST NOT contain nested orders. If an order definition for image extensions is present, it will be pre-pended to the order definition for buildpacks (as if the order definition for image extensions were an order buildpack).
	Order definitions for image extensions MUST NOT contain nested orders.
	If an order definition for image extensions is present, it MUST be prepended to the order definition for buildpacks before the resolution process occurs.

To make this more clear, I think we should define the following six terms early in the spec:

1. Order buildpack
2. Atomic buildpack
3. Order image extension (not currently allowed)
4. Atomic image extension
5. Order build module (currently only order buildpack)
6. Atomic build module (atomic buildpacks and image extensions)

The names are just suggestions.
Maybe it's easier to say that image extensions are buildpacks?

1. Normal order buildpack
2. Normal atomic buildpack
3. Image extension order bulidpack (not currently allowed)
4. Image extension atomic buildpack
5. Order buildpack (only normal buildpacks allowed)
6. Atomic buildpack (atomic normal and extension buildpacks)

[natalieparellano]

@sclevine what is a build module? What is the difference between an order build module and an atomic build module?

[natalieparellano]

Let's hash this out in https://github.com/buildpacks/spec/pull/300/files - we can rebase this PR when that one is merged.

[sambhav]

Curious why image extensions MUST be optional?

[natalieparellano]

@sclevine could you elaborate?

[sambhav]

How/where will we be enforcing this?

[natalieparellano]

The same way we enforce buildpacks not writing to other buildpacks' layers directory (wishful thinking) :)

This is something that we could add in theory, but it would to subject to the same concerns outlined in buildpacks/rfcs#155

[sambhav]

Why not?

[natalieparellano]

Linking to discussion here: https://github.com/buildpacks/rfcs/pull/173/files#r794629405

The concern is that we could end up switching to a base image that doesn't have buildpacks on it.

[BarDweller]

I would rather have this as a 'SHOULD' than a MUST.. it's doable, IF you really know what you are doing, and closing that door with a MUST might end up closing an escape hatch that someone might need =)

I've tried swapping build images in the PoC (and copying the /cnb folder from the previous image via multistage) and it is doable, but I hit odd issues executing the build step after the extension step, that I suspect were related to that switch.. I suspect with enough care, with certain constraints it could be done.. eg, if the image switched to was built as a stack image that includes the buildpacks content, etc, etc, etc.

[sambhav]

What will happen in case this label is set to true? What are the cases when an extension ran and the output image is still rebaseable?

One other thing I am unsure about is how we will uniquely identify a "family" of base images that can be rebased with one another.

I know we thought about replacing stack id with some other identifier that indicates the "family" of base images - how does that fit in here?

[sambhav]

The whole rebase picture with extensions is still unclear to me. It would be nice if we can have some actual examples of cases where/how this can work with platforms like pack or kpack.

[BarDweller]

I'm thinking / hoping that an extension can still set rebaseable=true, where it modifies the build image (say to install runtimes, tools to build etc) .. but limits the runtime changes to just using 'FROM' to switch to a different run image.. I think this would still qualify to be rebaseable, as future run images can still be swapped in.. provided they still contain the required dependencies that were met by the substituted run image. In theory this allows for the existence of a generic builder image that tailors itself to install runtimes/tools etc, working in conjunction with a set of run images to cover the most common scenarios.. and maybe, also in conjunction with a generic (non rebaseable) run image to cover the edge cases where the common image was insufficient.

[natalieparellano]

I wonder, in the case where a Dockerfile is applied to the run image, but all it does is switch the run image (using a FROM instruction):

• Should we publish a new "extended" run image (the <target-image> argument provided to the extender)
  • Opinion: no, that seems confusing
• Should we run genpkgs?
  • Opinion: no, but we should make an effort to locate an sbom for the new run image (see Allow platforms to provide run image sboms rfcs#211)

[natalieparellano]

Just to provide an update on this - I see this effort and the "run image SBOM" effort as sort of orthogonal at this point. The diagram below depicts what the path to implementation might look like:

We had discussed a phased implementation for Dockerfiles previously and this seems to be prudent given that we're still working out some issues with kaniko. As a next step, I could update this PR (or open a new one) to capture only the changes needed for the first phase (the green box in the diagram above).

[natalieparellano]

To expand on the conversation from 4/14 Working Group, the following (simpler) diagrams describe the extend / sbom flows for two phases of the implementation. cc @samj1912 @sclevine

First phase:

Final phase:

[natalieparellano]

After further discussion in 4/14 Office Hours, it seems that the simplest and best path forward for dealing with run image SBOMs is to make this the responsibility of the signer binary.

After the app image is exported, the signer will attempt to locate the run image SBOM on the registry; if an SBOM is not found, the signer will pull the run image in order to scan it - this will negatively impact performance, but can be avoided by:

• ensuring the run image has an SBOM in the first place (if you do care about SBOMs)
• skipping this step entirely (if you don't care about SBOMs)

This will also simplify the lifecycle implementation. We can drop the notion of run image SBOM and genpkgs from this effort as buildpacks/rfcs#195 will now capture these concerns.

[natalieparellano]

Closing in favor for #307 and #308. For posterity, here is a revised implementation plan following some discussion (and removing the run image SBOM dependency):