Conversation
Signed-off-by: Natalie Arellano <narellano@vmware.com>
|
Maintainers, As you review this RFC please queue up issues to be created using the following commands: Issues(none) |
Signed-off-by: Natalie Arellano <narellano@vmware.com>
text/0000-extract-extender.md
Outdated
| -rw-r--r-- 0:0 560 B └── lifecycle.toml | ||
| ``` | ||
|
|
||
| * When creating builders, pack will inspect the lifecycle version provided and pull the extender with the same version from the GitHub releases page. |
There was a problem hiding this comment.
Actually, this is just as non-declarative as looking for "sibling" artifacts, and would prevent builder creation in offline environments. We should probably go the uri route...
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
text/0000-extract-extender.md
Outdated
| * Using the builder image (as before) when doing build image extension | ||
| * Using the run image + extender binary from the _extender_ image (this is different) when doing run image extension | ||
| * See [here](https://github.com/buildpacks/pack/blob/a1edf2e9e3837c2e9eeca019b97c28896b40f778/pkg/client/build.go#L662) for how this is working today in pack | ||
| * Other platforms would need to make a similar change in order to upgrade to a newer lifecycle version IF they are looking in the lifecycle image for the extender binary (vs the builder) |
There was a problem hiding this comment.
Do such platforms exist? Anecdotally the support requests I've seen re: run image extension (vs switching) were using pack build
|
If we had the option to remove extensions, I would remove them completely. Anyway, we tried some experiments with buildah to programmatically build an image in https://github.tools.sap/I549554/buildah-rootless/, which might be helpful during evaluation. |
* Removed the separate delivery mechanism for the extender * Added the optional "slim" version concept for future consideration * Simplified the migration path Signed-off-by: Natalie Arellano <natalie.p.arellano@gmail.com>
|
I am happy to help on this @natalieparellano if the lifecycle gonna use buildkit |
|
|
||
| ## 2. Providing an alternative implementation of the extender | ||
|
|
||
| * We will need to explore alternatives to kaniko for Dockerfile application. |
There was a problem hiding this comment.
Does the reference from @sambhav change our approach here? If Kaniko is going to be maintained by Chainguard, I will suggest changing our references in go.mod to that fork, which will unblock us for security updates.
We can think on providing an alternative without the urgency we have now. right?
8 participants
Readable