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

Tiny runtime for fission #397

Open
tosone opened this issue Feb 22, 2021 · 2 comments
Open

Tiny runtime for fission #397

tosone opened this issue Feb 22, 2021 · 2 comments

Comments

@tosone
Copy link
Contributor

tosone commented Feb 22, 2021

Problem

  • I want to write my function freely.
  • 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.

@RealHarshThakur
Copy link
Member

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?

@tosone
Copy link
Contributor Author

tosone commented Feb 23, 2021

The goal is similar, but the startup time is my concern. I like the fission cold-start.

@soharab-ic soharab-ic transferred this issue from fission/fission Sep 18, 2024
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