#beanstalkd as Job Queue for TYPO3 infrastructure Moved some things to \url{https://notes.typo3.org/p/RabbitMQ} ~BB ##To be considered: Martin Bless: I skimmed over threads in the Beanstalkd Google Group. It seems, that the queue is ALL IN MEMORY. This might mean that a server crash will make all tasks vanish! Steffen: There's the possibility of a binlog, see \url{https://github.com/kr/beanstalkd/wiki/faq} and \url{https://github.com/pda/pheanstalk/#usage-example} Fabien: Besides the binlog, the application must have the ability to recover everything ##Current use ## Fabien: I have in the pipline a prototype to make communicate through **Beanstalkd **the documentation rendering server and the documentation delivery server. What format is used? Looks like using JSON is a good idea. ##Superivison of the queue Zabbix could be use to monitor the health of the queue. Code example? ##Idea: central message bus for extensions/docs/translations (Steffen) * Once a new extension is uploaded to TER, jobs are created * ter\_fe2 imports the extension into its data structures (implemented via scheduler) * Doc rendering renders documentation (implemented via scheduler) * translation server pulls extension to make them available for translation (implemented via nightly cron) * ZIP file is created (implemented via scheduler) * Replication to new main mirror (ter.typo3.org) is triggered (implemented via ~15min cron) * ... * Once a new patch set is pushed to Gerrit * Gerrit triggers docu rendering, if it's inside a Documentation repo. Rendering reports back with a comment that the documentation is rendered on a certain URL (but not the in the offical docs) (not implemented, yet) * Jenkins triggers new build to execute tests (currently done via a SSH connection Gerrit<->Jenkins, thus low prio) (implemented via gerrit ssh stream) * Once a change is merged * Gerrit triggers docu rendering, official docs updated (not implemented) * translation server updates (enable translation before release?) (implemented via cron) * Jenkins triggers build (not implemented) * Forge closes issue (via very slow cron job) * Forge refreshes repository view (via very slow cron) * Translation server announces new translation packages * TER server fetches them (implemented via nightly cron job) * Forge: Team members added * Triggers Gerrit to sync permissions for that project (implemented via cron job ~30min) * Forge: New project is created * Git repository is created (not implemented yet) * Packaging server (in case of v4/v6) or Jenkins (FLOW3) uploads a new release * notifies get.typo3.org (implemented via cron job ~10min) * Once a documentation is rendered * Documentation delivery server synchronize the docs (party implemented) * TYPO3.org: New extension key is registered * forge-project created (not implemented) * git repo created (not implemented) ##Requirements * Security Check * BackUp Check * Cloud Service? * Monitoring Inside * Monitoring via Zabbix