[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