-
Notifications
You must be signed in to change notification settings - Fork 69
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
Platform Spec is ambiguous about usage of extender
#389
Comments
related comment: buildpacks/lifecycle#1155 (comment) |
@natalieparellano Thanks for the explanation. That helps to understand the background. But this causes 2 questions:
What does optional mean in this context? So calling the |
Maybe, and in fact we have talked about it in the past. This would require some discussion. I think the main reasons not to do it would be security (potentially exposing registry credentials to buildpack/extension code) and complexity.
The quoted spec line should probably read something like:
Right, you can only use the creator if there are no extensions. Potentially, we can make this "if there are no extensions that extend the runtime base image" i.e., extending the build-time base image should be possible (we just didn't implement it yet). The
Which is true, so in that sense the creator is spec compliant. |
The most interesting question imho is that it apparently still works - but shouldn't, if I understand your explanation correctly. |
I think it would depend on the differences between the build and run images - see for example buildpacks/lifecycle#1285 It MAY work, but it is not guaranteed to work 😅 |
We digged a little deeper to better understand what is going on. So it kind of worked in our case since the packages of the And also we realized starting the So we came to the conclusion that we won't be able to support extensions in our platform since we are already running in a container. @natalieparellano What are the future plans for extensions? As long as there are optional, we are still spec conform. Will extension support be mandatory for platforms in the future? |
@c0d1ngm0nk3y this probably warrants further discussion, but I think there is a way around this, albeit one that requires further work. Even if extensions are never "required", it could lead to a bifurcation of the ecosystem if some builders require extensions for order resolution to succeed. Ultimately, extensions are a way to satisfy build plan In theory, one could write an extension that introspects the packages on the run image during detect and outputs
The missing link here is that base images today have no way of declaring the requirements that they satisfy, ever since we got rid of mixins. Mixins had their own problems (the stack ID and coupling of build & run images together introduced a bunch of unnecessary complication) but we probably need some way for base images to statically declare the packages they contain, so the lifecycle can read that off of the run image and provide it to extensions during detect. All that said, I wonder how many folks are planning to use run image extension? Most of the use cases I have heard involve some combination of build image extension and run image switching. It might be worth conducting a survey of our major buildpack providers to find out what is planned. Perhaps we could do away with run image extension entirely (or make it a very limited special case) and save ourselves a bunch of trouble. |
I haven't yet used it for anything, but I would like to.
This works nicely for problems where you have a limited set of things to switch between in the run image, like say three different Java major version branches. There are cases, for example, PHP extensions that require C-shared libraries to run, where there are too many permutations. Using a buildpack extension to dynamically add those at runtime allows you to be more fine-grained about what gets pulled into the run image. Don't need PHP extension XYZ, ok we don't install those packages. Need PHP extension ABC, ok we'll install its required shared libraries. You could in theory do this with runtime image switching, but it would be a nightmare of different combinations and in practice, I don't think you'd ever get beyond having a few different extension bundles. |
Perhaps an SBOM in one of the standardized formats supported by the buildpack? We could error if we cannot find an SBOM for the run image (we could look in the registry using tag-based discover, etc or the platform could provide it) |
Mainly, I see a case for statically optimised run images, as in knowing that Java has less native dependencies that let's say the Node engine, there could be different run images per language / runtime. I could see the need to dynamically optimise run images like @dmikusa mentions, which would right now not be possible with our Piper/Jenkins based platform. Luckily, I haven't seen the need yet for Java, Node or Python - but if this comes up we will have a problem indeed. Independently, a declarative way for run images to participate as a provider in the build plan definitely makes sense and I like the idea to use a standard format like the sbom variants that are anyway already supported in the CNV ecosystem. |
We want to adapt our platform to make use of extensions, but the usage of the
extender
is not that clear.In addition with this comment, it seems like the
extender
must be called from thebuild
image when called with--build
and from therun
image when called with--run
. But theeither or both
in the spec is a bit confusing.extender (run)
in the context of therun
image? Bothdetect
andgenerate
are already executed and "only" executingkaniko
is still missing and the image should not make any difference there, right?Background of this question is that it would complicate things quite a bit, e.g.:
creator
, see issueThe usage of the
extender
is not clearly specified, imho.extender (build)
MUST be called regardless of any extension present since it includes thebuild
extender (run)
MUST NOT be called if there is no run extension detected. At least judging by the reference implementation. Wouldn't it be easier if theextender (run)
can always be called and might do nothing?The text was updated successfully, but these errors were encountered: