On Wednesday, 01.04.2015 at 11:37, Antti Kantee wrote: > None of those involve the mechanism for *passing the configuration > from the tool to the guest*. That's an implementation detail. Yes, > the switches you list are missing (or at least some of them, didn't > check all), and we need to figure out the UI for how to pass the > info.
Agreed. > 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. 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. > I guess that's why the current version of rumprun/config only does > "1". Yes. 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). > 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".
