On 4/6/2011 11:49, brett lentz wrote:
On Wed, Apr 6, 2011 at 11:00 AM, Scott
Henson<shenson(a)redhat.com> wrote:
> 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.
+1 for RDBMS support.
LAMP can probably be considered a well-known IT idiom. I don't see
this change as significantly adding complexity, and it certainly isn't
adding unnecessary complexity.
That sounds reasonable to me; being able to use a full-blown RDBMS would
likely cause tremendous performance and ease of maintenance
improvements. However, if Cobbler starts using a DB to store things I
would like to see it support sqlite or another really low-maintenance DB
to help keep things simple in the default case. Cobbler should be easy
to pick up and use.
> 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.
>
+1 for SQLAlchemy or another upstream ORM.
Developing a schema might be non-trivial, but IMO it's worthwhile
because it will likely help resolve other issues along the way.
+1, "what he said." With the right schema this sort of thing could make
the code much easier to maintain.
> 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).
I'm not familiar with how Django is broken up and whether you'll be
able to rope in just the deps you need, or whether you'll end up
pulling in all of Django.
Overall, I don't see this as a huge problem so long as the
dependencies are packaged, the package manager handles this stuff. To
me, worrying about dependency bloat at this stage sounds to me like
premature optimization. As long as you're not roping in non-Django
deps, I don't see the problem staying within the scope of the chosen
framework.
The problem with dependency bloat is that there are more things in the
stack below Cobbler that can go awry as things get updated or ported to
more distros. On the other hand, if having cobbler and cobbler-web use
separate web stacks makes things too difficult to maintain then adding
more external dependencies may be the better option. I can't really
give much of an opinion with regard to the web UI because of how little
I have used it.
--
Garrett Holmstrom