Snapshotting repos
by Gerhardus Geldenhuis
Hi
I am working on a simple internal file based (symlinks) method to snapshot
repos on a monthly basis making use of cobbler. For various reasons we are
not using spacewalk to manage that... I am thinking with a Red Hat / CentOS
hat on so probably not considering other OS'es. My question is simple, do
you think that adding a repo snapshot ability to cobbler is worthwhile or is
that task better suited to be implemented in spacewalk or other management
software? If our interim solution becomes more permanent, I thought it would
be useful to build this into cobbler rather than tagging it on afterwards.
However things get more complicated if you take into consideration that
these snapshots potentially need to be replicated across multiple cobbler
servers and all of the other things I have probably not considered. So
before I go off on a tangent I thought I would get some opinions.
Regards
--
Gerhardus Geldenhuis
12 years, 6 months
Seeking feedback from build ISO users
by Jörgen Maas
Hi all,
I'm currently working on some patches regarding the cobbler buildiso feature.
Now i'm wondering who is using the netboot iso and the profiles as
provided in the boot menu, instead of the system records in the menu?
Could you also describe your use case, e.g. why are you using this
feature?
Any feedback would be greatly appreciated!
Thanks
--
Grtz,
Jörgen Maas
12 years, 6 months
A few bugs and fixes
by Javier Palacios
Hello,
I have found (and fixed) some minor bugs:
Missing Import*Manager.path_tail() method
https://github.com/javiplx/cobbler-2.x/commit/a7c65366b93691825a01a656b4c...
There are also some inconsistencies in handling of keep_updated and
mirror_locally for repos.
When they are set to different values, different errors happen:
keep False , mirror True - check warns about unsynced repo, but
reposync updates nothing
keep True , mirror False - a local repo is created, but with anything
but the config.repo file
https://github.com/javiplx/cobbler-2.x/commit/31ed180b3257a823e9213b27f3e...
There is a method on import managers that is never called
(get_tree_location, actually a duplicate of configure_tree_location)
https://github.com/javiplx/cobbler-2.x/commit/f37ffb3c6018d3f73912dfd8f1f...
I have also modified debian/ubuntu importer to remove a method defined
twice, and to create the associated repos when importing a debian
netinstall media [Enabling apt on VALID_REPO_BREEDS not included on
patch]
https://github.com/javiplx/cobbler-2.x/commit/b2b3acde4f3d0d34d21cbe41886...
And finally, I have patched cobbler to extend the use of
utils.rsync_files, to reduce direct calls to rsync command.
https://github.com/javiplx/cobbler-2.x/commit/87f64562f08f0f1c29027a6c68f...
Javier Palacios
12 years, 7 months
[PATCH] new template engine support
by James Cammarata
On Sun, Aug 28, 2011 at 12:33 AM, James Cammarata <jimi(a)sngx.net> wrote:
> Created a new feature branch on my github -> new-template, with the
> following commit:
>
> commit 838ba2425d3e8c0d4c8e04c827eb88fe6e87b1cb
> Author: James Cammarata <jimi(a)sngx.net>
> Date: Sun Aug 28 00:23:19 2011 -0500
>
> Initial commit for adding support for other template languages,
> namely jinja2 in this case
A follow up to this (and fixing the subject...):
commit a3806ce9f7ced3ba0ec3906f6e960e41b2f3fb9d
Author: James Cammarata <jimi(a)sngx.net>
Date: Sun Aug 28 15:46:54 2011 -0500
Added the setting 'default_template_type' to the settings file, and
created logic to use that in Templar().render(). Also added an option
to the same function to pass the template type in as an argument.
12 years, 7 months
[PATCH]
by James Cammarata
Created a new feature branch on my github -> new-template, with the
following commit:
commit 838ba2425d3e8c0d4c8e04c827eb88fe6e87b1cb
Author: James Cammarata <jimi(a)sngx.net>
Date: Sun Aug 28 00:23:19 2011 -0500
Initial commit for adding support for other template languages,
namely jinja2 in this case
This was pretty easy to add, most was moving the render() function to
render_cheetah() and reorganizing some code that would be common to
all render_* functions.:
Created commit 838ba24: Initial commit for adding support for other
template languages, namely jinja2 in this case
1 files changed, 79 insertions(+), 22 deletions(-)
To use jinja2 for your templates, just put #template=jinja2 on the
first line of the template (it is white-space sensitive, so it must
match that exactly). If you don't have jinja2 installed, you'll just
get an error string back for your template - it won't fail to run
cobblerd or throw exceptions.
This is EXTREMELY basic at the moment, and doesn't do much of anything
special. This is pretty much just a proof of concept, and to see how
people like the idea.
Here's a sample template:
#template=jinja2
Hi from Jinja2!
{%- for i in [1,2,3,4] %}
For loop line {{ i }}{% endfor %}
The http_server variable = @@http_server@@
The profile variable for this system is {{ profile }}
And here's how it renders:
Hi from Jinja2!
For loop line 1
For loop line 2
For loop line 3
For loop line 4
The http_server variable = 127.0.0.1
The profile variable for this system is centos-5.5-x86_64
12 years, 7 months
[PATCH] removing action_import.py
by James Cammarata
Pushed to my github. This is a remnant from before we had import
modules, and apparently can cause confusion when users have import
problems.
commit 9a2220b750a4f835f60e022e510952feed85402b
Author: James Cammarata <jimi(a)sngx.net>
Date: Sat Aug 27 07:47:01 2011 -0500
Removed action_import module and references to it in code to
prevent future confusion.
12 years, 7 months
Re: template languages (was: Release plan?)
by James Cammarata
> If you like the Django template language (I do :) ), then jinja2 might
> be an alternative. It was based around the same syntax and extended.
I've been playing with a few, and I really like both mako and jinja2.
The main problem I see with mako is it's damn near impossible to stop
people from importing random python modules. I tried some preprocessor
hooks to strip imports out, but it's messy. Jinja2 is much better, and
you can enable "line syntax" which makes the syntax more cheetah-like:
{% for foo in bar %}
{{ foo }} {# comment that won't show up in the output #}
{% endfor %}
{% include "some_other.tmpl" %}
can become:
#for foo in bar:
{{ foo }} ## comment that won't show up in the output
#endfor
#include "some_other.tmpl"
There is a small issue when you do it this way - it tries to interpret
any line starting with # as a python commands. I've gotten around that
by using #: as the character combo to indicate python lines. So it's
not exactly like cheetah, but it's still very easy to read and write:
#:for i in test:
# comment will show up
variable is {{ i }} ## comment won't be output
#:endfor
#:include 'test2'
The code to render this is very simple:
from jinja2 import Environment, FileSystemLoader
env = Environment(
loader=FileSystemLoader(['/var/lib/cobbler/snippets',]),
line_statement_prefix="#:",
line_comment_prefix="##")
template = env.get_template('test')
print template.render({'test':[1,2,3]})
Note that the FileSystemLoader() class can take multiple directories,
so we could easily add the feature allowing multiple snippet
directories.
So, overall, if I had to pick a templating language today it would be jinja2.
> I was considering (in my less-than-copious free time) hacking the
> templating engine parts to be modular, or attempting to. That would
> allow the testing of different engines.
> Dunno how hard that would turn out to be though.
I don't know if it's worth the effort to modularize this - it's
something we shouldn't be switching out that often. It would make it
easier to switch out if at some point the new language we choose
starts slipping on support the way cheetah has, but how likely is
that?
12 years, 8 months
