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

Re: [Pulp-list] Pulp Beyond 1.0



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


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