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

[Mairin Duffy]

Michael DeHaan wrote:
 > Mairin Duffy wrote:
 >> Michael DeHaan wrote:
 >>> Sorry for the late reply, I was looking over the pulp features list 
up on the Wiki a few weeks ago.
 >>>
 >>> Serious question -- it seems the features mentioned for Pulp (other 
than interface features) are suitable to be added to Cobbler in ways 
that requires people use less tools
 >>
 >> Where would the interface live, then?
 >>
 >> On top as a separate piece, making calls to a cobbler server? Does 
that mean pulp would be the interface piece only?
 >>
 >> ~m
 >
 > Spacewalk maybe?

Backtracking a bit, I had one question. Is it a concern that if 
the-artist-formerly-known-as-pulp becomes a part of cobbler, that it 
would be difficult to tie in pulp functionality with a different 
provisioning system? I had thought the original notion of having two 
separate apps was partly to provide that kind of flexibility since 
sometimes folks who manage their software distribution might not have 
any control over the provisioning of machines or the software/process 
used to provision the machines. Would pulp still be able to tie into 
another provisioning system if it was built into cobbler?

 > FWIW, I'm thinking about making cobbler-web a seperate package in a 
future release as well (I'm pondering moving to Rails to allow some 
content to be better accessed by ovirt, and also to make better use of 
mcpierce's rubygem-cobbler module), and am considering various upgrades 
related to Cobbler's new ACL support, so there's time to consider 
improvements to the way repos are being managed today as well. 
Ultimately I think where such UI bits go depend on what you would want 
to see.   From the list of functionality we see now I don't see why they 
couldn't be in there.

By "in there" do you mean cobbler web or do you mean spacewalk?

I think provisioning systems and managing the content to be provisioned 
to those systems are separate tasks. I could see a benefit to having a 
UI workflow that pulls together pieces of each integrated in one UI, but 
managing a software distribution and provisioning systems are still 
separate tasks and I think presenting the intricacies of both all 
together in one UI might be a bit overwhelming.

Let me explain how I'm thinking this could work, based on some of the 
stuff I've been working on My Fedora with J5, Eve, Luke, and Toshio. 
Maybe it's not applicable, or maybe it is or would spark a good idea. As 
you know, koji and bodhi are separate applications, geared for different 
tasks (building packages and pushing updates) but those tasks are 
related. Each is part of a larger 'package maintenance' workflow. (There 
are other overarching workflows involving the two tools too, such as 
release engineering but let's focus on pkg maintenance for now.) Our 
plan for the My Fedora webui is to provide integration between the two 
apps, koji and bodhi, in one UI tailored for a basic package maintenance 
workflow. But the bodhi and koji UIs will still remain, they're not 
going away, for more specialized tasks related to each respective 
domain. Does that make sense?

So I was thinking that maybe pulp could be a UI geared to the current 
Satellite 
build-your-distro-push-it-out-to-systems-and-update-your-distro-and-update-those-systems 
workflow that Satellite (and Spacewalk :) ) users go through today. This 
isn't to say there aren't other workflows that would use either/or or 
both the repo management bits and cobbler, but pulp would be an 
interface specifically geared towards the common Satellite/Spacewalk 
workflow we know so well from working with and going out and 
interviewing customers of the Satellite product.

~m