[et-mgmt-tools] What's new in Cobbler development lately

[Michael DeHaan]

A few things of interest to a few people.... There are still a few 
things upstream that I want to get done before pushing 0.6.3 out.    
However, it's worth talking about what is already there, in case anyone 
is interested in those features and would like to play with/test them 
now.  

First off -- performance upgrades.    Cobbler does great now with an 
average number of records, but performance with a very large number of 
systems in the "database" could be better.  By switching all serializers 
(except settings) to serializer_shelve in /etc/cobbler/auth.conf, 
cobbler gets a lot faster for very large configurations.    This is 
because changes to the cobbler "database" can be made without 
reading/writing the whole file.     I'm still undecided as to whether 
this should
be the default for new Cobbler installs, but there will be a script to 
migrate users between formats for those that have existing 
configurations.   With the new code, it's possible
to run a "cobbler list" command and see 5000 entries come back in 2 
seconds -- before, YAML parsing/loading would have made storing a config 
that large in YAML somewhat painful.   Currently this is using BSD-DB 
(which some of you said is scary, fair enough), though we could also use 
gddb.  I've tested both and performance is identical.     sqlite is 
possible, but maybe not needed.   You can read more here:  
https://hosted.fedoraproject.org/projects/cobbler/wiki/AlternativeSerializers

Second -- there was a request to extend the idea of Cobbler triggers ( 
https://hosted.fedoraproject.org/projects/cobbler/wiki/CobblerTriggers ) 
to  support a "sync" trigger.  We have that now.    For instance, now we 
have the service-restart code as a trigger.   So by default it will 
restart dhcpd/dnsmasq after a cobbler sync if you have DHCP management 
turned on.  If you don't, it does nothing.   However, suppose you wanted 
Cobbler to push out DHCP configurations to multiple servers?   No 
problem!   Now you can modify the trigger yourself and make it do 
whatever you want, all without modifying Cobbler code.

Both making things more modular (for arbitrary user extensibility) and 
making things scale for extremely large configurations will definitely 
be an ongoing focus for subsequent releases.

If you're interested in any of the above, check out the git version 
control repo.

--Michael