On 09/04/15 12:12, Martin Lucina wrote:
There are essentially three options with the UI:
1) try to abstract everything, but that will most likely fail, as
you note with the packet filter example
2) abstract nothing, and always require an rc-like script
3) do something in between, abstract the often-used bits like ip
address and require a full rc script for the more complex ones like
configuring a packet filter
Notably, 2 and 3 will require crunchgen/"exec" type of support.
"2" also requires some kind of "rc script intepreter" *inside* the image.
right
That would seem to imply either
a) porting a shell, if you want to re-use eg. existing pf configuration
scripts. This gets us into traditional OS-land which is something I'd like
to avoid. One of the things many people caught on in my rumprun talk was
"there is no shell".
b) using eg. Lua or similar small language with straightforward syscall
bindings. This would mean writing our own equivalents of the pf
configuration tools in it.
My gut feeling is that it doesn't need to be fancy, just take a list of
commands to run.
But, who knows, it might turn out into one of those things where you
start out simple with a strong conviction to do only the minimum and end
up reimplementing the wheel.
I'd stick with "1" for now, and see if we can come up with some
out-of-the-box thinking; after all there's no need to emulate traditional
UNIX configuration (shell scripts + files in /etc).
The problem with "1" alone is that how are you going to do firewalls,
routing, cryptographic block devices, ....
Just winging it won't work. Source: been there, tried that, ca. 2007-2010.
I can imagine built-in configuration management necessary for
something like docker when you can configure the guest in-band, and
want to preserve the configuration over application binary upgrades.
That does not apply for rumprun where the configuration always comes
out-of-band and is static after launch.
"static after launch" would seem to conflict with the script interpreter in
"2".
Why?
