Ticketing System - migration to RT Iwo Olszewski, PSNC - PowerPoint PPT Presentation

Ticketing System - migration to RT Iwo Olszewski, PSNC iwo@man.poznan.pl 7th TF-NOC meeting, December 13, 2012

Agenda • Migration background • Request Tracker • PSNC installation • Migration • Lessons learnt

Migration background Ticketing system is used by PSNC NOC to maintain issues related with PIONIER, POZMAN and services provided by PSNC • Previous solution: Own made Trouble Ticket System, >10 year old • Written in Java but by many developers and with many quick fixes • A lack of desired functionality • A cost of further development was higher than cost of new deployment

Request Tracker • A open source web and email-based bug tracking and trouble ticketing system. Written in Perl.

PSNC installation • Apache + mod_perl • Remote Oracle DB • LDAP user authentication (RT::Authen::ExternalAuth + RT::Extension::LDAPImport) • 7 operational queuess • About 140 tickets per month • Only internal users • No modifications of the original source code

Customizations Public interface for PIONIER queue (by courtesy of HEAnet) http://tickets.pionier.gov.pl

Customizations Customized email notifications for various groups of users.

Migration • Cross dependencies between system space (binary packets) and perl space (CPAN) • Documentation of RT itself is sufficient, but of plugins not. Extensive testing of LDAP plugins was needed. E.g. there are two fully functional and independent passwords for users: one form LDAP and one from RT DB • Complex DB schema. Everything remains in the DB forever. – We want to develop a tool for editing and deleting of comments – Direct import of old tickets into new system was impossible (rt command line tool was used) • „Object oriented ” code in perl is terrible to read • Polish translation of RT interface is incomplete and often misleading • Small possibilities of ticket list customization on dashboards (e.g. font color according to ticket state)

Lessons learnt • Even with a small „ client ” (4 NOC engineers) requirements constantly changing • „ If default settings will not be sufficient we will change them later ” is a bad idea (notifications, lifecycle, permissions) • Most of users requests are about reproducing functionalities and ways of using of the previous system

Thank you