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(a)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(a)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.
>
>