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
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
