[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