[RFC #0096] Remove Stacks and Mixins

[jromero]

RFC #0096 - Remove Stacks & Mixins

Spec:

• [RFC #0096] Remove stacks from platform spec spec#258
• [RFC #0096] Replace stacks with targets in buildpack api spec#260
• Released in Platform 0.12, Buildpack 0.10

Lifecycle:

• [RFC #0096] Analyzer should write new run image metadata to analyzed.toml lifecycle#742
• [RFC #0096] Lifecycle should provide CNB_TARGET_ID in buildpack env lifecycle#743
• [RFC #0096] Rebaser should validate target data and update labels lifecycle#744
• [RFC #0096] Lifecycle should detect Target OS from etc/os-release lifecycle#1033
• Released in lifecycle 0.17

Libcnb:

• TBD

Pack:

• [RFC #0096] Remove 'stacks' from builder.toml pack#1303
• [RFC #0096] validate buildpacks' targets to based images pack#1301
• [RFC #0096] Add --force to rebase operation pack#1302
• Released in pack 0.30

Samples:

• [RFC #0096] Remove stacks and replace them with base images samples#111
• Released in <placeholder>

Documentation:

• [RFC #0096] Remove stacks and replace them with base images docs#422
• Released in <placeholder>

Enhancements:

• Provide a way to specify desired platform when creating packages and builders pack#1459 (mentorship project)
• [RFC #0096] Define base image in distribution spec spec#259
• Distribution Spec (v3) - Build Image Artifact format spec#266
• Request: Stack Removal Migration Plan #221 - RFC for moving base image author requirements from platform spec to distribution spec
• Released in Distribution TBD

[jromero]

@jabrown85 IIRC, you were more or less pushing these efforts forward so I assigned it to you. Please let me know if that's incorrect.

[jkutner]

Jesse will probably be out of pocket for a while. If anyone else is interested in moving these forward, please help :)

[ekcasey]

The high levels concerns I have here are around:

1. Migration Path
2. API orthogonality
3. Platform/Builder/Stack/Lifecycle compatibility matrix

Here are the outstanding questions I think we need answers to:

1. There are some existing places where the lifecycle reads run-image labels (example: lifecycle reads io.buildpacks.stack.id during rebase) and newly proposed instances (e.g. analyzer reads io.builldpacks.id). If we define these labels in the distribution API instead of the platform API:
   a) Must the lifecycle express compatibility with various Distribution APIs, in addition to platform and buildpack APIs?
   b) If not, why not? Should the platform provide consistently formatted inputs instead?

2. We are requiring platform API environment variable inputs like CNB_LAYERS_DIR or the schema of order.toml to be set on builder images, but what happens when the platform API changes, for example renaming one of these variables?
   a) Can an older builder still be used with this new platform API? If so, how does that work (e.g. does the platform handle the translation?)?
   b) Can a builder implementing a newer distribution API still be used with older platforms? If so, how does that work? If no, must platforms express which distributions APIs they support?

3. Can I rebase an app image built with an older stack onto a newer stack that only specifies the newer limited set of metadata (i'm leaning yes)? Does this require --force (less sure about this one)? What about downgrades to older stack APIs?

4. Can I run a newer buildpack that only specifies targets on an older stack (with a stack ID and mixins)? If so, who sets the new required env variables like CNB_TARGET_DISTRO_NAME (lifecycle could probably do this successfully for linux given /etc/os-release and assuming stack ID -> target ID)? If not, can the buildpack specify both stack and targets to achieve compatibility?

5. Can I make a distribution 0.3 builder from an older stack?

6. Can I combine buildpacks implementing different distribution APIs onto a builder? What is its version? In that case does I am assuming the platform creating the builder handles any migration (e.g. labels)?

7. As a stack author what exactly do I need to do to support both old and new buildpacks? old and new platforms? Do I need to indicate somehow that I intend to provide backwards compatibility?

[schneems]

Migration Path

I'm curious about this as well. We use stack ID for layer invalidation for layers that may contain natively compiled code (like bundle install can install C extensions that depend on the current system.

[jabrown85]

Migration Path

I'm curious about this as well. We use stack ID for layer invalidation for layers that may contain natively compiled code (like bundle install can install C extensions that depend on the current system.

There are new values that buildpacks will have available to help determine layer compatibility. For your case, I think your buildpacks go from checking heroku-22 to making sure CNB_TARGET_DISTRO_NAME and friends are all the same before using the cache.

Does that help answer your question @schneems ?