[Pulp-list] Pulp Beyond 1.0

Nick Coghlan ncoghlan at redhat.com
Wed Apr 4 03:43:13 UTC 2012


On 04/04/2012 12:40 PM, John Morris wrote:
> On 04/03/2012 09:15 AM, Jay Dobies wrote:
>> http://blog.pulpproject.org/2012/04/03/pulp-beyond-1-0/
>
> 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
> repoview.
>
> 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:
http://pulpdist.readthedocs.org

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.

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Engineering Operations, Brisbane




More information about the Pulp-list mailing list