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

[Michael DeHaan]

Máirín Duffy wrote:
> Michael DeHaan wrote:
>> Mairin Duffy wrote:
>>> Michael DeHaan wrote:
>>>> Sorry for the late reply, I was looking over the pulp features list 
>>>> up on the Wiki a few weeks ago.
>>>>
>>>> Serious question -- it seems the features mentioned for Pulp (other 
>>>> than interface features) are suitable to be added to Cobbler in 
>>>> ways that requires people use less tools
>>>
>>> Where would the interface live, then?
>>>
>>> On top as a separate piece, making calls to a cobbler server? Does 
>>> that mean pulp would be the interface piece only?
>>>
>>> ~m
>>
>> Spacewalk maybe?
>
> 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

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"...


>> FWIW, I'm thinking about making cobbler-web a seperate package in a 
>> future release as well (I'm pondering moving to Rails to allow some 
>> content to be better accessed by ovirt, and also to make better use 
>> of mcpierce's rubygem-cobbler module), and am considering various 
>> upgrades related to Cobbler's new ACL support, so there's time to 
>> consider improvements to the way repos are being managed today as 
>> well. Ultimately I think where such UI bits go depend on what you 
>> would want to see.   From the list of functionality we see now I 
>> don't see why they couldn't be in there.
>
> By "in there" do you mean cobbler web or do you mean spacewalk?

Cobbler web.

>
> 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).


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

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

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.

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.

>
> ~m