[Pulp-list] How about we just merge these core features into Cobbler?
duffy at redhat.com
Fri Sep 12 19:10:34 UTC 2008
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
>>>> So I was thinking that maybe pulp could be a UI geared to the
>>>> current Satellite
>>>> 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
> 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
Okay, I understand now, although I'm still not sure I agree or disagree
> 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.
More information about the Pulp-list