Wow,

That's hot.  And amazing potential esp with connecting to things that already exist like LDAP and puppet. etc.


Peter Halliday
Excelsior Systems
(Phone:) 607-936-2172
(Cell:) 607-329-6905
(Fax:) 607-398-7928


On Fri, Aug 28, 2009 at 1:30 PM, Michael DeHaan <mdehaan@redhat.com> wrote:
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
cobbler-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler-devel