1

I'd like to install source code packages which doesn't have binary packages (deb, rpm) yet.

How do I stop execution of a module in case that the module is already install on that machine?

I'm using:

  Exec {
    creates => "${zookeeper_path}/zookeeper/bin/zkServer.sh"
  }

however all the other block are executed anyway. What is the best way? Checking existence of several files? I don't want to untar and recompile all the modules when puppet check for changes.

EDIT:

The installation process consists of several steps:

  1. fetch tar.gz package
  2. untar package
  3. create several config files
  4. create service
  5. ensure service is running
Tombart
  • 2,013
  • 3
  • 27
  • 47
  • I'd expect there's a better way around this problem, given a few more details. `exec` already has a `creates` parameter that helps sometimes. Puppet resources should be designed to be [idempotent](http://docs.puppetlabs.com/guides/introduction.html#idempotency), so it wouldn't hurt to apply them repeatedly. If you can edit the question to add some more information, it might narrow down possible solutions. – Mike Renfro Mar 17 '13 at 22:08
  • I've edited the question. I might check if the process is running e.g. `ps aux | grep zookeeper | wc -l` > 1, if so, skip all other steps? Instead of cleaning unpacked files it's better to keep it at filesystem? – Tombart Mar 18 '13 at 14:04
  • If I was going to stick with my understanding of "the puppet way", I'd think steps 1, 2, and 4 are best handled by building a package for zookeeper, and possibly using a `package` resource to ensure you have the latest version. Steps 3 and 5 would be best handled with `file` and `service` resources. The whole thing could then be wrapped up into a self-contained zookeeper module. Do zookeeper packages already exist for your distribution? Or are they the wrong version, etc? – Mike Renfro Mar 18 '13 at 21:04
  • For Debian zookeeper in not in stable branch yet. The question is more about understanding the puppet way, which you mostly answered. The documentation has many versions and I'm never sure what is already outdated. – Tombart Mar 19 '13 at 15:39
  • 1
    Been there, done that. I'm actually in the middle of rebuilding my Puppet infrastructure to clean up 6 years of learning experiences and outright hacks. If it was me, I'd backport the zookeeper package from testing or unstable, build a local Debian repository if zookeeper had to be updated frequently and/or deploy on multiple nodes, and then use `package`, `file`, and `service` as given before. The packaging *could* be as simple as `apt-get -b source zookeeper`, with appropriate deb-src lines in /etc/apt/sources.list. – Mike Renfro Mar 19 '13 at 16:38
  • You're right, actually I'm slowly getting there, thanks to you I might make bigger steps. Creating Debian packages seems to be the best option. – Tombart Mar 19 '13 at 19:11
  • Feel free to grab the puppetmaster and puppet agent bootstrap tarballs I have in my Github (linked in my profile). I won't claim they're perfect, but they get you a relatively prouduction-ready setup quickly. – Mike Renfro Mar 19 '13 at 23:17
  • I've tried to sum up some general knowledge for using puppet in an answer below. I've ported the zookeeper package from `sid` version, though there are still some problems: zookeepers logs grows exponentially, probably using `logrotate` would be a good idea etc. – Tombart Apr 21 '13 at 12:08

1 Answers1

4

After trying few dead-ends and from @Mike Renfro comments I came up with following steps (feel free to improve it):

  1. Don't install packages from source code with Puppet (it takes too long and brings too many problems)

  2. Always create binary packages. It can be easily redistributed and tested.

  3. Set up your own repository - for Debian a good choice is reprepro, documentation seems to be awful, but there's a Puppet module for installing: puppet-reprepro. Adding new package is quite easy:

    $ reprepro -Vb . includedeb squeeze ~/packages/my_package.deb

  4. Create new packages with fpm. The process of building a package is surprisingly simple and much easier than writing it in Puppet script.

  5. Install packages simply with:

    package { "leiningen": ensure => present }

  6. You can simply get packages which are still in testing version deploy it with your local repository.

  7. Use hiera for machine-specific configuration, in manifests should be only generally reusable templates for certain tasks (like web-server, db-server, etc.)
Tombart
  • 2,013
  • 3
  • 27
  • 47