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

Re: [Pulp-list] Pulp Beyond 1.0

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.


Nick Coghlan
Red Hat Engineering Operations, Brisbane

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