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

Re: [Pulp-list] Pulp Beyond 1.0

On 04/04/2012 12:40 PM, John Morris wrote:
On 04/03/2012 09:15 AM, Jay Dobies wrote:

Looks awesome. I'd adopt pulp today if the remote filters worked. Ha ha!

Just checking, does the v2.0 plan to support 'user-defined content'
still mean software-repository-like content collections, or is pulp's
function of content synch/distribution/deployment/etc. really being
completely abstracted?

For v2.0, I like the idea of a plugin model. I'd write a plugin that
performed extra processing on repos after synching: rebuild the metadata
for filtered remote repos (ok, broken record here, and anyway I recall
pulp might have done that for me anyway when I gave it a spin), and run

I'm betting that in v2.0, grinder will cease to exist as a separate
entity and replaced with something new, sleek, pythonic and with real
inherited OO classes. Of course it may live on for awhile in a
deprecated plugin.

Hi John,

If you want to see some of what is possible with the new repository model in v2.0, you may want to take a look at PulpDist:

I'm using Pulp as the back end for an rsync-based mirrorring network with REST API control over the individual jobs.

One caveat: the client and plugins are currently implemented against a pre-alpha version of the Pulp v2 APIs (from 0.267 or so), so I wouldn't bet on it working properly with the updated plugin and REST APIs in the latest Pulp development releases. It will be a few iterations before PulpDist catches back up with the API improvements made in Pulp.


Nick Coghlan
Red Hat Engineering Operations, Brisbane

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