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