[Pulp-list] Pulp Beyond 1.0

Nick Coghlan ncoghlan at redhat.com
Thu Apr 5 01:25:26 UTC 2012


On 04/05/2012 01:19 AM, Jay Dobies wrote:
> When I say "the Pulp model", it's not that you're mapping unit metadata
> on to a rigid structure. The content type definition gives Pulp some
> clues so it can store it properly to make querying optimized, but at the
> end of the day the structure and contents of the unit metadata are
> pretty much up to the discretion of the plugin developer.

And you can even dial things down to the level that PulpDist currently 
does: bypass large chunks of Pulp altogether and only use the parts you 
need.

While I make use of the REST API to trigger jobs and the sync history 
tracking, the current set of PulpDist plugins actually write directly to 
user-specified filesystem paths, don't store any content metadata in the 
Pulp repo and rely on an external trigger for periodic sync operations.

Longer term, the level of integration with Pulp will increase (e.g. when 
implemented, the delta plugins will likely use the Pulp content storage 
area, all the plugins will start recording some content metadata in the 
repo to indicate what trees are currently available and I'll start using 
Pulp's scheduling engine to trigger automatic updates), but it's pretty 
cool that the plugin model is flexible enough that you can pick and 
choose which parts you want to adopt at any given point in time and 
still have something useful that can be deployed.

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Engineering Operations, Brisbane




More information about the Pulp-list mailing list