On Wed, 06 Apr 2011 13:20:50 -0400, Bill Peck <bpeck(a)redhat.com> wrote:
I think this would be a lot easier if we had a proper DB on the
backend
for cobbler.
Then the WebUI and Command line only tweak the DB, long running tasks
get picked up by cobblerd querying the DB for work.
I'm sure there are other ways too, but a DB would help when you have
thousands of records too. ;-)
Yeah, I believe a DB of some sort is the way forward. We just have a
couple of conflicting requirements that I'm not entirely sure how we
implement it. The first is to maintain the simplicity of cobbler for a
user to setup. The second is to simplify cobbler's internal code.
I'd like to get rid of cobbler's pseudo ORM and move to something
maintained by someone else. However, what do we use? I like SQLAlchemy
and Django's ORM, however they don't really map that well to cobbler's
data model. Something like couchdb will map much easier, but this
complicates setup for most people as there isn't much experience with
couchdb out there. There is also no simple, default case as there is
with SQLAlchemy/Django and sqlite.
I also am weary of what dependencies we have. I'm slightly loathed to
require all of Django just to get cobbler up and running. On the other
hand, I'm loathed to require a separate stack for cobbler and
cobbler-web (assuming we used sqlalchemy + pure wsgi for cobbler).
Opinions? Thoughts?
--
Scott Henson
Red Hat CIS Operator
WVU Alum BSAE/BSME