Re: [rt-users] Input from any other University or similar
Joby, This probably doesn't answer your question, and is mainly just for people searching for university/higher-ed deployments. We're using RT for all IT ticketing/tracking on campus. Internally, our people love it. Externally, there has been some confusion with e-mails coming from people (eg. me) but not from my e-mail address: But that's a bootstrapping/eduction-re-education-re-re-education issue. In general, the external response has been very positive as well. We're looking hard at how to bring in other non-IT areas that have ticketing and tracking needs. Getting RT to use Oracle RAC as its database is a next step for us, before we can offer the kind of performance and reliability we insist on before bringing others in. I have been playing with having multiple RT application servers in front of a database - The app servers are running differently branded copies of the same RT - So IT looks different from Building Grounds looks different from Security looks different from ... but they share the tracking database, so ticket numbers never overlap, and there is a common repo for reports to run off, and you can link/refer tickets across ticketing systems (BG needs to electrically wire a room, but needs IT to provide phone/data cabling who in turn need Purchasing to approve a PO ... All using different RT instances visually customized for their workflow). -- Matthew Keller Information Security Officer Network Administrator Computing Technology Services State University of New York @ Potsdam Potsdam, NY, USA http://mattwork.potsdam.edu/ ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Input from any other University or similar
Bob Goldstein wrote: With our current experience with our implementation, we have been considering some sort of Federated solution -- entirely separate instances of RT that know about each other and that can communicate effectively (transfer/link tickets). Not sure what entirely separate means, if you can transfer tickets. Yeah that was a bit unclear. We are considering an extension which would allow you to transfer a ticket to an other instance (separate database, etc) of RT. We do set up entirely separate instances (same core codebase, but separate databases, separate config files, separate customized code (of which there is little) for departments. But they are truly separate, no transfer of tickets. I tell people I don't want to set up multiple instances in a single department, in part because they probably do want to transfer tickets, even if they don't know it yet. Do you charge departments for the service? How are you hosting the various instances? We've considered dedicated servers, dedicated VMs, or a cluster of that services multiple vhosts. jbw ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Input from any other University or similar
All, I've been running RT in production for almost 2 years in a fairly large implementation for just the University of Washington's Computing and Communications (central IT infrastructure). We're just about to 220K tickets, after a fairly slow roll out. Last week we had more than 2700 new tickets -- and that is during Summer our slowest period. But now we're in the process of investigating offering RT as a service to the rest of the campus, which would involve supporting several similarly sized departments, and many smaller departments. I am curious if there is anyone else on the list that is currently doing something similar. Yes. With our current experience with our implementation, we have been considering some sort of Federated solution -- entirely separate instances of RT that know about each other and that can communicate effectively (transfer/link tickets). Not sure what entirely separate means, if you can transfer tickets. We do set up entirely separate instances (same core codebase, but separate databases, separate config files, separate customized code (of which there is little) for departments. But they are truly separate, no transfer of tickets. I tell people I don't want to set up multiple instances in a single department, in part because they probably do want to transfer tickets, even if they don't know it yet. bobg Any input or experience would be useful. Thanks, -- Joby Walker CC SSG, University of Washington ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Input from any other University or similar
Bob Goldstein wrote: With our current experience with our implementation, we have been considering some sort of Federated solution -- entirely separate instances of RT that know about each other and that can communicate effectively (transfer/link tickets). Not sure what entirely separate means, if you can transfer tickets. Yeah that was a bit unclear. We are considering an extension which would allow you to transfer a ticket to an other instance (separate database, etc) of RT. I might be interested in that extension. I had crafted a one-way extension, so that tickets from a Clarify system could be transferred to RT. Basically, Clarify would send email with a special format, and RT would parse that email and create a new ticket, tracking the Clarify ID in a custom field. (So any future appends to the Clarify ticket could be sent to RT and appended to the proper RT ticket.) However, this was one-way. Clarify never received any updates when the RT ticket was modified, and there was no back-transfer mode. Depends on your need, of course, but an easy course would just be to create an RT ticket, and have it contain a web link to a ticket in the other RT instance. In my case, though, we rarely need this, so I've ignored it. We do set up entirely separate instances (same core codebase, but separate databases, separate config files, separate customized code (of which there is little) for departments. But they are truly separate, no transfer of tickets. I tell people I don't want to set up multiple instances in a single department, in part because they probably do want to transfer tickets, even if they don't know it yet. Do you charge departments for the service? No. But we do minimal support. It works for us because RT pretty much works as needed, and consultants don't really need much training to use it. And the way I have the core code shared, any mods I make to my own instance can be shared across all instances (on the vendor branch) or not (on the user branch), so there hasn't really been any call for customizations that I didn't want for myself as well. BTW, I did propose that the rest of the university replace Clarify with RT, and that I'd be willing to do that for a fee. The people involved really like preminum service, formal SLAs, etc, which is ok but beyond my free resources. But so far I don't think they are interested. How are you hosting the various instances? We've considered dedicated servers, dedicated VMs, or a cluster of that services multiple vhosts. At the moment, I have two boxes, one for apache and one for mysql. But it was set up initially so that I could have multiple web servers (via DNS rotation, or other load balancer), or could put the db for each instance on a separate mysql box. I can't imagine a single instance so large that would overwhelm a single mysql server (at least before we move to mysql 5.x clusters) so we're prepared. bobg jbw ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] Input from any other University or similar
All, I've been running RT in production for almost 2 years in a fairly large implementation for just the University of Washington's Computing and Communications (central IT infrastructure). We're just about to 220K tickets, after a fairly slow roll out. Last week we had more than 2700 new tickets -- and that is during Summer our slowest period. But now we're in the process of investigating offering RT as a service to the rest of the campus, which would involve supporting several similarly sized departments, and many smaller departments. I am curious if there is anyone else on the list that is currently doing something similar. With our current experience with our implementation, we have been considering some sort of Federated solution -- entirely separate instances of RT that know about each other and that can communicate effectively (transfer/link tickets). Any input or experience would be useful. Thanks, -- Joby Walker CC SSG, University of Washington ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com