1. 07 Aug, 2016 1 commit
    • Kirill Smelkov's avatar
      gitlab: Sync gitlab-parameters.cfg to upstream · 61177775
      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 \
      and modulo trusted proxies there are no interesting changes for us.
  2. 02 Aug, 2016 1 commit
    • Kirill Smelkov's avatar
      gitlab: Sync gitlab-parameters.cfg to upstream · 6459ea7c
      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 \
      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.
  3. 28 Feb, 2016 1 commit
    • Kirill Smelkov's avatar
      gitlab: Sync gitlab-parameters.cfg to upstream · 043402bb
      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 \
      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.
  4. 11 Feb, 2016 2 commits
  5. 17 Jan, 2016 10 commits
    • Kirill Smelkov's avatar
      gitlab: Setup sidekiq service · 4c127fdd
      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's avatar
      gitlab/nginx: Slapos'ify config and turn nginx into a service · 85f7d7e3
      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's avatar
      gitlab/unicorn.rb: First round of slaposification · 0aae33d9
      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:
        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's avatar
      gitlab/gitlab.yml: Slapos'ify rest of it · c3f1f0a9
      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
          - default issue-closing pattern is just ok for now and not
          - 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
          - 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's avatar
      gitlab/gitlab.yml: Handle "external URL" · 93362a08
      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's avatar
      gitlab/smtp_settings.rb: Convert/integrate to slapos · c64f7ece
      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's avatar
      gitlab/rack_attack.rb: Convert/integrate to slapos · a44f5a43
      Kirill Smelkov authored
      Just another 2 simple parameters (attack detection tunables) conversion
      to jinja2/slapos.
      /cc @kazuhiko, @jerome
    • Kirill Smelkov's avatar
      gitlab/config.ru: Convert/integrate to slapos · 41b1edb5
      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's avatar
      gitlab/database.yml: Tweak to integrate gitlab with internal postgresql · a73d20f4
      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's avatar
      gitlab: Organize place to keep parameters & their default imported from gitlab-omnibus · de860ba5
      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