> On 8 February 2013 16:37, David Boyes <dbo...@sinenomine.net> wrote: > > Actually, it’s not that bad. > With all due respect David your system is highly customised and you must > have the people power (or skills) to maintain your custom setup. > I don't want to have to do any of that custom piece, and more to the point I > shouldn't have to do that.
I think you misinterpreted my reply. I was replying to Gerard's note on the difficulty level of storing connection info with the "not that bad" comment to illustrate that a solution like we're discussing wouldn't be that hard to implement. I'm totally with you on the "we shouldn't have to invent hacks like this" -- that idea with git is a workaround, and for enterprise-grade infrastructure such as OTRS purports to be, hacks like that shouldn't be necessary. We're not breaking new ground here; most of what we're discussing has long ago been done in other tools, and there's little excuse for not learning from the past. (I'm coming from a mainframe background, so the fact we have to do any of this HA stuff at the application level continues to amaze -- the mainframe world had this kind of basic system integrity stuff in 1982 for *everything*, not just single apps inventing it as they go along. ) I tossed out the git idea as one way we worked around the problem. It's fugly, but it does work as a stopgap solution. There is some unavoidable formalism that it assumes in terms of administrative practice, but nothing that you wouldn't expect from good practice where downtime has a substantial price attached to it. We built it on git precisely because we didn't have to invent the management of the configuration versioning, and we used it elsewhere, and it didn't require modifying OTRS beyond a simple init script change, which is easily managed (in fact, if I were doing it now, I'd pull that step out of the OTRS init script and put it into a new script with appropriate dependencies). It shouldn't be necessary, but it lets us cope with the problem without rewriting the universe. There are a lot of things I'd like to see added for HA and system resilience in OTRS. Matter of time and resources, I'd say. It probably would be a good idea to discuss it here, and help them define some requirements for what a really resilient enterprise OTRS system would look like. My "starter" list would be: 1) tolerate/exploit clustered database engines 2) explicit interaction with load balancing solutions (start with LVS, move on to the hardware solutions later) 3) rationalization of configuration data 4) management of configuration data 5) work on lock management in the database (there are a lot of places where a table-level lock is used by default that could be much more efficiently use row-level locks) 6) More work on index definition for high-use tables 7) Allow explicit use of different database extent storage pools in the database scripts to tune data placement (indexes on SSD, data on slower disk, for example). 8) More formal work on the SOAP interface. XML-RPC only goes so far. 9) a instrumentation interface to determine how well the application is performing (per-request timing, transaction overhead would be a good start) --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
