-
Notifications
You must be signed in to change notification settings - Fork 201
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
Implement Build Providers as Plugins #2125
Comments
Moving discussion to mailing list. Will reopen if this gains traction |
Thanks for the proposal, @richbai90! I'm reopening because we just need a heads up of proposals sent to the mailing list (so people know that it exists). The discussion doesn't have to happen there though. |
Right now we have 2 components in Porter that aren't plugins but could become plugins if needed:
When you say "build provider" I'm guessing that you actually are interested in making the runtime drivers pluggable since the issues you linked to are mostly interested in changing how much access the system that the porter client is running on. Runtime drivers are actually a CNAB concept, and are not implemented in Porter. You can find the implementations of the above runtime drivers here in the cnab-go library: https://github.com/cnabio/cnab-go/tree/main/driver If you wanted to try prototyping Porter to support different implementations, I'd recommend that you point porter at a fork of the cnab-go library and tweak https://github.com/getporter/porter/blob/release/v1/pkg/cnab/drivers/drivers.go (work off of the release/v1 branch) so that Porter knows how to select your new driver. I think you could get pretty far with minimal changes to Porter and without having to try to change Porter to switch from "drivers to plugins" which would be a bunch of extra work when all you are interested in is proving out a new type of driver. I'm down for making either build or runtime drivers pluggable if that's what ends up making sense. In the meantime, I am really interested in seeing how you expose the host to to the bundle through the new driver. As you have seen, I've been a bit stuck on what's a good way to do while working within the confines of the CNAB spec. 😀 If we can make it work with the current CNAB spec that's best, but at times Porter does make changes with the intention of circling back and updating the CNAB spec to match after we've vetted a feature (like we are doing with dependencies). I'm happy to help answer questions or bounce ideas back and forth as you work on a new driver! |
That sounds great, I'll give that a shot. I still think making something pluggable makes a lot of sense long term for both build drivers and runtime drivers. You already mentioned supporting Podman as a build driver, and I'm sure there are other tools that might make sense in various use cases. Allowing individuals and teams to support their own use cases and benefit the community at the same time seems to fit nicely into the ethos of this project. |
@carolynvs Can you explain extensions as they relate to drivers? I've read the spec, and understand that extensions are a means of extending the underlying json bundle with custom metadata that may or may not be required to successfully perform an action on the bundle. The confusing part to me is that in the case of Docker for instance, Docker is a build driver, runtime driver, and mixin. The Docker extension permits the setting of the privileged flag, but this is required only when using the Docker mixin. Notwithstanding, the extension is declared in the porter source under One other thing I'm trying to figure out, how is a driver registered as a runtime or build driver? I see in the porter source that the docker driver is registered with buildx in |
Yup, I'm fine with making them plugins eventually. In the meantime though I'm suggesting changing the driver so that you can prototype the new features without also having to take on making the drivers plugin friendly. 👍 |
Upon further examination I think I've answered my own questions. Please let me know if I'm off track
I mistook the path, it's actually under
It's not. A driver implements a simple interface, |
I'm not sure what you mean by that? The docker and k8s CNAB drivers have a simple interface like you pointed out, and there isn't any way to run them independently from Porter. Porter handles waves hands everything else that sets up getting to the point where we can ask the CNAB driver to execute a bundle. 😀
Porter's install command (and the others that run a bundle) have a --driver flag that eventually is handled in the cnab package, where porter selects a CNAB driver to use to execute the bundle. https://github.com/getporter/porter/blob/release/v1/pkg/cnab/drivers/drivers.go |
That answers my question. Basically how porter interfaces with the CNAB package. I apologize for not being on top of this issue, I had to tackle another more pressing concern, but I'm back to this. Thank you for leaving it open. |
I'm happy to leave it open as it's a great suggestion. No need to apologize for only engaging when you have time, that's pretty much the expectation for all of us. If you have any more questions, just let me know. 👍 |
I have a working implementation in PR #2167. This case was pretty easy since the the go-cnab api exposes all the options available to the docker go package, so I didn't need to make any changes to the go-cnab library. It doesn't make drivers pluggable, but for a near term solution it should solve most of the needs. The best part about it is that on its own it changes very little because there are no Mixins that take advantage of the options. It does open a world of capabilities to Mixin developers that would benefit from these sorts of options. |
What design is being proposed?
Move build provider functionality to plugin architecture
Additional Context
There are a few questions open now (#2097 #1823 #1665 #1366 ...) about configuring various components of the build container that porter runs in. These issues have various work arounds or have been put on hold pending further review. Security concerns, implementation details, and other questions stall these proposals. I suggest in order to allow the core team to focus their energy on the core product, allowing build providers to be created via plugins. I see the following benefits in this:
Risks/Concerns
Allowing anyone to create a build provider raises possibilities of security risks, as well as potential tech debt, and maintenance issues. That said, it's not any more risky than the current plugin functionality, and I assume that the core team will adopt the docker provider as an officially maintained plugin.
What other approaches were considered?
Many work-arounds, hacks, and other fragile methods
Implementation details
I have done my best to replicate the existing plugin architecture for build providers at https://github.com/richbai90/porter-advanced-build-plugins It compiles, but I'm not a go expert (started learning for this project) so I'm sure it could be improved.
Checklist
The text was updated successfully, but these errors were encountered: