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

[Michael DeHaan]

Máirín Duffy wrote:
> 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 image what it 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.

I think we are stuck in metaphor land :)

I also think we provide those in the form of documentation pretty well 
already.  

>
> 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.

Maybe create some mockups to see what this might look like?

>
> ~m