All,
We need to nail down the semantics and the broad design of "ilbadm export"
and "ilbadm import" (note, this diverges from the spec as it's currently
posted, where we still talk about import-rules etc. This has been simplified).
In addition, there's what we have come to call "persistent configuration",
which is conceptually an extension of ilbd, basically a copy of ildb's
running configuration that persists across start/stop of ilbd (and reboot
of the server). (this has nothing to do with "session persistence", btw)
We have been investigating how closely these are related and what impact
this has; here's some points that we seek understanding and your input on:
* import/export: the initial requirement was to have a means to take the
current configuration of the load balancer ("ilbadm export <file>"),
transport it to another machine by whatever means and re-apply ("ilbadm
import <file>") it there.
Q1: Would people agree that this requirement makes sense?
Q1a: if yes, would you agree that the format we use here is of secondary
concern, ie. private?
Since we already have a parser in place for the CLI, it was suggested to
use that format for import/export (initially, anyway) to avoid having to
duplicate effort.
Q1b: does the above cause concern for anyone?
* persistent config: this was initially planned to be completely invisible
to users/admins, and exclusively maintained by ilbd. (As I understood it,)
this configuration file would be updated with every change the admin made
via ilbadm that was not explicitly designated temporary. Whenever ilbd
starts, it was supposed to clear all rules from the kernel (in case it, the
daemon, had died unexpectedly), re-read the persistent config and apply all
that to the kernel (ie all rules).
There is also discussion of a different usage model, namely, requiring
explicit admin action ("commit") to cause the running configuration to be
saved in the persistent config file. (There seems to be precedent for that
in the industry, but I couldn't find a reference right now)
There are tradeoffs for both models.
Q2: which of the above models (explicit commit vs implicit update) do you
think is more appropriate for us?
The argument that "we already have a parser for CLI" also seems attractive
here, so we're toying with the idea of using the same syntax we use for
import/export for persistent config as well; since SMF handles ilbd
restart, it would be easy to add an invocation of "ilbadm read-config" (or
sth. to indicate that persistent config is meant) to the service's start
method.
Q3: since persistent configuration is viewed as a private component of the
ilb framework, is it be acceptable from a privilege/authorisation POV to
expose any interaction with it via ilbadm?
If we went with "commit" model outlined above, a suitable subcommand could
be added to ilbadm, which would presumably perform the actual update to the
persistent config file (in line with the "we already have ..." argument).
This would have maybe even more severe implications than Q3 indicates, as
ilbadm would be *writing* persistent config.
Q4: would this cause security considerations?
TIA for your (timely ;-) thoughts.
Michael for the ilb development team
--
Michael Schuster http://blogs.sun.com/recursion
Recursion, n.: see 'Recursion'
