[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]