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

feature(spin): Support for custom Spin triggers #193

Open
0xE282B0 opened this issue Dec 5, 2023 · 1 comment
Open

feature(spin): Support for custom Spin triggers #193

0xE282B0 opened this issue Dec 5, 2023 · 1 comment

Comments

@0xE282B0
Copy link
Contributor

0xE282B0 commented Dec 5, 2023

Spin has a plugin system that allows Spin apps to be triggered by user-defined events. To add a trigger to the spin-shim it needs to be added to the source code e.g. #192

Since it is not desirable to add all possible triggers to the shim, it would be nice to use the existing plugin system to load the plugins at runtime. Trigger plugins are standalone binary CLI programs that take the path of a locked spin application as a parameter.

I see two options:

Option 1: Mount Spin plugins folder from Host

image

With this approach, the plugins can be conveniently managed on the host using the spin cli tool, and only the mount needs to be added to the shim. However, it is a piece of "dark magic" for the user, and the plugins still need to be distributed across all nodes of a Kubernetes cluster (in the case of K8s).

Option 2: Make the shim aware of plugins and fetch them during container startup

image

This option fetches the plugin during container creation, what makes startup a bit slower but does not need the plugins being installed on the node.

Thoughts

  • In the end, a trigger plugin is just another thing which has a lifecycle that needs to be managed. I see this as outside the scope of the shim.
  • Locating and executing a trigger can be done similar to the trigger_command_for_resolved_app_source function in the spin CLI https://github.com/fermyon/spin/blob/main/src/commands/up.rs#L152-L153
  • Executing binaries is a potential attack vector we should be aware of. (maybe this feature can be made optional)
@Mossaka
Copy link
Member

Mossaka commented Jan 5, 2024

I can see this as a very useful addition to the spin shim. Thanks for brining this up @0xE282B0 !

I am personally preferring the second approach where the spin shim is aware of the plugins because this seems more ops friendly.

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

No branches or pull requests

2 participants