search

princeton-sns / firecracker-tools

5 stars 5 forks source link

Enable separate block device for application code #1

Closed alevy closed 5 years ago

alevy commented 5 years ago

Allows a Firerunner user to specify a separate block device containing their application code, in addition to the root file system.

Both rootfs and appfs are exposed as read-only block devices

LedgeDash commented 5 years ago

I assume an appfs can just be an ext4 file just like rootfs? What's the path to appfs on a VM?

tan-yue commented 5 years ago

I assume an appfs can just be an ext4 file just like rootfs? What's the path to appfs on a VM?

Isn't the path the mountpoint you choose to mount the device? The appfs device still gets inserted before kernel boots but mounted later. During bootup, kernel allocates memory for the device, turns the device into a usable state, and creates a node under /dev tmpfs representing the device.

alevy commented 5 years ago

@LedgeDash Yes, it's any valid linux file system. Next PR will be scripts for generating a rootfs which will have all the details implemented. The plan is for the following:

rootfs has all the non-app-specific binaries and configuration, so Python/Node, OpenRC, and an OpenRC script that's called on boot (under /usr/bin/somethingorother) which is responsible for mounting the appfs device and invoking the function.

This script currently (i.e., in my uncommitted working directory) mounts appfs under /src and executes /srv/workload.sh (we may want to change this to /opt and /opt/bootstrap to match Lambda's convention).

The appfs should contain a workload.sh that looks something like:

#!/usr/bin/env python2

print("Hello World")
# Bootstrap code to run the function that in this directory
alevy commented 5 years ago

and @tan-yue you're right. Basically how the VM actually uses the appfs is up to the VM, firerunner doesn't dictate that at all, except that it is (currently) read-only.