Re: [Pulp-list] How about we just merge these core features into Cobbler?

From: Michael DeHaan <mdehaan redhat com>

To: Ben Riggs <rigg0022 umn edu>

Cc: pulp-list redhat com

Subject: Re: [Pulp-list] How about we just merge these core features into Cobbler?

Date: Fri, 12 Sep 2008 15:06:07 -0400

Ben Riggs wrote:

Hi,

I've been an avid user of cobbler for a year or more, now, and we use
it for repo management. It works well for what it does, but,
naturally, there are functions we currently do by hand or by script
that would be very convenient to have included.

Which features are these? We can likely include them, but I don't
recall anything left not included that was brought up on cobbler-list.
Bring them up, definitely.

I definitely like the idea of a separately maintained repo management
program that integrates with cobbler. I also think that having repo
manage working properly is crucial to cobbler working properly.
However, the idea of having a different interface that uses the
cobbler api for more advanced features seems like a less than
desirable solution.

Instead, I think what would make the most sense in the long run in the
way of software architecture is for pulp to provide a solid api that
is used by cobbler. This, however, would be added complexity for
anyone developing the software and would likely require close
oversight. Given that caveat, I think that such a design would provide
better functionality and ease of development in the end.

Yeah, so cobbler already has an API for repo mirroring/management which
we can easily upgrade to support the new features (repo snapshotting
seem to be the main critical one and is essentially a cp + a hardlink).
I can't see pulp's being that different at a base level. These tools
just use yum core bits and are fundamentally not that complex.

We can set attributes on various repos, clone them, and so forth all
from the API today. The API already has hooks into the command line
app and you can get at those same bits of XMLRPC.

I personally don't think it matters what import scope that API is in, so
expanding on the existing tool and improving what we don't like about it
seems better than creating another that has to reimplement something
that is not very old, already has an active community, and is open to
the upgrades.

If Pulp had a codebase that did all of this and it beat what Cobbler
did, yes, we'd look at integrating it, but right now, with those
features suggested (which are not many) being things that are easily
addable to cobbler, this is very much what I believe we should do.

What we do with the Web interfaces to such tools is equally important,
but it's a separate question. Using cobbler for the underlying
implementation for any new repo management features (which of course are
just in turn simplifiers on top of yum), seems perfectly reasonable to
me.
You can use the cobbler repo objects independently of the distro/profile
objects.