gitlab: Add empty instance
Add stub instance configuration which just establishes a way to have several software types(*), pass all needed info from software to instance, organizes base directory and establishes log rotation base for upcoming services. Log rotation is done with the help of cron periodicallly calling logrotate. The rotation is done in "copytruncate" mode - i.e. log file is not moved away and signal sent for service to reopen it, but instead log content is just copied to outside and there is no need for a service to reopen it's log file. The reason it is done this way, is that there is a chance of not handling such "reopen-log-file" callbacks correctly on a service side, and so the net is full of crashing reports, e.g. like this: http://serverfault.com/questions/627521/why-is-logrotate-causing-apache-to-seg-fault-each-time That's why we take a safer approach instead, even if "copytruncate" mode is risking to loose several log entries(**) on rotation. NOTE services will organize log rotation with just [logrotate-entry-<service>] <= logrotate-entry log = path/to/log/files/*.log For this to work some "!py!" magic (our way to serialize object into executable python and process it in buildout recipes) is used to process section names. The approach trick is also used for cron, e.g. logrotate registers to cron this way: [cron-entry-logrotate] <= cron-entry time = daily command = ${logrotate:wrapper} NOTE2 instance md5 are not fixed yet - we'll fix them after applying all patches in gitlab series. (*) for now there is only 1 - "gitlab", but we'll need to have "-export" and "-import" for resiliency in the future. (**) ideally such things should be done with logfs - a filesystem specializeing in logging - for client services it will look like as they just continue to write to log file, and on log service side, the rotation can happen, all transparent to client service. /cc @kazuhiko, @jerome
Showing
Please register or sign in to comment