Dependency Reconsiderations

[atomaka]

We have had several talks about decoupling puppet-gitlab from GitLab's dependencies (#35, #87,#102) and have been slowly pulling them out as we find reasonable ways to do so. However, it seems like a large number of users come here expecting the application to handle a full installation of the GitLab software (#109, #82, #57, #107, #108, etc). Furthermore, several of the forks of this project are the result of people wanting to have a module to install all dependencies.

If a majority of users are looking for a full installation solution, should we consider providing that? This would basically involve replacing puppet-gitlab with puppet-gitlab-requirements (a cleaned up version) and migrating the current puppet-gitlab to a puppet-gitlab-core (or something). This would benefit typical users while allowing advanced users to continue to provide their own dependencies if they wish.

I am not sure if this is something we should do, but recent issues and pull request make it worth discussing.

[igalic]

That sounds like a good direction.

now, exactly what do you consider core?
I'm thinking that would be gitlab, gitlab-shell, resque, unicorn.

Everything below or above this should be handled elsewhere.

[atomaka]

Initially, I figured the change would mostly be superficial just so people could type puppet module install sbadia/gitlab and end up with a completely working install. I believe our overall goal is still to continue separation of the requirements pulling more from puppet-gitlab and putting it into puppet-gitlab-requirements.

[igalic]

Everything we have in ensure_packages() needs to be ripped out and placed into requirements.

[lmello]

suggestion for ensure_packages:

if !defined(Package[pkgname]) {
  package { 'pkgname': }
}

If we use something like that, it would not conflict if other module already defined the package, and we will install it if it was not defined in another module in the catalog.

don't know if i was clear. :-/ sorry for the english.

[lmello]

The problem with ensure_packages is it implementation use the defined_with_params, that search the catalog for a definition for the resource with the same params... this would create duplicate declarations.
for example module git, manages package git and could set explicit the git version out of our control, and we only ensure => present (the behaviour of ensure_packages) . this would create a duplicate definition of package git, because ensure_packages only configure the parameter ensure => present and check if it is already defined one package with the same parameter ensure => present, since git package have ensure => 1.8 (example), it would create a duplicate definition.

using !defined(Package[pkgname]) we won't have that problem, because it will only check if there is a package with name pkgname defined, does not take into account the parameters.

this behaviour is possible to understand reading the following stdlib files:
/stdlib/lib/puppet/parser/functions/ensure_packages.rb
stdlib/lib/puppet/parser/functions/ensure_resource.rb
./stdlib/lib/puppet/parser/functions/defined_with_params.rb

[andyleejordan]

I think parameterizing each dependency with an off switch isn't a bad way do it at all. This lets users pick and choose which parts of the installation they want managed.

[poikilotherm]

Hey guys,
I just found this module and it looked promising... As some people mentioned that they prefer spuder/puppet-gitlab@4aaa702, I would prefer using this module as I don't want a Postgres service while having a central MySQL, but no GitLab enterprise license. ;)

Anyway, my question on this topic: I looked into the sbadia/puppet-gitlab-requirements@129ceff code (branch gitlab-rbenv) and I was wondering if it would be a clever idea to introduce a roles-and-profiles pattern for the requirements.

If you think this is a good idea, I am willing to contribute to this. :)

[igalic]

👍

any idea on how to go about designing that?

[poikilotherm]

I thought about this thing for the past hours...

Right now, I am at a point in my thoughts, where it only makes sense to return to using Puppet for a configuration management of GitLab, but not trying to install things without tools build for it (package management).
This relates to #47, too.

I'm sorry guys, I don't think my idea would be an appropriate solution. To be clear with this: spuder's idea with spuder/puppet-gitlab to use the omnibus packages is closer to the idea Puppet was built with, but it does not provide much flexibility if one wants to leave the path the omnibus packages paves.

I'll think some more about this and maybe come back later...

Edit: I think I overlooked something. If you use "puppet apply" (run once), this module is just fine. I am using puppet with a master (run regularly) and in this context the module IMHO doesn't seem to fit.

[igalic]

given that the execution is idempotent, I don't really see the issue. You running once or twice an hour. I don't see the issue.