Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC #0096] Remove Stacks and Mixins #219

Open
18 of 21 tasks
jromero opened this issue May 18, 2022 · 5 comments
Open
18 of 21 tasks

[RFC #0096] Remove Stacks and Mixins #219

jromero opened this issue May 18, 2022 · 5 comments

Comments

@jromero
Copy link
Member

jromero commented May 18, 2022

RFC #0096 - Remove Stacks & Mixins

Spec:

Lifecycle:

Libcnb:

  • TBD

Pack:

Samples:

Documentation:

Enhancements:

@jromero
Copy link
Member Author

jromero commented May 18, 2022

@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
Copy link
Member

jkutner commented May 20, 2022

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

@ekcasey
Copy link
Member

ekcasey commented Jun 6, 2022

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?

@natalieparellano natalieparellano changed the title [RFC #0096] Remove Stacks and Mixins Spec PRs for platform and buildpack facing changes Nov 15, 2022
@natalieparellano natalieparellano changed the title Spec PRs for platform and buildpack facing changes [RFC #0096] Remove Stacks and Mixins Nov 15, 2022
@natalieparellano natalieparellano self-assigned this Dec 6, 2022
@schneems
Copy link

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
Copy link
Contributor

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants