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
Improve this question
8
  • 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, 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
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.)
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.