Pass The Conch (by alaric)

In The Lord of the Flies, the children (marooned on an island and working out how to organise themselves to survive) develop a technique for managing debate: they use a conch shell as a token to represent who currently holds the floor. Without the conch, you can't talk; you have to wait your turn.

Cut to the Real World of Commerce and Industry: in various places I've worked, there's been a number of shared resources which can only be used by one person or agent at a time. Mainly, these have been testing servers - if you are doing performance analyses, or looking for timing-related bugs, you can't have anyone else running jobs on the same server as you, or they'll compete for resources and interfere with your results. Or perhaps there's only one "data area" of some kind, and two attempts to use it at once will lead to catastrophe.

This is usually handed by asking around the office or in IRC: "Is anyone using X?", hoping that anybody who is is still around (as opposed to too busy doing something to notice the request, or leaving a job going while out to lunch). Because of the unreliability of this system, and the inability to integrate it with automatic systems that need to claim resources (such as automatic test systems), I have often wished for a software tool to manage it. Which would, naturally, be called "conch".

Here's my feature wishlist:

• Network-based. A central conch server tracks a set of conches, accessed via a Web interface or a direct protocol. The direct protocol should have a command-line client for scripting, and be trivial to write native client libraries for in programming languages.

• Authenticated. No need for super security, but we want to keep out casual mischief-makers, so require authentication to use the server; to enable easy integration with other workflow apps, support htaccess files, "trust the upstream proxy" (eg, accept HTTP auth usernames and ignore any passwords sent), or running an arbitrary shell command to validate a username/password pair. It might be used across the public Internet, so allow for SSL wrapping the connection. The command line client should, by default, use the username and password from ~/.conch or prompt for them (and save them in ~/.conch) if not specified.

• The ability to create or delete resources, to claim a currently-free resource, to release a resource you hold, or to "force" the release of a resource that somebody else holds (if they forget and go home, etc).

• The ability to list the status of a resource, to list the resources held by a specific user, to list the resources held by yourself, to list all users with resources held, and to list all resources.

• Fine-grained access control (per-user rights limitation) might be handy, but probably not useful for the first draft.

• An IRC bot might be cool - at least for logging resource claims/releases and commands to list current state; maybe for resource claims/releases as well, if users are either trusted by nick or authenticate via a private message.

If this doesn't already exist, it should be easy to build (something could be knocked up with awful and sql-de-lite in a day or two, I bet!)...

3 Comments

• 

  By @ndy, Tue 20th Sep 2011 @ 12:23 pm

  Making it avahi/rendevous/zeroconf based might be interesting. That way it could start off fairly adhoc but reliable and also be integrated into larger infrastructures.

  Also, do you need a concept of queues so that people can get the resources as they become available?

• 

  By alaric, Tue 20th Sep 2011 @ 1:10 pm

  Zeroconf: That would let clients find active conch servers in their environment, but is that a big win over just telling them a hostname to try?

  Queues: That's a good point. Given the ability to force somebody to release a resource, we really need a way to send people asynchronous messages anyway (a "block for a message" operation in the native protocol, and an AJAXy thingy in the Web UI), so that could also be used as a way to tell people they'd been granted a resource they are waiting for.

  In effect, you'd keep a list of waiters on each resource. When the resource is released, if there are waiters, find the top weighter (oldest, unless you want to introduce priority), give them the resource, and send them a message about it. Otherwise, mark the resource as free.

  To support IRC/Jabber/etc bots, you already need a mechanism to get a stream of "global messages" on resource claims/releases anyway - that can be extended to include getting copies of messages for users, so bots can notify the users directly.

• 

  By MD, Wed 21st Sep 2011 @ 12:27 am

  couldn't the principle of something like a job queueing system like pbs function too - where the resource that you're scheduling is an interactive session on the system, instead of a run of a particular command?

Other Links to this Post

RSS feed for comments on this post.

Leave a comment