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

Re: [Pulp-list] Pulp with minimum complexity


Mongo is a hard requirement. Pulp cannot function without it. However, it requires no configuration on your part.

qpid is theoretically optional, for now (that's likely to change in the somewhat-distant future). If you don't use the "consumer" management features of pulp and don't use the amqp "event listener" feature, pulp won't use qpid. So you can just install it and forget it.

boost isn't actually a dependency. It used to be a dependency only for building qpid for centos 5, but we no longer support running the server portion of pulp on RHEL 5 or centos 5. Thanks for noticing this; I've made a note to remove the portion of our documentation about building qpid.

In general, I think pulp can be a good fit for a simple use case like yours. The installation instructions can look a bit daunting, but I think it's mostly because we were very thorough. You can ignore the consumer section completely.

Let us know if you have any additional questions.

Michael Hrivnak

----- Original Message -----
From: "Martin Langhoff" <martin langhoff gmail com>
To: pulp-list redhat com
Sent: Wednesday, July 3, 2013 5:44:26 PM
Subject: [Pulp-list] Pulp with minimum complexity

Apologies in advance for the trollish-sounding question.

Is there a way to use pulp in trivial/basic usage of having a
controlled mirror of an http-served yum repo, serving http yum
clients... and using a much simpler setup?

(By 'controlled mirror' I mean that updates aren't mirrored in
automatically; an admin chooses whether to update the mirror whole or
selected packages.)

Pulp has the simple CLI that I am looking for; but it also has some
scary dependencies. I came expecting Python and repos served by plain
old apache... and found boost, qpid and mongodb.

In other words, are boost, qpid and mongodb core dependencies? Is
there a way to have it simple, understandable, trivially debuggable?

(In past job @ OLPC I have met similar needs with scripts that used
git internally so we could roll back to a known repo. Perhaps I should
go back to those scripts, or study whether I can live with something
like mrepo and some scripting around it?)

thanks in advance,

 martin langhoff gmail com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff

Pulp-list mailing list
Pulp-list redhat com

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