splitting sbadia/puppet-gitlab into three parts

[mc0e]

See the Initial Discussion at (sbadia/puppet-gitlab#34)

I've taken the module from (https://github.com/sbadia/puppet-gitlab) and forked it three times:

• https://github.com/mc0e/vagrant-gitlab
• https://github.com/mc0e/puppet-gitlab_prerequisites
• https://github.com/mc0e/puppet-gitlab

I've made some minimal modifications to vagrant-gitlab such that it loads the other two in as submodules, and I've adjusted the Vagrantfile accordingly. This is just enough that the vagrant setup can run as before.

The puppet gitlab_prerequisites module is mounted on the server, but nothing in the rest of the puppet config refers to it, so it does nothing, and the class names in the files don't line up with the "gitlab_prerequisites" directory name anyway.

The general way forward looks something like this:

• strip puppet stuff out of vagrant-gitlab
• Strip Vagrant stuff out of puppet-gitlab and puppet-gitlab_prerequisites
• Rearrange the puppet functionality between the two modules so that puppet-gitlab is service specific

There's a fair bit that I'm not familiar with in sbadia's distribution, so it'll be a learning experience.

[sbadia]

Hi, as for the vagrant things / rest of the project separation, I agree completely with your point of view.
But about the separation of puppet-gitlab «core» and its prerequisite, I'm septic... especially in the infrastructure virtualization context (a vm by service), it may make the packaging / dependencies a bit complicated on puppet forge.

[sbadia]

I can help ? 😃
(i just added you to sbadia/puppet-gitlab collaborators)

[mc0e]

Help most welcome. I've added you to all three repositories.

For me splitting the service module from the prerequisite support is the whole point of the exercise. I'm looking to add github into an environment which currently has 11 servers, all of them managed very nearly entirely through puppet. I've got layers of common configuration between servers that cover common utilities, network configuration, user access management, firewall configuration, monitoring, backups, etc. I don't want to be maintaining a whole separate puppet configuration for github, and working to integrate those things into your base configuration approach. I'm also probably not going to have github as the only major service on the box. Currently we're running an svn service on the same box that hosts the puppetmaster and a lot of the monitoring infrastructure. So for me the primary goal is to get a service focused github module going, such that I can fit it into an existing environment.

Being able to develop this in a vagrant environment appeals though, and setting the 3 projects up as I have enables me to work on a series of incremental changes while testing a rebuild from the ground up at various stages as I go. Also, I'd like to convince you that while I might be pursuing a different use case to you, these don't have to be incompatible. I'd be much happier to see you adopt my changes, so I can benefit from future changes you introduce without needing to do as much maintenance myself.

From the end user's perspective I don't think it will be much different to build a vagrant server. git clone. git submodule init. git submodule update. vagrant up. done. Exactly what you have now, just with more submodules, and starting from the vagrant-github repository as the parent rather than from puppet-github.

In terms of maintaining the project, it's quite possible that I may be missing subtleties. I haven't really worked with git submodules in this way before. I see that there's a bit of telling the parent project to update its references to the latest release of the child projects every so often. What else?