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