Skip to content

GitLab

  • Menu
    • Projects Groups Snippets
      Help
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • G gitlabhq1
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 21
    • Issues 21
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 12
    • Merge requests 12
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • gpt
  • large_projects
  • gitlabhq1
  • Issues
  • #7902

Closed
Open
Created 10 years ago by Administrator@rootOwner
  • New issue

  • Report abuse

  • New issue

  • Report abuse

omnibus crashes if nginx is running

Closed

omnibus crashes if nginx is running

Created by: spuder

Starting in 7.3.1, the omnibus packaging will fail while trying to upgrade.

This is because users are now expected to manually run gitlab-ctl stop nginx before upgrading to 7.3.1.

This really needs to be put in the pre_install script of the omnibus RPM, and not reqiure manual user intervention. This has the nasty side effect of causing the upgrade to fail for users who manage gitlab with resource managment systems (puppet/chef/salt/ansible).

Example

In puppet, you define a package like so:

package { 'gitlab:
  ensure => latest,
}

There is no way in puppet to run an exec only before a package is upgraded. That is the RPM's job.

See https://github.com/spuder/puppet-gitlab/issues/81

https://about.gitlab.com/2014/09/24/gitlab-7-dot-3-dot-1-released/

Linked issues
...

    Related merge requests

    • Administrator
      Administrator @root · 10 years ago
      Owner

      Created by: Razer6

      This is also documented here.

      By Administrator on 2014-09-30T05:40:53 (imported from GitLab project)

    • Administrator
      Administrator @root · 10 years ago
      Owner

      Created by: jacobvosmaer

      @spuder you make a good point but this nginx issue only affects people upgrading from 7.3.0.

      Speaking more generally I am conflicted about this topic. Our current procedure mandates the following:

      • stop unicorn
      • stop sidekiq
      • create backup
      • install new package
      • reconfigure
      • restart gitlab

      This is the right thing for most but not all users. If you have a large GitLab server (think gitlab.com) you will not want to use the backup script because it is too slow. Because of this I think creating a backup automatically when you just install the package is not really an option. There also is the other selfish issue of minor deploys to gitlab.com; if it is just a change in the Rails code we ship there is no need to interrupt the service during a deploy. So doing a stopping unicorn and sidekiq from the package scripts is also not really an option for that reason.

      I would love for the upgrading of omnibus-gitlab to be less of a 'brainer' than it is now but I am not quite sure right now how to do that.

      PS the preferred forum for discussions about the workings of omnibus-gitlab is https://gitlab.com/gitlab-org/omnibus-gitlab/issues .

      By Administrator on 2014-10-01T11:52:47 (imported from GitLab project)

    • Administrator
      Administrator @root · 10 years ago
      Owner

      Created by: Razer6

      Closing this here as related to omnibus packages

      By Administrator on 2014-12-25T17:38:36 (imported from GitLab project)

    • You're only seeing other activity in the feed. To add a comment, switch to one of the following options.
    Please register or sign in to reply
    0 Assignees
    Assign to
    Milestone
    No milestone
    None
    None
    Time tracking
    Due date
    None
    None
    0
    Labels
    None
    Assign labels
    • No matching results
    • Manage project labels
    Confidentiality
    Not confidential

    You are going to turn on confidentiality. Only team members with at least Reporter access will be able to see and leave comments on the issue.

    Lock issue
    Unlocked
    participants
    Reference:

    Menu

    Projects Groups Snippets
    Help