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

[Mairin Duffy]

Michael DeHaan wrote:
 > Máirín Duffy wrote:
 >> Michael DeHaan wrote:
 >> Backtracking a bit, I had one question. Is it a concern that if 
the-artist-formerly-known-as-pulp becomes a part of cobbler, that it 
would be difficult to tie in pulp functionality with a different 
provisioning system? I had thought the original notion of having two 
separate apps was partly to provide that kind of flexibility since 
sometimes folks who manage their software distribution might not have 
any control over the provisioning of machines or the software/process 
used to provision the machines. Would pulp still be able to tie into 
another provisioning system if it was built into cobbler?
 >>
 > Basically we have two classes of Cobbler users now:
 >
 > - ones who use the repo management bits
 > - ones who don't

Well, to be fair my concern/focus isn't on Cobbler users, but on 
RHEL/Fedora users trying to manage and deploy systems. I would guess 
that the folks who are using cobbler in professional deployments today 
are doing so because they have a great more deal of leverage over the 
selection of management tools to use than the hypothetical users my 
original concern was considering.
 >
 > I see the pulp features as being extensions on the existing repo 
management bits, for the most part, though we'd probably want to discuss 
them one by one on the lists.
 >
 > I am not sure everyone really wants a seperate app for each function 
of things, more so, they just want tools that are easy to integrate 
together.
 >
 > Using the cobbler repo management bits w/o the provisioning aspects 
works today, so yes, it would not require that anyone use "cobbler 
distro add" or "cobbler profile add" and similar features, just "cobbler 
repo add"...

Okay that's good to know.

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

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.
 >
 >> Let me explain how I'm thinking this could work, based on some of 
the stuff I've been working on My Fedora with J5, Eve, Luke, and Toshio. 
Maybe it's not applicable, or maybe it is or would spark a good idea. As 
you know, koji and bodhi are separate applications, geared for different 
tasks (building packages and pushing updates) but those tasks are 
related. Each is part of a larger 'package maintenance' workflow. (There 
are other overarching workflows involving the two tools too, such as 
release engineering but let's focus on pkg maintenance for now.) Our 
plan for the My Fedora webui is to provide integration between the two 
apps, koji and bodhi, in one UI tailored for a basic package maintenance 
workflow. But the bodhi and koji UIs will still remain, they're not 
going away, for more specialized tasks related to each respective 
domain. Does that make sense?
 >
 > Perhaps.  I guess a related question is, does anyone really like that 
these are two seperate apps?  I use bhodi for pushing updates, but never 
really log into koji and just go by the email it sends me.  If they were 
better integrated where I could see the build logs when I was looking at 
an update -- basically in the same app view,  that might be easier.

Well, it's hard to say with My Fedora still not live and ready for use 
yet (although we're getting closer!) From initial interviews and quick 
paper prototyping with some of the folks here in Westford who use both 
tools in package maintenance, I did get the feeling that there was a 
desire to tie the two tools into one workflow, in a simplified manner, 
but still allow for digging back into the original app (be it koji or 
bodhi) in the exceptional cases where more detailed information/actions 
needed to be taken. (Your example is one we handle this way - we tell 
you in My Fedora if your build failed, and if you want to probe further 
we link you to the appropriate spot in bodhi to pull up the build logs 
to figure out what went wrong.) We'll learn more about whether or not 
this suggested model works when My Fedora goes into production and 
starts getting used.
 >
 >>
 >> 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?)
 >
 > 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?

~m