On 09/22/2009 12:23 PM, Michael DeHaan wrote:
I'm sitting in all-day meetings this week so I don't have
enough
attention cycles for debugging/fixing 2.0 items until next week.
Anyway, got something kind of interesting done... though I am not sure
if we'll ever consider it a mainstream feature. TBD.
From the master branch
If you create:
/etc/cobbler/use.couch
Cobbler will use an installed and running CouchDB instance to store
distros, profiles, systems, repos, and images.
(yum install couchdb&& /sbin/service couchdb start)
This will be instead of /var/lib/cobber/config/*.d
Note that there is *no* implemented upgrade path from .d mode, and I
don't plan on making one for this...
(Also we use the "use.couch" format since we no longer support users
writing their own serializers)
Theoretically, this could be used as the basis of a newer
self-replicating cobbler replicate mechanism, though there is the
limitation that the data would /already/ have to be available on the
remote systems.
This is mostly an experiment. It seems roughly the same performance
wise as the existing (and, admittedly, very couch-like) Cobbler JSON system.
To return to the previous behavior, rm the use.couch file and restart
cobblerd.
--Michael
_______________________________________________
cobbler-devel mailing list
cobbler-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler-devel
A couple of notes:
* there is NO security for this right now. Any user with local socket
access can manipulate the CouchDB.
* don't run this in production, again this is a experiment. Couch lists
itself as being 'alpha'
That all being said, for folks that find this interesting, we might
explore where else it can go. I notice Couch replication is manual, but
we could
keep a list of servers in Cobbler... and possibly try to get push
replication going via rsync or at least have some suggestions about
SAN/NFS usage for content (maybe?) for those kind of workflows?
TBD.
--Michael