I'd like to teach Cobbler about how to use other templating engines, so that folks who have preferences can use them.
I'm thinking the easiest way to do this might be to assume a template is (whatever is marked as the default engine in settings, which is probably Cheetah) and then allow the template language to be marked at the top of a file with something like
"#template:cheetah"
OR:
"#template:mako"
Basically similar to the bash shebang (#!/bin/interpreter)
And if that is found, throw that line away and then pass the rest to the template.
Mako isn't currently available in EPEL 4/5, so I'm not sure how much we could actually use for anything stock until we've got that resolved. I put a question out to the Fedora maintainer.
We could also try to put in some logic to guess the template language if not specified though I see that as being potentially error prone.
Note were's also already Django Templating in cobbler-web, so that's a logical template to support, though we are probably not going to require the django framework for cobbler (not: cobbler-web), though if we're not actually using it, and just want the templating that's not so terribly wrong either (given it's in EPEL).
Thoughts?
Obviously Cheetah support will never go away.
--Michael
On Mon, May 4, 2009 at 12:17 PM, Michael DeHaan mdehaan@redhat.com wrote:
I'd like to teach Cobbler about how to use other templating engines, so that folks who have preferences can use them.
I'm thinking the easiest way to do this might be to assume a template is (whatever is marked as the default engine in settings, which is probably Cheetah) and then allow the template language to be marked at the top of a file with something like
"#template:cheetah"
OR:
"#template:mako"
Basically similar to the bash shebang (#!/bin/interpreter)
And if that is found, throw that line away and then pass the rest to the template.
Mako isn't currently available in EPEL 4/5, so I'm not sure how much we could actually use for anything stock until we've got that resolved. I put a question out to the Fedora maintainer.
We could also try to put in some logic to guess the template language if not specified though I see that as being potentially error prone.
Note were's also already Django Templating in cobbler-web, so that's a logical template to support, though we are probably not going to require the django framework for cobbler (not: cobbler-web), though if we're not actually using it, and just want the templating that's not so terribly wrong either (given it's in EPEL).
Thoughts?
Two words, "Support nightmare".
Jeff Schroeder wrote:
On Mon, May 4, 2009 at 12:17 PM, Michael DeHaan mdehaan@redhat.com wrote:
I'd like to teach Cobbler about how to use other templating engines, so that folks who have preferences can use them.
I'm thinking the easiest way to do this might be to assume a template is (whatever is marked as the default engine in settings, which is probably Cheetah) and then allow the template language to be marked at the top of a file with something like
"#template:cheetah"
OR:
"#template:mako"
Basically similar to the bash shebang (#!/bin/interpreter)
And if that is found, throw that line away and then pass the rest to the template.
Mako isn't currently available in EPEL 4/5, so I'm not sure how much we could actually use for anything stock until we've got that resolved. I put a question out to the Fedora maintainer.
We could also try to put in some logic to guess the template language if not specified though I see that as being potentially error prone.
Note were's also already Django Templating in cobbler-web, so that's a logical template to support, though we are probably not going to require the django framework for cobbler (not: cobbler-web), though if we're not actually using it, and just want the templating that's not so terribly wrong either (given it's in EPEL).
Thoughts?
Two words, "Support nightmare".
Three words: uncertain Cheetah future. Six words: You wouldn't have to use them. Twenty two words: Cheetah hasn't had a release since 2007. Some hedging of bets seems important if we say, run into 2.6/3000 Python bugs.
I've already asked the Fedora maintainer about whether we can move to the "Community Cheetah" release/fork though from the Cheetah list it's a little unclear about who's owning it moving forward.
On Mon, May 4, 2009 at 12:25 PM, Michael DeHaan mdehaan@redhat.com wrote:
Jeff Schroeder wrote:
On Mon, May 4, 2009 at 12:17 PM, Michael DeHaan mdehaan@redhat.com wrote:
I'd like to teach Cobbler about how to use other templating engines, so that folks who have preferences can use them.
I'm thinking the easiest way to do this might be to assume a template is (whatever is marked as the default engine in settings, which is probably Cheetah) and then allow the template language to be marked at the top of a file with something like
"#template:cheetah"
OR:
"#template:mako"
Basically similar to the bash shebang (#!/bin/interpreter)
And if that is found, throw that line away and then pass the rest to the template.
Mako isn't currently available in EPEL 4/5, so I'm not sure how much we could actually use for anything stock until we've got that resolved. I put a question out to the Fedora maintainer.
We could also try to put in some logic to guess the template language if not specified though I see that as being potentially error prone.
Note were's also already Django Templating in cobbler-web, so that's a logical template to support, though we are probably not going to require the django framework for cobbler (not: cobbler-web), though if we're not actually using it, and just want the templating that's not so terribly wrong either (given it's in EPEL).
Thoughts?
Two words, "Support nightmare".
Three words: uncertain Cheetah future. Six words: You wouldn't have to use them. Twenty two words: Cheetah hasn't had a release since 2007. Some hedging of bets seems important if we say, run into 2.6/3000 Python bugs.
I've already asked the Fedora maintainer about whether we can move to the "Community Cheetah" release/fork though from the Cheetah list it's a little unclear about who's owning it moving forward.
Oh sorry please mention the reasoning behind a change like that next time :)
It sounds perfectly reasonable but also sounds like a huge pain point. That seems to be the only downside of cobbler. Every major change has big breakage from the last version. Just my two cents.
Jeff Schroeder wrote:
On Mon, May 4, 2009 at 12:25 PM, Michael DeHaan mdehaan@redhat.com wrote:
Jeff Schroeder wrote:
On Mon, May 4, 2009 at 12:17 PM, Michael DeHaan mdehaan@redhat.com wrote:
I'd like to teach Cobbler about how to use other templating engines, so that folks who have preferences can use them.
I'm thinking the easiest way to do this might be to assume a template is (whatever is marked as the default engine in settings, which is probably Cheetah) and then allow the template language to be marked at the top of a file with something like
"#template:cheetah"
OR:
"#template:mako"
Basically similar to the bash shebang (#!/bin/interpreter)
And if that is found, throw that line away and then pass the rest to the template.
Mako isn't currently available in EPEL 4/5, so I'm not sure how much we could actually use for anything stock until we've got that resolved. I put a question out to the Fedora maintainer.
We could also try to put in some logic to guess the template language if not specified though I see that as being potentially error prone.
Note were's also already Django Templating in cobbler-web, so that's a logical template to support, though we are probably not going to require the django framework for cobbler (not: cobbler-web), though if we're not actually using it, and just want the templating that's not so terribly wrong either (given it's in EPEL).
Thoughts?
Two words, "Support nightmare".
Three words: uncertain Cheetah future. Six words: You wouldn't have to use them. Twenty two words: Cheetah hasn't had a release since 2007. Some hedging of bets seems important if we say, run into 2.6/3000 Python bugs.
I've already asked the Fedora maintainer about whether we can move to the "Community Cheetah" release/fork though from the Cheetah list it's a little unclear about who's owning it moving forward.
Oh sorry please mention the reasoning behind a change like that next time :)
It sounds perfectly reasonable but also sounds like a huge pain point. That seems to be the only downside of cobbler. Every major change has big breakage from the last version. Just my two cents.
Not stated, but I did not plan on migrating any existing kickstarts, /etc/cobbler files, or snippets.
--Michael
Three words: uncertain Cheetah future. Six words: You wouldn't have to use them. Twenty two words: Cheetah hasn't had a release since 2007. Some hedging of bets seems important if we say, run into 2.6/3000 Python bugs.
I've already asked the Fedora maintainer about whether we can move to the "Community Cheetah" release/fork though from the Cheetah list it's a little unclear about who's owning it moving forward.
I've already run into at least one major (in my opinion) Cheetah bug, which was improper handling of escapes. In Cheetah currently you cannot escape a , so trying to do \ fails. This was a major nightmare when working on Windows SIFs (response files), since all the paths are MS paths, and needing to have variables in the paths.
The solution was to add a tempate variable for backslashes and render the template with that, total nightmare that looked like this:
OriSrc = "${bsp}${bsp}$next_server\REMINST${bsp}$name\i386"
\$var is interpreted as "$var" always, so your variable is not interpreted.
James Cammarata wrote:
Three words: uncertain Cheetah future. Six words: You wouldn't have to use them. Twenty two words: Cheetah hasn't had a release since 2007. Some hedging of bets seems important if we say, run into 2.6/3000 Python bugs.
I've already asked the Fedora maintainer about whether we can move to the "Community Cheetah" release/fork though from the Cheetah list it's a little unclear about who's owning it moving forward.
I've already run into at least one major (in my opinion) Cheetah bug, which was improper handling of escapes. In Cheetah currently you cannot escape a , so trying to do \ fails. This was a major nightmare when working on Windows SIFs (response files), since all the paths are MS paths, and needing to have variables in the paths.
The solution was to add a tempate variable for backslashes and render the template with that, total nightmare that looked like this:
OriSrc = "${bsp}${bsp}$next_server\REMINST${bsp}$name\i386"
\$var is interpreted as "$var" always, so your variable is not interpreted.
I am guessing it might be \\$foo, not having tried it.
Escape the backslashes and also the dollar sign.
When in doubt you can also build the string in pieces using #set --Michael
I've already run into at least one major (in my opinion) Cheetah bug, which was improper handling of escapes. In Cheetah currently you cannot
escape
a , so trying to do \ fails. This was a major nightmare when working on Windows SIFs (response files), since all the paths are MS paths, and needing to have variables in the paths.
The solution was to add a tempate variable for backslashes and render
the
template with that, total nightmare that looked like this:
OriSrc = "${bsp}${bsp}$next_server\REMINST${bsp}$name\i386"
\$var is interpreted as "$var" always, so your variable is not interpreted.
I am guessing it might be \\$foo, not having tried it.
Escape the backslashes and also the dollar sign.
When in doubt you can also build the string in pieces using #set --Michael
The thing is, in the above example you do NOT want to escape the $, you want cheetah to evaluate the variable. Instead, Cheetah always escapes the $ (meaning your variable is not evaluated), and just prints out all the other backslashes.
James Cammarata wrote:
I've already run into at least one major (in my opinion) Cheetah bug, which was improper handling of escapes. In Cheetah currently you cannot
escape
a , so trying to do \ fails. This was a major nightmare when working on Windows SIFs (response files), since all the paths are MS paths, and needing to have variables in the paths.
The solution was to add a tempate variable for backslashes and render
the
template with that, total nightmare that looked like this:
OriSrc = "${bsp}${bsp}$next_server\REMINST${bsp}$name\i386"
\$var is interpreted as "$var" always, so your variable is not interpreted.
I am guessing it might be \\$foo, not having tried it.
Escape the backslashes and also the dollar sign.
When in doubt you can also build the string in pieces using #set --Michael
The thing is, in the above example you do NOT want to escape the $, you want cheetah to evaluate the variable. Instead, Cheetah always escapes the $ (meaning your variable is not evaluated), and just prints out all the other backslashes.
Noted.... that is annoying if it's not processing the string Left-to-Right. I'd use #set in that case and build it in pieces.
--Michael
On Mon, 04 May 2009 17:29:48 -0400, Michael DeHaan mdehaan@redhat.com wrote:
James Cammarata wrote:
I've already run into at least one major (in my opinion) Cheetah bug, which was improper handling of escapes. In Cheetah currently you cannot
escape
a , so trying to do \ fails. This was a major nightmare when working on Windows SIFs (response files), since all the paths are MS paths, and needing to have variables in the paths.
The solution was to add a tempate variable for backslashes and render
the
template with that, total nightmare that looked like this:
OriSrc = "${bsp}${bsp}$next_server\REMINST${bsp}$name\i386"
\$var is interpreted as "$var" always, so your variable is not interpreted.
I am guessing it might be \\$foo, not having tried it.
Escape the backslashes and also the dollar sign.
When in doubt you can also build the string in pieces using #set --Michael
The thing is, in the above example you do NOT want to escape the $, you want cheetah to evaluate the variable. Instead, Cheetah always escapes the $ (meaning your variable is not evaluated), and just prints out all the other backslashes.
Noted.... that is annoying if it's not processing the string Left-to-Right. I'd use #set in that case and build it in pieces.
--Michael
Looking in /usr/share/doc/iputils-20020927/README.bonding it would seem that RHEL4 only supports the modprobe.conf method of specifying options... so it looks like we may need to build some additional logic into the network config snippet to have it sense whether the OS being installed supports the newer method :(
On Mon, May 4, 2009 at 2:37 PM, James Cammarata jimi@sngx.net wrote:
On Mon, 04 May 2009 17:29:48 -0400, Michael DeHaan mdehaan@redhat.com wrote:
James Cammarata wrote:
I've already run into at least one major (in my opinion) Cheetah bug, which was improper handling of escapes. In Cheetah currently you cannot
escape
a , so trying to do \ fails. This was a major nightmare when working on Windows SIFs (response files), since all the paths are MS paths, and needing to have variables in the paths.
The solution was to add a tempate variable for backslashes and render
the
template with that, total nightmare that looked like this:
OriSrc = "${bsp}${bsp}$next_server\REMINST${bsp}$name\i386"
\$var is interpreted as "$var" always, so your variable is not interpreted.
I am guessing it might be \\$foo, not having tried it.
Escape the backslashes and also the dollar sign.
When in doubt you can also build the string in pieces using #set --Michael
The thing is, in the above example you do NOT want to escape the $, you want cheetah to evaluate the variable. Instead, Cheetah always escapes the $ (meaning your variable is not evaluated), and just prints out all the other backslashes.
Noted.... that is annoying if it's not processing the string Left-to-Right. I'd use #set in that case and build it in pieces.
--Michael
Looking in /usr/share/doc/iputils-20020927/README.bonding it would seem that RHEL4 only supports the modprobe.conf method of specifying options... so it looks like we may need to build some additional logic into the network config snippet to have it sense whether the OS being installed supports the newer method :(
Wasn't there a per-distro snippets patch that was just applied? This sounds like it will have to be used unless you want a big mess.
Jeff Schroeder wrote:
On Mon, May 4, 2009 at 2:37 PM, James Cammarata jimi@sngx.net wrote:
On Mon, 04 May 2009 17:29:48 -0400, Michael DeHaan mdehaan@redhat.com wrote:
James Cammarata wrote:
I've already run into at least one major (in my opinion) Cheetah bug, which was improper handling of escapes. In Cheetah currently you cannot
escape
a , so trying to do \ fails. This was a major nightmare when working on Windows SIFs (response files), since all the paths are MS paths, and needing to have variables in the paths.
The solution was to add a tempate variable for backslashes and render
the
template with that, total nightmare that looked like this:
OriSrc = "${bsp}${bsp}$next_server\REMINST${bsp}$name\i386"
\$var is interpreted as "$var" always, so your variable is not interpreted.
I am guessing it might be \\$foo, not having tried it.
Escape the backslashes and also the dollar sign.
When in doubt you can also build the string in pieces using #set --Michael
The thing is, in the above example you do NOT want to escape the $, you want cheetah to evaluate the variable. Instead, Cheetah always escapes the $ (meaning your variable is not evaluated), and just prints out all the other backslashes.
Noted.... that is annoying if it's not processing the string Left-to-Right. I'd use #set in that case and build it in pieces.
--Michael
Looking in /usr/share/doc/iputils-20020927/README.bonding it would seem that RHEL4 only supports the modprobe.conf method of specifying options... so it looks like we may need to build some additional logic into the network config snippet to have it sense whether the OS being installed supports the newer method :(
Wasn't there a per-distro snippets patch that was just applied? This sounds like it will have to be used unless you want a big mess.
Or we could just not support it for RHEL 4 (?).
Per distro snippets as implemented key off the name, so it's not a good fit.
--Michael
On Mon, May 4, 2009 at 2:46 PM, Michael DeHaan mdehaan@redhat.com wrote:
Jeff Schroeder wrote:
On Mon, May 4, 2009 at 2:37 PM, James Cammarata jimi@sngx.net wrote:
On Mon, 04 May 2009 17:29:48 -0400, Michael DeHaan mdehaan@redhat.com wrote:
James Cammarata wrote:
> > I've already run into at least one major (in my opinion) Cheetah bug, > which > was improper handling of escapes. In Cheetah currently you cannot > >
escape
> > a > , so trying to do \ fails. This was a major nightmare when working > on > Windows SIFs (response files), since all the paths are MS paths, and > needing to have variables in the paths. > > The solution was to add a tempate variable for backslashes and render > >
the
> > template with that, total nightmare that looked like this: > > OriSrc = "${bsp}${bsp}$next_server\REMINST${bsp}$name\i386" > > \$var is interpreted as "$var" always, so your variable is not > interpreted. > > > >
I am guessing it might be \\$foo, not having tried it.
Escape the backslashes and also the dollar sign.
When in doubt you can also build the string in pieces using #set --Michael
The thing is, in the above example you do NOT want to escape the $, you want cheetah to evaluate the variable. Instead, Cheetah always escapes the $ (meaning your variable is not evaluated), and just prints out all the other backslashes.
Noted.... that is annoying if it's not processing the string Left-to-Right. I'd use #set in that case and build it in pieces.
--Michael
Looking in /usr/share/doc/iputils-20020927/README.bonding it would seem that RHEL4 only supports the modprobe.conf method of specifying options... so it looks like we may need to build some additional logic into the network config snippet to have it sense whether the OS being installed supports the newer method :(
Wasn't there a per-distro snippets patch that was just applied? This sounds like it will have to be used unless you want a big mess.
Or we could just not support it for RHEL 4 (?).
Per distro snippets as implemented key off the name, so it's not a good fit.
You're right and --template-files="/srv/templates/modprobe.conf.RHEL4=/etc/modprobe.conf" or something like that isn't unbearable. You might just not support it until an enterprising individual wants it enough to send you patches.
Looking in /usr/share/doc/iputils-20020927/README.bonding it would
seem
that RHEL4 only supports the modprobe.conf method of specifying options... so it looks like we may need to build some additional logic into the network config snippet to have it sense whether the OS being installed supports the newer method :(
Gah, I totally replied to the wrong thread...
On Mon, 2009-05-04 at 15:17 -0400, Michael DeHaan wrote:
I'd like to teach Cobbler about how to use other templating engines, so that folks who have preferences can use them.
I'm thinking the easiest way to do this might be to assume a template is (whatever is marked as the default engine in settings, which is probably Cheetah) and then allow the template language to be marked at the top of a file with something like
"#template:cheetah"
OR:
"#template:mako"
Basically similar to the bash shebang (#!/bin/interpreter)
Would this open the door for ...
#template:snake ?
Thanks, James
And if that is found, throw that line away and then pass the rest to the template.
Mako isn't currently available in EPEL 4/5, so I'm not sure how much we could actually use for anything stock until we've got that resolved. I put a question out to the Fedora maintainer.
We could also try to put in some logic to guess the template language if not specified though I see that as being potentially error prone.
Note were's also already Django Templating in cobbler-web, so that's a logical template to support, though we are probably not going to require the django framework for cobbler (not: cobbler-web), though if we're not actually using it, and just want the templating that's not so terribly wrong either (given it's in EPEL).
Thoughts?
Obviously Cheetah support will never go away.
--Michael
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
James Laska wrote:
On Mon, 2009-05-04 at 15:17 -0400, Michael DeHaan wrote:
I'd like to teach Cobbler about how to use other templating engines, so that folks who have preferences can use them.
I'm thinking the easiest way to do this might be to assume a template is (whatever is marked as the default engine in settings, which is probably Cheetah) and then allow the template language to be marked at the top of a file with something like
"#template:cheetah"
OR:
"#template:mako"
Basically similar to the bash shebang (#!/bin/interpreter)
Would this open the door for ...
#template:snake ?
Thanks, James
It might. (Assuming we make this template support modular, snake.py could just be dropped into "modules" ?)
For those that were wondering, Snake builds kickstarts out of a series of pykickstart statements, so it's more like Python code instead of kickstart language.
https://fedorahosted.org/snake/wiki/SnakeExamples/ServerSnakeKs
In this case, would each kickstart snippet be a portion of the whole, and maybe the very last part ("the def ks stuff) is written for you so the file is just a list of snippets? Trying to figure out what that might look like... either way, probably not a part of cobbler proper but I'd like to make your life easier however we can.
(Also, for those wondering, the reason we don't do this right now is suppose you have a RHEL-4 server, in order to install F-10, we'd need a pykickstart that was F-10 aware, which is why we don't do anything with pykickstart today).
--Michael
cobbler-devel@lists.fedorahosted.org