[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Server policy / clustering scripts
From: |
Richard Levitte |
Subject: |
Re: [Monotone-devel] Server policy / clustering scripts |
Date: |
Tue, 26 Jun 2007 08:28:17 +0200 (CEST) |
Awesome work! And, I have a couple of comments...
In message <address@hidden> on Mon, 25 Jun 2007 20:00:49 -0500, Timothy
Brownawell <address@hidden> said:
tbrownaw> There are some new files in contrib/ that should work as a
tbrownaw> simple server policy mechanism. It does not allow for a
tbrownaw> server to have multiple policies for multiple projects, as a
tbrownaw> proper policy branch implementation should.
Hmmm, if you don't mind, I'll try to make it handle multiple
projects. While I see that I can currently use this for the monotone
group of branches and handle the rest of my projects manually, I'd
like to extend this to work for any project I work on or with.
(plus I think is a good thing, it will give us the experience we
might need)
tbrownaw> serverctl-branch contains a branch name, and
tbrownaw> serverctl-signers contains a list of keys allowed to commit
tbrownaw> to that branch.
I looked, and I wouldn't be surprised if it's perfectly possible to
adapt them to multiple projects.
tbrownaw> The control branch constains include, exclude,
tbrownaw> write-permissions, and serverlist files. The include and
tbrownaw> exclude files are used to know what to sync to other
tbrownaw> servers, and the serverlist file contains a list of
tbrownaw> server "address" "key"
tbrownaw> lines, that tell what servers to sync to and what keys they
tbrownaw> use (the "key" part is used to know when to *not* forward
tbrownaw> received revisions to the other servers). The
tbrownaw> write-permissions file in this branch is used along with the
tbrownaw> standard write-permissions file, so that anyone listed in
tbrownaw> either is given write access.
Aha, I see, you have quite a different view on how this cluster should
work than I. Of course, a pool topology, where everyone knows
everyone, is a grand thing, but does both require stricter control
over the board and a great deal more trust in the pool and its
managers.
My view of the Awesome Cluster Stuff thingy is that every server admin
decides for him/herself exactly who they want to synchronise
permissions with, and therefore that the serverlist file should be
controlled locally, not through the server control branch.
This is a small matter, though, the bigger matter to me is multiple
projects.
I'll repeat it, awesome work!
Cheers,
Richard
-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
--
Richard Levitte address@hidden
http://richard.levitte.org/
"When I became a man I put away childish things, including
the fear of childishness and the desire to be very grown up."
-- C.S. Lewis