I found this issue in the caselog
> seb-0 Assuming that the future of network configuration is
> NWAM-only, and that the existing mess that comprises
> network/physical:default will eventually go away, are there
> design, architectural, or even scoping constraints that this
> project imposes on other current and future project? For
> example, I know of a current larval project planning on
> replacing ifconfig and /etc/hostname* files as an IP interface
> configuration tool. If nwamcfg and its GUI are the future,
> should that project stop what it's doing?
I don't think that project needs to stop what it is doing, but some care
is needed around the fixed configuration where there is overlap.
One of the key things we need and that NWAM is delivering is the dynamic
dependencies that feed into the configuration i.e., the ability to
specify a matching criteria for a location and which configuration
should apply in that location.
Separately we need to make fixed configurations easier to handle by
building an infrastructure which can replace ifconfig and /etc/hostname*
so that we can have a simple way to setup persistent fixed IP configuration.
As part of doing the latter piece we definitely need to think about the
intersection with nwamcfg for the case of a single, fixed location. But
I don't think that would be too complex.
One possibility is that NWAM and nwamcfg grows the ability to specify
the full IP feature set (link aggregations, VLANs, IPMP groups) in which
case an invocation of a ipadm cli could be implemented by just invoking
NWAM to update the fixed location. But there might be other ways to fit
things together. In any case, the work to have think CLIs on top of
libraries means that we will be able to reuse things even if we end up
with a different CLI targeting the fixed server configuration case and
nwamcfg+GUI for the nomadic case.
Erik
