Re: [Monotone-devel] Server policy / clustering scripts

[Timothy Brownawell]

On Tue, 2007-06-26 at 08:28 +0200, Richard Levitte wrote:
> 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)

Could you wait a bit? I'd like to try exending this to handle the "who
can sign revisions" kind of policy as well, and that should be at least
somewhat integrated with handling multiple policy branches (so that one
policy can delegate to another). So it'd be nice if I could add both
parts together.

> 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.

Yeah, probably shouldn't the that hard.

> 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.

...that would be pretty easy, actually. Just have a non-versioned file
that would override the versioned one if present.


-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net