On May 22, 2015, at 11:58 PM, Carlos Rodríguez <carlos.rodrig...@otrs.com<mailto:carlos.rodrig...@otrs.com>> wrote: Probably I didn’t get the point, the new architecture of OTRS will enable the scheduler to perform different kind of tasks that are currently delegated to Cron and other parts of OTRS itself, That is the point - you're reinventing a fairly critical wheel here in a way that makes it more expensive and painful to run otrs. . For better or worse, cron is the system standard method for executing repeating batch workload on Unix systems. There are lots of things to hate about cron, but it's what people have, and it works well enough. Most enterprise monitors have tooling to monitor cron-based workloads built in. In a production environment with real SLAs, it's not good enough to know that the scheduler is running. You need to know that the actual tasks run (and the success/failure of those tasks may need to get reflected into a larger business service monitor). Inventing your own scheduler means that to get that information, I have to code a completely separate set of scripts to cope with your scheduler AND maintain them over time. That's a significant cost over time. But, you might say, our stuff is compatible with cron, so you don't need that....If your solution looked enough like cron to use the standard interfaces, then what's the point of NOT using cron? Every tool that reimplements standard system services costs me significant time and effort and makes it harder to give the bosses a comprehensive business dashboard that lets them see that the business is running OK. It makes it more expensive to run OTRS, and it makes it harder to upgrade a fully integrated environment because now some piece of critical workload -- the enterprise ITSM system -- is now off in a corner and not part of the other system scheduled workload. I can't optimize it along with the other scheduled work because the optimizer we use looks at the standard system service, and the otrs piece isn't there. To some extent, we're talking about a developer view of the world vs an operations view. Developers can tolerate proliferation of schedulers; for operations, more places to put stuff isn't better. If you want to try an example of this problem, try mapping the workload using the default OTRS CMDB. It'll quickly show you why this approach has problems. > in OTRS 5 you will only need to > monitor the process that controls > the scheduler is up and running to > make sure that the service will be > working. Uh, no. All that tells you is that the scheduler process exists, and maybe that that the control interface is operational. It doesn't tell you that the scheduler is actually doing work or the success of individual tasks. For that, you'd need to develop custom monitoring scripts. Fwiw, cron exposes that data via crontab (the list of scheduled tasks) and the standard process exit codes (success/fail). > For sure you still need to monitor >you http server and your DB. Same thing here. Process up != working. You will get more details about the new scheduling mechanism and other new features when OTRS 5 Beta 1 gets GA. I'll look for it. Thanks for the response. == db
_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
