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

[Michael DeHaan]

>
>>> 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.
>>>
>>
>> It's blurred.  Provisioning essentially means "giving out resources", 
>> so not only can distributions be provisioned, but also packages, also 
>> things like IP addresses and hostnames (which cobbler also does if so 
>> configured).
>
> Sure, that makes sense. I suspect, though, that there are a lot of 
> intricacies to cobbler-provisioning that are maybe too detailed or 
> in-depth or not commonly-used for the sort of workflow I was 
> envisioning that pulp could support. I just worry about the interface 
> getting too crowded and complex for what should be a simple workflow 
> that just happens to span a few different types of tasks, you know?
>
I have some ideas about that about expressing simpler views for some of 
our larger users -- this is all about allowing users who just own 
certain systems to just access the bits they need without seeing the 
additional complexity.  Yes, I agree, there are starting to be too many 
fields in there.

> 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 :)

Either way I don't see what is there as being that complex, and I'm open 
to making them simpler however we can.




.. snip ...

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

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

Perhaps the new webapp could have different perspectives for repos 
versus installation, maybe that's a good solution?

>
> ~m