You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I write some complex function code and run it in Fission, cannot debug my function locally.
Sometimes my function should use a special runtime framework, MUST build a special runtime for my function.
Some users really donot want Fission to have any restrictions on code and framework.
Now the builder and runtime Dockerfile has a lot of code snippets from the official or otherwise Dockerfile. It's so hard to upgrade them.
Proposed solution
Previously, functions were loaded as plugins in fission. We can completely load functions as child processes, and then the function can be decoupled from fission. We only need to complete a program similar to systemd to accept the specialize API. The environment we have already prepared can still be used. Some users really don't want Fission to have any restrictions on code and framework.
We call this application monitor. monitor accepts the specialize API, and specializes the container, at last startup the function.
running directory
single file function should locate in /fission/ directory.
function is a directory, all of the directory files should layout in /fission/.
The monitor runs the function, and /fission/ as working director.
metrics
monitor can expose the healthz and metric if needed.
env
monitor loads all of the env value from specialize API, start the function with the envs.
command
monitor loads the function start command, start function with this command.
arguments
Sometimes functions need specific arguments to start.
logs
monitor runs the function as a subprocess and collects the stdout and stderr.
entrypoint
entrypoint is useless.
runtime
We build all of the runtime docker images with language's official image and add new layer for the monitor, and the command is monitor.
The text was updated successfully, but these errors were encountered:
Hey @tosone ! Thanks for the proposal. I am wondering if this PR serves a similar goal : fission/fission#1681 .
There's a good ecosystem around building containers. So running them directly instead of introducing our own layer feels redundant. What are thoughts about it?
Problem
Proposed solution
Previously, functions were loaded as plugins in fission. We can completely load functions as child processes, and then the function can be decoupled from fission. We only need to complete a program similar to
systemd
to accept the specialize API. The environment we have already prepared can still be used. Some users really don't want Fission to have any restrictions on code and framework.We call this application
monitor
.monitor
accepts thespecialize API
, and specializes the container, at last startup the function.running directory
/fission/
directory./fission/
.The
monitor
runs the function, and/fission/
as working director.metrics
monitor
can expose thehealthz
andmetric
if needed.env
monitor
loads all of the env value fromspecialize API
, start the function with the envs.command
monitor
loads the function start command, start function with this command.arguments
Sometimes functions need specific arguments to start.
logs
monitor
runs the function as a subprocess and collects the stdout and stderr.entrypoint
entrypoint
is useless.runtime
We build all of the runtime docker images with language's official image and add new layer for the
monitor
, and the command ismonitor
.The text was updated successfully, but these errors were encountered: