Note: this is a rather programming-intensive and theoretical email. However, for those that grok it, I promise it's at least conceptually interesting. I am not sure I understand all the potential uses for it, yet, but it opens up a way to add functionality to cobbler that effectively rewires the core, which I think is pretty darn powerful :)
Ok, so here we go. I ate lunch with Dan Radez today and we were talking about a way to integrate his own custom repo management thingy (TM) with Cobbler. We came up with an idea. This would add a new cobbler setting, defaulted to not being enabled: blender_filter = /usr/bin/path/to/external_blender Those familiar with Puppet's external nodes will understand this concept somewhat -- it's about injecting data from another program directly into a program using programs that work by exchanging data over stdin/stdout. The idea is that it will be possible to mix in the evaluation of Cobbler fields easily with the data from an external program -- whether that be an API, LDAP, a custom database, whatever you want. For instance, in Dan's case, assume that he has a list of extra repos (not defined in Cobbler) that he wants to dynamically assign to certain profiles from an external source. (One catch, see postscript) Every time cobbler evaluates an object with blender, cobbler, if configured, can execute /usr/bin/path/to/external_blender. This script passes as standard input the JSON file from cobbler as it blended the object. The script returns JSON as it /modified/ the object. The result is that arbitrary manipulation of cobbler is possible from the script with systems, without using the cobbler API, and without storing things in Cobbler. Another example might be (warning -- this is crazy arbitrary!) that you want to write a kickstart metadata variable into Cobbler that writes the current stock price of a company into /etc/motd every time kickstart is evaluated. This script might then, in this case, tweak ks_meta to perform that manipulation of the data. --Michael P.S. -- so, the catch. For Dan's theory to work with repos, it helps if all of his repos were actually in Cobbler due to the way repogen.py works. However in his case, he'd most likely just generate an additional templating variable that contains the text of his repo information, and bypass repogen.py. Effectively he would have $yum_repo_stanza (from Cobbler) and $dan_repo_stanza. What this would allow is for him to generate $dan_repo_stanza from an arbitrary external program. _______________________________________________ cobbler-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler-devel
