[Pulp-list] How about we just merge these core features into Cobbler?
duffy at redhat.com
Fri Sep 12 17:33:13 UTC 2008
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?
> 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?
> 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?
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.
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?
So I was thinking that maybe pulp could be a UI geared to the current
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.
More information about the Pulp-list