State management
State management should be the way the state data is persisted.
Types of states
States include (in this order):
- fs store
- running boxes
- stopped boxes
- moksha configuration
- logs
State features
Each state/store should have the following features:
- easily open and initialize the state
- easily retrieve and set data
- give the user a way to refer to the data (i.e: urls, paths, etc)
- provide some kind of backwards compatibility (i.e: once a store is added, the old store doesn't break moksha; and it will be initialized by default, if necessary)
Configuration
Configuration - what it means
Configuration refers to the following:
- moskha software configuration
- box configurations
Moksha conf
Features:
- default path
- hostname
- API version
- configured defaults (i.e: KVM options, etc)
Box conf
Features:
- multiple paths to find configurations in (possibly including env vars)
- each box configuration will be named a Manifest or a Library
- each manifest will have to be: inheritable, and optionally inherited
- should provide imports
- should provide a way for the user to customize their bootstrapping process,i.e:
example library
module my_library
fn (mut b Box) cap_unset(...) {...}
example manifest
manifest := new_manifest(...)
manifest.name("my manifest")
manifest.version("0.1")
box := create_box(manifest, ...)
box.add_seccomp(moksha_defaults.default_seccomp)
box.add_pre_fork( fn (b Box) ? {
b.cap_unset(Moskha.CAP_SYS_ADMIN)
})
box.add_inside( fn (b Box) ? {
b.cmd("mount -o remount,ro /")
#include <unistd.h>
uid := C.getuid()
if uid == 0 { ... }
})
// global
moksha_complete = Manifest{manifest.complete() }
The templating language showcased here would be Vlang - which has the upside of interoping with C seamlessly, being comfortable, and the downside of requiring a compiler.
Should the user just use a plain templating language? But then scripting it would be harder. Should the user be able to write code in the Manifest? That seems like something that can go bad from many perspectives. Should the user be able to insert .sos? That seems to be Kubernetes' preferred way, but imo is a very bad security practice.
Vlang on the other hand could prove useful: the compilation could be done in memory somehow, using V's native compiler, and afaik it strips down unnecessary libc dependencies. To harden the V compiler would also mean using musl, for example.
I guess, if libc proves to be not needed, V could or could not be fine. If libc is needed by the user, then V + TCC I guess would be the only solution.