An error occurred fetching the project authors.
- 20 Oct, 2016 1 commit
-
-
iv authored
Like for 61177775. I've manually reviewed git diff 8-7-stable 8-8-stable -- files/gitlab-config-template/gitlab.rb.template \ files/gitlab-cookbooks/gitlab/attributes/default.rb on omnibus-gitlab repository. There are only changes on postgresql and registry options, which are not relevant for us.
-
- 07 Aug, 2016 1 commit
-
-
Kirill Smelkov authored
I've manually reviewed git diff 8.6.5+ce.0-0-g342f8be..8.7.9+ce.1-0-gf589ad7 -- \ files/gitlab-config-template/gitlab.rb.template \ files/gitlab-cookbooks/gitlab/attributes/default.rb and modulo trusted proxies there are no interesting changes for us.
-
- 02 Aug, 2016 1 commit
-
-
Kirill Smelkov authored
I manually reviewed $ git diff 8.5.1+ce.0-1-ge732b39..8.6.5+ce.0-0-g342f8be -- \ files/gitlab-config-template/gitlab.rb.template \ files/gitlab-cookbooks/gitlab/attributes/default.rb in omnibus-gitlab, and module proxy_cache and http2 changes, which we already handled in 2 previous patches, there is nothing more interesting for us.
-
- 28 Feb, 2016 1 commit
-
-
Kirill Smelkov authored
I manually reviewed $ git diff 8.4.2+ce.0-3-g68d5ee8..8.5.1+ce.0-1-ge732b39 \ files/gitlab-config-template/gitlab.rb.template \ files/gitlab-cookbooks/gitlab/attributes/default.rb in omnibus-gitlab, and module proxy_set_header change, which we already addressed in previous patch in Nginx config, there are no more changes for us.
-
- 11 Feb, 2016 2 commits
-
-
Kirill Smelkov authored
I manually reviewed files/gitlab-config-template/gitlab.rb.template files/gitlab-cookbooks/gitlab/attributes/default.rb from omnibus-gitlab 8.4.2+ce.0-3-g68d5ee8 and picked up changes: - unicorn OOM killer memory limits were raised up (because gitlab is now more memory hungry according to talks on gitlab.com) https://gitlab.com/gitlab-org/omnibus-gitlab/commit/f8ee4a19 - there is no default limit for nginx client_max_body_size - it just goes to gitlab-workhorse as is at any size https://gitlab.com/gitlab-org/omnibus-gitlab/commit/78862837 /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Slapos'ify config updates brought by sync with omnibus-gitlab (see merge in the previous patch). Changes: - default visibility levels gone away (see merge commit and https://gitlab.com/gitlab-org/omnibus-gitlab/commit/b5ebbab3 ) - there are new settings for GitLab Pages and Elasticsearch, which are EE only and thus we do not support them. - there are new settings for auxiliary cron-like jobs, which we do not support for now, since they are used either for CI (not supported by us) or EE features. Configuration files that were synced, but did not changed are also marked as updated, so it is easier to track their changes to upstream in the future. /cc @kazuhiko, @jerome
-
- 17 Jan, 2016 10 commits
-
-
Kirill Smelkov authored
Sidekiq[1] is used in GitLab as background jobs manager - i.e. if a request handler needs to spawn some non-light job - it adds it to sidekiq queue (in Redis) and relies on sidekiq service to later pick this job up and execute it. The service is setup with just to run bin/gitlab-sidekiq with appropriate queues (extracted from omnibus-gitlab) and appropriate settings to controlling GitLab's sidekiq Out-Of-Memory killer[2]. NOTE Unlike unicorn OOM killer, Sidekiq memory killer just makes sidekiq processes to be SIGKILL terminated and relies on managing service to restart it. In slapos we don't have mechanism to set autorestart=true, nor bang/watchdog currently work with slapproxy, so we setup to do such monitoring ourselves manually with here-introduced watcher-sigkill program. NOTE2 sidekiq promise, because it is rake/gitlab based, is slow to load/run and thus is put into etc/promise.slow/ [1] http://sidekiq.org/ [2] https://gitlab.com/gitlab-org/gitlab-ce/blob/1322bd78/doc/operations/sidekiq_memory_killer.md /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Go through nginx configuration templates and convert them to jinja2 with slapos parameters (reminder: names and default values are imported from omnibus-gitlab 8.2.3+ce.0-0-g8eda093), except commenting out features we do not want to support (yet ?). As nginx is a reverse-proxy, i.e. it integrates all internal services and works as frontend to them, our gitlab service is now ready to listen and talk to the world over (standard to slapos services backend) IPv6. Nginx also acts as SSL termination point - for it to work by default we setup self-signed certificate for the backend, which can be manually changed to proper certificate if needed. Backend certificate is used if gitlab is configured to work in HTTPS mode (and frontend certificate is another story). NOTE ssl certificate is generated with just `openssl req ...` - yes, there is slapos.cookbook:certificate_authority.request but it requires to start whole service and has up to 60 seconds latency to generate certificate. And we only need to run 1 command to do that... The features disabled are: - http -> https redirection not needed for us at nginx level - the frontend can do the redirection and also gitlab speaks HSTS on https port so when we access https port via http protocol, it gets redirected to https. - kerberos - ssl_dhparam - providing custom nginx configuration via instance parameter /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Convert unicorn parameters to slapos and configure it to listen on unix socket only. ( Omnibus configures unicorn to listen on unix socket and loopback TCP, mainly because gitlab-shell could not connect to unicorn via unix socket until recently: https://gitlab.com/gitlab-org/gitlab-shell/commit/184385ac But as it can now, there is no point to keep on TCP port open ) To be able to do such configuration we add stub to unicorn service section (to create needed directories where to keep the socket). There will be follow-up patch which configures unicorn pre/post-forking actions, which is not trivial and thus better be done on its own. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Convert the rest of this configuration file to slapos. It is straightforward conversion of parameters except: - access-via-ssh is disabled (gitlab slapos version does not support ssh access and supports HTTP(S) only by design on purpose) - we do not support restricting possible projects visibility via instance parameter (very low chance this will be needed in practice) - default issue-closing pattern is just ok for now and not configurable - support for builds, build artifacts & CI is disabled (we do not support CI (yet ?)) - some internal defaults are just ok (e.g. where to organize directory for keeping repositories archives for downloads) - reply-by-email is not supported (yet ?) - we do not support LFS (yet ?) - just plain git hosting is ok for now. - Gravatar defaults are ok for now and not configurable. - Support for LDAP is disabled - Support for Kerberos is disabled - Support for OmniAuth is disabled - Satellites path is just /dev/null as we start from version where satellites are already non-existent. - Uploading backups to somewhere via GitLab's builtin mechanism is not supported - we'll use SlapOS native backup and resiliency for this. - Support for Google analytics is disabled. - Support for Piwik is disabled. - we are ok (for now) with default rack-attack git settings /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
GitLab has a notion of "external URL" - the canonical "frontend" URL the server is reachable through: this URL is used as prefix to show e.g. git-clone URL for repositories, etc, even if a server can be reachable via several frontends. Add external_url handling to slapos instance. NOTE whether to use https or not is also defined by external_url, in particular by external_url scheme. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Convert to slapos SMTP settings for gitlab: - convert to jinja2 - remove support for gitlab CI (we do not support it (yet ?)) - add handling of `smtp_enable` parameter directly to that file ( omnibus handles this parameter externally and just removes smtp_settings.rb if it is true ) NOTE smtp_settings.rb contains SMTP password, so it is mode is set to 0600. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Just another 2 simple parameters (attack detection tunables) conversion to jinja2/slapos. /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Just convert 2 parameters used in that file to jinja syntax and add those parameters (unicorn OOM killer tunables) to gitlab-parameters.cfg /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
We tweak database.yml to point to our postgresql unix socket; set adapter to hardcoded postgresql, encoding to unicode and omit collation (which according to omnibus-gitlab is used for mysql only). The only instance parameter imported from omnibus is `db_pool` - how many connection to a DB to keep open in a RoR thread/process. XXX we use db's superuser as a user to connect. Is it ok to do even if the whole DB is used only for gitlab? (I think it is ok for the first iteration, but we'll probably need to refine this later) /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
We will be using a several dozens of parameters to control gitlab instance. It makes sense not to deviate in such parameters namings and defaults from omnibus version. Thus for such parameters - for clarity - we organize a separate file where we will be keeping them - gitlab-parameters.cfg. In this patch series all used parameters will be "imported" from omnibus-gitlab 8.2.3+ce.0-0-g8eda093. NOTE it is maybe better to try to autogenerate that file from upstream omnibus parameters definitions. If time will tell it becomes hard to maintain our copy - we'll consider going that way. /cc @kazuhiko, @jerome
-