1

We've adopted the ideas outlined in http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/, which introduces the notion of component modules, profiles and roles.

Say we have a component module "moduleA", which may be used by different profile modules. As different development teams may commit changes to "moduleA" at any given moment and push it to production (all our production servers are subscribing to the Puppetmaster "production" environment), it's kind of like depending snapshot-version of a module.

I the Java and Maven world, on would point the pom.xml to specific releases of the "moduleA", to avoid depending on a snapshot release. In Puppet, however, I don't think this is supported out of the box.

Is there any way of packaging Puppet similar to that of Maven, or any other means which may be applied, so that one can ensure a profile module can depend on a specific version of a component module?How are other puppet users managing module versions in such scenarios?

Regards, Kenneth Holter

kenneho
  • 401
  • 1
  • 7
  • 24

2 Answers2

1

You can't have the same module multiple times in the same environment. If you need multiple versions of the same module you have to use different environments.

How I would implement this:

  • have a profile module at version 1.0 that depends on your module moduleA at version y. This will be installed on environment env1
  • when you need a new version of moduleA, you create a new profile at version 1.1 (or 2.0, doesn't matter) that will depend on the new version. You will install this on env2

If you use the puppet forge to keep your modules, you only need to update the metadata.json and pull the new profile with:

puppet module install profile --target-dir /etc/puppet/environments/envX
cristi
  • 2,019
  • 1
  • 22
  • 31
  • Thanks for the reply. This seems like the way to go. Might end up with a fair amount of environments though, depending on how fast one get to migrate modules over to the newest versions. – kenneho Nov 03 '15 at 08:32
-1

I had similar situation where I wanted two different java versions in the same host I tried in this way.

define common::install_java() {
  package { 'zulu-8':
    ensure => 'installed',
    before => Service['jexec']
  }

  package { 'zulu-11':
    ensure => 'installed',
    before => Service['jexec']
  }

  file { '/etc/alternatives/java':
    ensure => 'link',
    target => "/usr/lib/jvm/zulu-8/bin/java",
  }

  file { '/etc/alternatives/java11':
    ensure => 'link',
    target => "/usr/lib/jvm/zulu-11/bin/java",
  }

  file { 'usr/bin/java11':
    ensure => 'link',
    target => '/etc/alternatives/java11',
  }

by default 'usr/bin/java' points to '/etc/alternatives/java' so I ignore that.

ryuik
  • 69
  • 4