monotone-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]