[Pulp-list] Pulp Beyond 1.0
Jay Dobies
jason.dobies at redhat.com
Wed Apr 4 15:19:12 UTC 2012
On 04/03/2012 10: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?
It's still called a "repository" but that's just a naming thing and,
from the Pulp level, has absolutely no yum connotations whatsoever.
The importer's task is taking the content units from an external source
and fitting them into the Pulp model; Pulp doesn't care where they came
from, how they got to the importer, or even what's inside of them.
The distributor then takes the Pulp model and turns them into whatever
is needed to fulfill what it considers a publish. That may mean turning
it into a yum repo, assembling them into an ISO, or rsyncing them into a
legacy system.
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.
Let me know if you have any more questions. I started down this path of
explanation in that blog entry but decided to aim for a more summary
view of 2.0 instead, so I understand if there are parts that are still a
bit fuzzy.
> 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.
>
> John
--
Jay Dobies
Freenode: jdob @ #pulp
http://pulpproject.org | http://blog.pulpproject.org
More information about the Pulp-list
mailing list