I'd be interested in supporting a puppet version of this with feature parity to what you have created with the chef cookbooks.

Does this make sense to you to include in this project or have a separate project?

If the puppet manifests were to be in this project maybe one the chef could be 7.x-1.x and puppet 7.x-2.x.

Pros for same project

  • Easier to keep feature parity and less likely a good idea one place won't be implemented in another
  • One module is easier for drupal users

Pros for separate module

  • Less issue queue clutter
  • Easier for maintainers to make decisions.

Thoughts?

Comments

acouch’s picture

acouch commented
Issue summary: View changes

styling

christianchristensen’s picture

christianchristensen commented

Hey! I am cool with Puppet confs. going into this repo (at our office we have been working with Puppet for our instances and I have been intending to push an example to this repo). But I also agree with your pro's and con's; I can even see the vagrant project being separate from different "types" of Drupal configurations (e.g. configurations with www, proxy, db config in Puppet vs. Chef vs. Salt vs. whatever...), however - given this was initially meant to share how quick and easy it should be to get a "production parity" Drupal install I just kindof put all the configs in one place...

So long answer longer: Puppet configs in here: cool! I'd love to help and see what you've got! Would you like to co-maintain on this project too?

Thanks!

christianchristensen’s picture

christianchristensen commented

(Opinions ahead)

Re: Chef branch 7.x-1.x and Puppet branch 7.x-2.x: Given how flexible the Vagrantfile is I would almost consider one branch sufficient with a Chef and Puppet directory... mainly b/c if they are different branches they are really going to have no common history. We could do something like Vagrantfile.chef and Vagrantfile.puppet - thoughts?

The Vagrantfile I have used with Puppet looks a little like (probably needs to update to the newer format...):

Vagrant::Config.run do |config|
  config.vm.box = "lucid64b"
  config.vm.network :hostonly, "33.33.33.10"
  # Provision with shell commands
  config.vm.provision :shell, :inline => "hostname dev-site.vbox.local"
  # Enable provisioning with Puppet stand alone.
  config.vm.provision :puppet do |puppet|
    puppet.options = "--verbose --debug --external_nodes=/vagrant/Puppet/nodes_extlookup.rb --node_terminus=exec"
    puppet.module_path = "Puppet/modules"
    puppet.manifests_path = "Puppet/manifests"
    puppet.manifest_file  = "site.pp"
  end
end

I use the node_terminus to basically return YAML config files that describe what the nodes "look like" (rather than having all the config stuck in top level manifest). This seems to play nicely with running this on Vagrant and then later deploying it with Puppet master...

acouch’s picture

acouch commented

I think it would make sense to have separate branches because it would make it easier to deal with the issue queue and the history doesn't necessarily need to be shared to be useful.

It would also make it harder to troubleshoot problems with the "noise" of additional files.

I'm currently in the process of documenting what you have (which I'm preparing to share as documentation for this project) and preparing to share the puppet manifests we are currently using.

The Vagrantfile I have is pretty similar to what you posted above. More to come soon :)

acouch’s picture

acouch commented
Issue summary: View changes

Updated issue summary.