On Apr 5, 2011, at 9:00 AM, Steve Huff wrote:
>
> On Apr 5, 2011, at 8:50 AM, Jeff Johnson wrote:
>
>> If there is interest at RPMForge in using MongoDB as an alternative to
>> traditional mirroring of "repository" metadata, I will adjust my priorities
>> accordingly, and attempt to host an RPMForge MongoDB containing package
>> metdata
>> sooner rather than when a round 'tuit is found.
>
>
> this does sound interesting; as a mirror maintainer, i'm aware that we
> sometimes get bitten by the scenario of syncing metadata while it's being
> generated at the master, and thus receiving b0rken metadata.
>
> just to make sure i follow: if you were to set up such a mirror, i should
> then run a MongoDB instance on my own RPMforge mirror, set it to replicate
> from your MongoDB, and then write some script that generates the repomd.xml
> etc. by querying my own local MongoDB? if so, that sounds like a workflow
> i'd be interested in.
>
Yep, that's the plan (or at least the depsolver part of the plan, @rpm5.org
has the mongo-c-driver embedded, there's *lots* of usage cases).
If interested, most of the deployment will be discussed at
<[email protected]>
And the initial hosting will be through http://mongohq.com so
sign up for a "free" account to familiarize yourself with
the admin interface there. The mongohq databases run
in AWS instances, so there is high bandwidth available
somehow if you wish to do your own thing. MongoDB is
just another form of spewage, this time JSON/BSON rather
than XML or SQL.
I'd also suggest reading up on MongoDB, tutorial starts here:
http://www.mongodb.org/display/DOCS/Tutorial
Not also that my immediate focus is on @rpm5.org implementations
to make a distributed MongoDB exist for client-side development.
All that means is that -- for many reasons -- I'm less interested
in compatibility tools for yum etc atm.
(aside)
There is a proof-of-concept client-side replacement for server-side
createrepo in tools/rpmrepo.c @rpm5.org that I will be using for develoment.
But since its just a MongoDB distributed store and bindings exist
for almost every interpreted language, well, there's hardly
any reason to look at my C implementation of rpmrepo(1).
(aside)
There are most definitely reasons for incremental distribution of package
metadata, as well as client-side rather than server-side generation of the
metadata to be fed to yum/smart/urpmi etc etc.
The ability to create analogues of primary/filelists/other markup spewage
is already implemented and functional @rpm5.org:
rpm -qp --wnh:primary.mongo *.rpm | monggo host:port -u user -p password
...
MongoDB 1.8.0 (using JavaScript 1.8.5) is the targeted server deployment; SRPM's
for these packages exist in Mandriva Cooker now.
Establishing organizational administrivia, like hierarchical naming for
the usual candidates of {distro,repo,arch,...} into a mongodb:// URI
is what the current focus is on. Takes a bit to find consensus on
public hioerarchical URI's, any feedback is welcomed.
OK: I will attempt to set-up a RPMForge MongoDB, the only rate limitation
there is having to pull *all* RPMForge packages onto a local disk in
order to extract the metadata. todo++ (but note the size of the necessary
download and plan your expectations accordingly).
todo++
hth
73 de Jeff
_______________________________________________
users mailing list
[email protected]
http://lists.rpmforge.net/mailman/listinfo/users
