Multiple Instances or Another Queue

RT Users
1

Hi,

I’ve been using RT since 3.8.8 for our internal IT requests. It works well but I’ve never really
done much with Queues. I created one extra one to segregate some specific issues but that’s it.
Also, I’m the only one who’s had to use it in anger until now. My understanding of RT and
specifically Queue separation (e.g. by department, etc.) is very limited. As an aside, I recently
upgraded to RT 4.0.7 and implemented Authen-ExternalAuth which works great.

We now have a requirement to use RT for external support for a new department within our
organisation. Originally they requested a new instance of RT to be set up (they wanted a separate
database). I have been looking at several options to do this but I’m not satisfied with any multiple
instance set up configurations. I’m really unsure of the best way to move forward. The options that
I see so far are:

  1. Use a new queue for the new department, isolating administration and users for that department to
    that queue.
  2. Run two instances by following http://requesttracker.wikia.com/wiki/MultipleInstances (requires
    hacking the code to make this work on 4.0.7).
  3. Run two installations side by side having compiled with different configuration options.

I am curious to know what you all think about these options and what is the recommended way to do
what we want to do.

I can see pros and cons for each of the choices above. A separate instance is so clear cut but the
future upgrades and maintenance issues bother me. Personally I would choose number one but I need
reasons to take back to the new department head so I can explain my choice and convince him it is
the right thing to do. I would also need some pointers on the best way configure that option.

Many thanks,
Tom

Tom Robinson
System Administrator

MoTeC Pty Ltd

121 Merrindale Drive
Croydon South
3136 Victoria
Australia

T: +61 3 9761 5050
F: +61 3 9761 5051
E: tom.robinson@motec.com.au

signature.asc (250 Bytes)

2
  1. Use a new queue for the new department, isolating administration and users for that department to
    that queue.

A very reasonable option that works Right Now without much additional
effort. Consider if the new department is going to want lots of queues
down the road, or custom visual branding, etc. Anything you do in a
single RT will affect all departments using it, so you need flexibility
from your users.

The question to answer to determine between 1 and 3 (2 is right out) is
“How customized do you predict the new department is going to need their
RT?” (i.e. why do they want a separate database).

  1. Run two instances by following http://requesttracker.wikia.com/wiki/MultipleInstances (requires
    hacking the code to make this work on 4.0.7).

The hacks described in that wiki page lead to more complications than
they are ever worth.

  1. Run two installations side by side having compiled with different configuration options.

This is the dead simple option, and completely reasonable. Upgrades
within the 4.0 stable series are intentionally small and designed to be
safe. When you do a larger upgrade to 4.2 down the road, you can
upgrade one install and use what you learned to upgrade the other that
much quicker. If you keep local customizations clean, upgrades are
pretty painless (esp. starting from 4.0.7).

FWIW, Best Practical uses option #3. The RT source code is tiny, and it
gives us clean separation between public facing RT and internal RTs.
The added overhead of administering more than one install is not much
once you have processes set down for doing it to a single RT.

3
  1. Use a new queue for the new department, isolating administration and users for that department to
    that queue.
    A very reasonable option that works Right Now without much additional
    effort. Consider if the new department is going to want lots of queues
    down the road, or custom visual branding, etc. Anything you do in a
    single RT will affect all departments using it, so you need flexibility
    from your users.

The question to answer to determine between 1 and 3 (2 is right out) is
“How customized do you predict the new department is going to need their
RT?” (i.e. why do they want a separate database).
I see that this could be a good option but less flexible.

  1. Run two instances by following http://requesttracker.wikia.com/wiki/MultipleInstances (requires
    hacking the code to make this work on 4.0.7).
    The hacks described in that wiki page lead to more complications than
    they are ever worth.
    Yes, that made me quite hesitant.
  1. Run two installations side by side having compiled with different configuration options.
    This is the dead simple option, and completely reasonable. Upgrades
    within the 4.0 stable series are intentionally small and designed to be
    safe. When you do a larger upgrade to 4.2 down the road, you can
    upgrade one install and use what you learned to upgrade the other that
    much quicker. If you keep local customizations clean, upgrades are
    pretty painless (esp. starting from 4.0.7).

FWIW, Best Practical uses option #3. The RT source code is tiny, and it
gives us clean separation between public facing RT and internal RTs.
The added overhead of administering more than one install is not much
once you have processes set down for doing it to a single RT.
Great to have this kind of feedback. Many thanks. I’ll give option #3 a try as it gives good
separation of the departments and will allow them to customise it more completely.

Thanks again,

Tom

Tom Robinson
System Administrator

MoTeC Pty Ltd

121 Merrindale Drive
Croydon South
3136 Victoria
Australia

T: +61 3 9761 5050
F: +61 3 9761 5051
E: tom.robinson@motec.com.au

signature.asc (250 Bytes)

4

Le 21/09/2012 ? 15:21:54+1000, Tom Robinson a �crit

Hi,

I’ve been using RT since 3.8.8 for our internal IT requests. It works well but I’ve never really
done much with Queues. I created one extra one to segregate some specific issues but that’s it.
Also, I’m the only one who’s had to use it in anger until now. My understanding of RT and
specifically Queue separation (e.g. by department, etc.) is very limited. As an aside, I recently
upgraded to RT 4.0.7 and implemented Authen-ExternalAuth which works great.

We now have a requirement to use RT for external support for a new department within our
organisation. Originally they requested a new instance of RT to be set up (they wanted a separate
database). I have been looking at several options to do this but I’m not satisfied with any multiple

If they really need a separate database I personnaly choose the 3rd
solution.

instance set up configurations. I’m really unsure of the best way to move forward. The options that
I see so far are:

  1. Use a new queue for the new department, isolating administration and users for that department to
    that queue.
  2. Run two instances by following http://requesttracker.wikia.com/wiki/MultipleInstances (requires
    hacking the code to make this work on 4.0.7).
  3. Run two installations side by side having compiled with different configuration options.

I am curious to know what you all think about these options and what is the recommended way to do
what we want to do.

IF (I don’t known you company) they don’t really need a separate database I
would choose the first solution. Because you can configure RT to allow
change a ticket from your queue to other queue.

Event if now you don’t need this feature that’s not mean you don’t going to
appreciate.

If you do with two installations you can do that.

Regards.

JAS
Albert SHIH
DIO b�timent 15
Observatoire de Paris
5 Place Jules Janssen
92195 Meudon Cedex
T�l�phone : 01 45 07 76 26/06 86 69 95 71
xmpp: jas@obspm.fr
Heure local/Local time:
mer 26 sep 2012 17:15:17 CEST