[rt-users] RT to go? Dependency graphs?

[Bruce Campbell]

On 15 Apr 2002, Rob Walker wrote:

> On Mon, 2002-04-15 at 10:07, Johan Ihren wrote:
>
> >    To make things worse, we are not always in one place. We travel, we
> >    lose Internet connectivity (typically in hotel rooms, airports,
> >    etc). At the same time such (disconnected) occasions are often the
> >    best to get things off your personal list of things to do.
> >
> >    So what I would like to do is run RT on top of a replicated MySQL
> >    db with slave replicas in our laptops. I fully realize that I

The RIPE NCC Operation's ticket system runs on replicated mysql servers
for redundancy and general paranoia reasons.  I have considered directing
read operations to one server, and write operations to the master, but
haven't gotten around to that as yet.

Your main limitation with running replication from your master to your
laptop-slaves (the only way to do this, obviously over a secured
transport) is to ensure that each slave has enough disk to keep the entire
database.  This is not a serious problem in today's high-disk-capacity
world.

> With disconnected operations, how do you create a new ticket?  Have my
> userid in the name of it?  I don't know, myself, I haven't put that much
> brainpower into it.

I'll say 'trivial in concept, not so trivial in implementation'.

The main problem that you face is keeping the same numbering system.  Once
you realise that you don't need to, you've got a lot more options open.

Elsewhere in the thread, we're using database replication.  Cool, lets
continue to do so.

Lets assume that example.com has an rt system, with its numbering system
looking like '[example.com #321]'.  Lets assume that the database behind
this runs on 'master.example.com' in the 'rt' database.  (master:rt).

Lets also assume that master:rt is replicated to every slave (laptop) that
example.com has, as slaveX.example.com:rt .  Easy-peasy so far.

Now, if we give each slave their own database and numbering system, eg
'slaveX:slaveX' and '[slaveX.example.com #123]', we can get updates sent
back to the master server by having the master database server be a slave
for each seperate slaveX database.  The Links table can provide the
linkage between '[example.com #321]' and '[slaveX.example.com #123]'.

A little bit of magic on the master (also on the customised RT install on
each slave) keeps everything in sync between the various slaveX databases
and the main RT databases.

( I have a feeling that this is one of those things where I can see the
  solution clearly, but don't have a suitable X-dimensional drawing
  instrument to put the solution down on )


-- 
                             Bruce Campbell                            RIPE
                   Systems/Network Engineer                             NCC
                 www.ripe.net - PGP562C8B1B                      Operations