Module Breaks on 7.10.0 Release of gitlab

[ahuffman]

I changed the gitlab_branch to 7.10.0 today with the new gitlab release, but the download failed...

With this release it looks like gitlab is changing the naming convention on their RPMs: https://downloads-packages.s3.amazonaws.com/centos-6.6/gitlab-7.10.0_omnibus-1.el6.x86_64.rpm <---failed https://downloads-packages.s3.amazonaws.com/centos-6.6/gitlab-ce-7.10.0~omnibus-1.x86_64.rpm <--actual link from gitlab.com downloads page

I used the gitlab_download_link module parameter to point to the correct RPM name and it downloaded, but then more problems....

Apr 22 14:31:48 myserver puppet-agent[13751]: (/Stage[main]/Gitlab::Config/Exec[stop gitlab]) Failed to call refresh: Could not find command '/usr/bin/gitlab-ctl'
Apr 22 14:31:48 myserver puppet-agent[13751]: (/Stage[main]/Gitlab::Config/Exec[stop gitlab]) Could not find command '/usr/bin/gitlab-ctl'
Apr 22 14:31:48 myserver puppet-agent[13751]: (/Stage[main]/Gitlab::Config/Exec[/usr/bin/gitlab-ctl reconfigure]) Failed to call refresh: Could not find command '/usr/bin/gitlab-ctl'
Apr 22 14:31:48 myserver puppet-agent[13751]: (/Stage[main]/Gitlab::Config/Exec[/usr/bin/gitlab-ctl reconfigure]) Could not find command '/usr/bin/gitlab-ctl'
Apr 22 14:31:48 myserver puppet-agent[13751]: (/Stage[main]/Gitlab::Config/Exec[start gitlab]) Could not evaluate: Could not find command '/usr/bin/gitlab-ctl'
Apr 22 14:31:48 myserver puppet-agent[13751]: Finished catalog run in 119.03 seconds

[root@myserver ~]# gitlab-ctl
-bash: gitlab-ctl: command not found
[root@myserver ~]# updatedb
[root@myserver ~]# locate gitlab-ctl
/opt/gitlab/bin/gitlab-ctl

So it looks like some binary paths have changed now as well and need updating in the module. I'm running CentOS 6.6 by the way.

[deedoubledub]

Here's the explanation for gitlab-ctl: command not found

https://about.gitlab.com/2015/04/23/gitlab-7-dot-10-dot-0-omnibus-patch-release/

[ahuffman]

The missing binaries issue is cleared up as of today with the newest 7.10.0 patched release: https://downloads-packages.s3.amazonaws.com/centos-6.6/gitlab-ce-7.10.0~omnibus.2-1.x86_64.rpm

The file naming convention change still stands as a needed module update, unless you specify the download link parameter and use the rpm url above.

[ahuffman]

I sent over a pull request for a CentOS 6 fix of this issue that could be ported to the Debian code as I mentioned in my email.

I also added an option called omnibus_build_ver that allows you to specify a build number. The 7.10.0 initial release came out buggy and gitlab re-released a 2-1 build the following day. There was no provision in the module to handle this type of scenario and this covers it.

In your manifest you would have this: class { '::gitlab': puppet_manage_config => true, puppet_manage_backups => true, puppet_manage_packages => true, gitlab_branch => '7.10.0', omnibus_build_ver => '2-1', ...

This allows for the handling of the rpm from gitlab: https://downloads-packages.s3.amazonaws.com/centos-6.6/gitlab-ce-7.10.0~omnibus.2-1.x86_64.rpm

The default is set to 1.

[spuder]

I'll have to keep looing into this. I think the best option would to do a major API change and use the built in packages.

issue #150

[ahuffman]

It's working now!!! It was a documentation issue on the packagecloud module config. Thanks to Joe at packagecloud for helping me debug the problem.

I had to specify the server_address parameter because the repo is at packages.gitlab.com not the default packagecloud.io.

        packagecloud::repo { "gitlab/gitlab-ce":
          type    => 'deb',
          server_address => 'https://packages.gitlab.com',
          require => Package['wget'],
        }

I pushed the final commit up to branch_140 after a quick CentOS 6.6 test. It upgraded perfectly from 7.10.0_2-1 on my production system.

Let me know if you have any questions, but it should be a functional fix at this point. I would still have to test backward compatibility for the older version installs, but I don't have the bandwidth to do that at the moment.

[spuder]

Really great work. I'm going to test these changes as soon as I can.

I'm evaluating an overhaul of the module based on these changes. I really like what elastic did with their module so that it can convert a hash into yaml.

https://github.com/elastic/puppet-elasticsearch/blob/b2ab583949562dc51b264ea1ed63c3223ebb8566/templates/etc/elasticsearch/elasticsearch.yml.erb

This would make it so that all parameters that are defined in the gitlab.rb don't have to be pre-generated in the erb template.

[ahuffman]

One thing I did find is that the packagecloud module keeps running an exec that remakes the yum_cache on every puppet run. I forked that repo and submitted a pull request to that module. Basically adding a refreshonly => true so it doesn't run unless it receives an event. My tests prove that to work nicely. Other than that, as I mentioned above, I've removed the wget requirements as the package isn't really required as I had initially thought.

[ahuffman]

One more thing that could make this update complete (now that we're working with repositories) is a parameter for latest if somebody didn't want to be locked into a specific version, and wanted to always receive the most up-to-date gitlab-ce, but not sure it belongs in this branch.

[spuder]

Great, I've started a refactor of the code that will make generating the gitlab.rb file more flexible and dynamic. This will deprecate some of the more obscure parameters, so it is targeted for version 3.0 of the module.

I'll push a new 3x branch soon.

I'm also adding a parameter to let you choose between rpm, deb and gem installs.

[spuder]

Module transitioned to here: https://github.com/vshn/puppet-gitlab