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
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
