Re: configuration
- From: Antti Kantee <pooka@xxxxxx>
- To: rumpkernel-users@xxxxxxxxxxxxx
- Date: Wed, 01 Apr 2015 11:37:44 +0000
On 01/04/15 11:07, Justin Cormack wrote:
The idea was that the rumprun utility would create the configuration which
would then be interpreted at runtime by the rumpconfig module, like what
mato already implemented for Xen. I don't think deciding the actual
mechanism matters that much, since it can even be changed without the user
noticing. The user interface provided by the rumprun utility still needs
work and discussion and review.
I think it does matter in terms of configuration management. If the
binary is being modified you may want to store the new version
somewhere, or generate it before running it and run the preconfigured
version. Deleting unused config files and so on, whether from xenstore
or the file system is also necessary.
In terms of the utility, the obvious to me missing stuff is:
1. set mac address
2. inet6,auto config
3. inet6,static config. May need multiple addresses, and I guess auto
and static together are valid.
4. setting name servers
5. is the assumption that the "environment variable" mechanism is used
to set custom info eg crypto keys?
6. setting fqdn, at the moment there is a name field, but we dont
sethostname/setdomainname on host, although rump will make up a
hostname.
7. support for mounts of other devices. The main thing missing here is
to specify the fs type, rather than have it autodetected, eg for pci
device mounts, or /proc or /tmpfs. Some way to specify netbsd per
filesystem mount options (eg tmpfs size) would be useful eventually.
You still need more generic mechanisms, which is why I think some
generic discussion is useful. eg if you want to configure a packet
filter you are not going to do it from command line options.
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.
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. I guess
that's why the current version of rumprun/config only does "1". I am
not sure which is best. "2" seems attractive, though not sure if it's a
usability improvement over 1+some examples. (The thing I really hated
about Apache was that there was a 10000-line example configuration file
which had some important stuff hidden in the middle, and you were
essentially forced to go through it even if you just wanted to serve a
few files on port 80. I'd like to now repeat that usability crisis here)
"Store configuration" seems like a separate problem. I don't think we
need to reinvent shell scripts for the rumprun tool. It's probably even
counterproductive. Either you're a very casual user and can type the
commands and up-arrow+edit them to iterate, or you're a pro sysadmin (or
devops or whatever they're called these days), and you'd like to use the
tools you're already familiar with.
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.
Other related posts:
