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

[Michael DeHaan]

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.



>
> Ben
>
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list