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





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


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