[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

Ben Riggs wrote:

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.


Pulp-list mailing list
Pulp-list redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]