On 08/28/2009 02:04 PM, James Cammarata wrote:
I think that also accomplishes the goal of having an arbitrary  
templating engine, not necessarily bound to cheetah (at least for some  
things).

  

Not quite, as this would be blending the data before it got fed to Cheetah (or anything else, like koan, that also used
the blender toolchain).

I wouldn't recommend that as a way of bypassing Cheetah.

That being said, Cheetah seems to be in decent shape upstream now, so I'm not too worried about needing alternates anymore.

--Michael



On Aug 28, 2009, at 12: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

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.