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

[Mairin Duffy]

Michael DeHaan wrote:

 >
 >> Maybe it would help to analogize what I mean: if I just want to make a
 >> peanut butter sandwich, I don't need to be offered an apron, french
 >> chopping knife, a 36-inch long cutting board, and a food processor to
 >> do so. I mean, maybe the food processor would be handy if I wanted to
 >> shell and crush the peanuts and make freshly made peanut butter for my
 >> sandwich, but that's definitely a path less travelled :) But if I'm
 >> Martha Stewart making a Thanksgiving feast, then at least some of
 >> those tools probably are absolutely essential. Is the type of person
 >> who makes PB&J and mac&cheese going to be able to do so with a Martha
 >> Stewart kitchen (TM)? Yeh, but it might be a lot more
 >> confusing/complicated for them ("which knife do i use?" "what does
 >> this tool do?") And it's not a simple vs complex dichotomy, add a
 >> cafeteria chef into the mix who cooks for 500 people a day, and he'll
 >> have a third separate workflow from myself and Martha and maybe needs
 >> even more different tools.
 >
 > I generally prefer to make tools that allow people to define their own
 > workflows, very much in the LEGO (TM) building block vein.  If you don't
 > want to use the green blocks, it's okay :)

I think that's a good philosophy, but I think it is also good to provide 
a 'best practices' or maybe a better term would be 'reference 
implementation' of putting those lego blocks together? Just given a 
bucket of legos, it's hard to imagine what id possible without the 
little  catalog that comes with it right? :) And they are just as fun 
(although a different kind of fun) to build based off of the instruction 
booklet than to build from your own head. It certainly takes a lot more 
time and work to do the latter.

Anyhow, I see the UI/workflow pulp thing I'm talking about as being sort 
of what you get if you follow the lego leaflet instructions maybe...?
 >
 > Either way I don't see what is there as being that complex, and I'm open
 > to making them simpler however we can.

I would think adding more repo functionality to it, though, it would
grow more complex than what is there in it right now. I don't know for 
sure though, but looking at spacewalk's complexity it seems a reasonable 
guess.
 >>>>
 >>>> 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.
 >>>
 >>> If it's geared to that workflow, why is it not part of Spacewalk?   I
 >>> think that package management (RPMs) is the core use of Spacewalk
 >>> today ... with the other features as being very useful but kind of a
 >>> "bonus".  So maybe it could be just done as upgrades to that project
 >>> if it's more about that workflow?
 >>
 >> Well, I do think there was some thought to it eventually replacing
 >> Spacewalk. I am not sure if a 'clean slate' is needed there or not. If
 >> cobbler is getting integrated into spacewalk, does that make spacewalk
 >> the horse that ate the dog (cobbler) that ate the cat (pulp?) that ate
 >> the mouse (my sanity?)
 >
 > Not sure, but perhaps there is a hole in my bucket.

Is that the bucket the cow kicked after it ate the horse? :)
 >
 >>>
 >>> Either way, cobbler's repo stuff could remain the backend.  I am less
 >>> interested in what happens with the Web details (they are very
 >>> important, don't get me wrong), but am mainly interested in seeing we
 >>> leverage available bits on the backend.
 >>
 >> Seems reasonable :)
 >>>
 >>> If Pulp would want to be a WebUI that supported the Cobbler API,
 >>> maybe that does make sense, but seeing the linkage that exists today
 >>> where we can associate profiles with repos in Cobbler, I like them
 >>> being together.
 >>
 >> I'm not quite following this - you're saying you'd like pulp and
 >> cobbler to be together, or you'd like the webui to be together with
 >> cobbler?
 >
 > I think I'm saying I'd like everything in Pulp to be added to Cobbler as
 > cobbler enhancements, just because cobbler's core (not so much the
 > webapp) already has what it takes to do most of the repo management, the
 > rest is extensible, and it integrates at API level with provisioning
 > already.

Okay, I understand now, although I'm still not sure I agree or disagree 
fwiw.
 >
 > Perhaps the new webapp could have different perspectives for repos
 > versus installation, maybe that's a good solution?

Yeh, but I think where you say "perspective" I'm thinking different UI / 
different workflow. Although then they could be tied together in 
different tabs and look the same so they could "look" like perspectives 
- but essentially they would be different UIs developed as such.

~m