[Xorp-hackers] Configuration managment ....

[Kurt J. Lidl]

On Tue, Mar 22, 2005 at 11:21:56AM -0800, Javier Cardona wrote:
> On Tuesday 22 March 2005 06:20 am, Timothy Griffin wrote:
> > perhaps this idea has been kicked around before:
> > how about using an SQL database (such as MySQL) to
> > manage all xorp configuration data?
> > (...)
> > comments?
> 
> It's a good idea: the proof is that a similar architecture is being used 
> elsewhere with good success:  the WindManage suite, from Wind River 
> ( http://www.windriver.com/products/device_technologies/management/ ). 

No it isn't.

Just because someone does something and files for a patent on it does not
mean its a good idea.  Besides, its not a new idea -- varients have
been done in the past.  For example, I think it was the Netgear(?) backbone
routers that basically did everything through SNMP.  All the world's
a SNMP query, even the CLI.

It sucked.  Sure, architectually clean, and what engineering student
wouldn't have been impressed with the single data storage, and only
a single access method (SNMP GET) to get data out.  Just paste on
some CLI glue, and you're done.

Except that you couldn't get work done with it.  When the network
is mostly busted, and you're trying to fix it by manipulating the
running router configuration, the less you have to type, the more
likely it is you're going to be able to fix it.  When you have to
type long, long command lines to get anything done, it slows down
the person trying to fix things.  A lot.

Embedding something like a lightweight SQL database might work, but
does it really help?  I can imagine that the next thing someone
asks for is "how about we retrieve the router config from a
remote database?".  There is a serious chicken and egg problem here,
no working network until it is configured, and no configuration
until the network is up.

Sure, then they'll suggest a "bootstrap configuration" just to be
used long enough to get the "real configuration" into the router.
Then you're back at two different configurations, both of which
must be tested to work.  (And testing the "bootstrap configuration"
would necessitate taking the router offline, too!)  I would claim
it is insanity to separate the primary configuration storage from
the physical machine that is the router.  (Or the master of the
routing cluster, however you want to define that.)

You'd be better off making a nice, high level (smells like a job
for XML to me) configuration exporter, and make it easy to dump
that to a central configuration repository.  Tracking configuration
changes like this would actually be valuable to people with non-trivial
networks.

-Kurt