How to deal with resource conflict between modules

126 views
Skip to first unread message

titlei...@gmail.com

unread,
Nov 6, 2017, 11:13:11 AM11/6/17
to Puppet Users
Hello,

I'm very new to Puppet and trying to implement 2 very simple modules.  Both of these modules should work independent of each other, but both will be run on the same host.  They both require that openssh-server be installed and the sshd service is started and enabled.  I'm unable to figure out how to deal with this as I keep getting a Duplicate declaration for Package['openssh-server'].


   
package { 'openssh-server':
       
ensure => installed,
   
}
    service
{'sshd':
       
ensure  => running,
        enable  
=> true,
       
require => Package["openssh-server"],
   
}


What is the best way to deal with this?  Please keep in mind that I'm not very proficient with Puppet, still have a lot to learn.  I read through some of the documentation that discusses uniqueness for resource titles and names, but I don't follow how to get around that.  Should I have a "common" module of sorts where duplicate things exist?  That seems to add complexity and the modules will then have a dependency on that.  I would like to avoid that and have each module be self contained.

Thank you for any pointers or help.

-J

warron.french

unread,
Nov 6, 2017, 8:36:25 PM11/6/17
to puppet...@googlegroups.com
titleistfour,
    please copy/paste the content of both modules.  You said in your first sentence that you have 2 modules.  

Did you actually mean you had 1 module with 1 class with 2 puppet resources?  Specifically the code snippet you provided only shows 2 puppet resources: 1 for package and 1 for service.

So, please provide the manifest name (the .pp file), and then immediately below it the entire class (starting from the class line down to the closing curly brace '}' ).

Also, for real-time help, are you aware of the site slack.puppet.com?  It is awesome and there are tons of puppet experts that can help you on many levels with your code and design for that matter.



--------------------------
Warron French


--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/45e66272-be57-4b7a-8176-554edb05badc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

jcbollinger

unread,
Nov 7, 2017, 1:33:21 PM11/7/17
to Puppet Users
Module compatibility issues are a longtime recurring matter.  A variety of approaches to various aspects of the problem have been devised over the years.  The best and most reliable solution I have so far encountered is first and foremost architectural: plan and implement your modules and manifest set so that each resource is the responsibility of exactly one module.  Having done that, you can rely on the singleton character of Puppet classes to allow you to declare your need for a particular feature wherever is appropriate, without risking duplicate resource errors.

In your particular case, that would involve factoring the ssh server resources out into their own module, either one of your own or one of the many existing third-party modules for the purpose, such as ghoneycutt's.  Then each of the two modules you started with uses an include-like declaration of the appropriate class(es) from that module to assert its need for ssh services.  For ghoneycutt-ssh, that would be simply

include ::ssh

Note well that an include-like class declaration should be used, not a resource-like class declaration.  That also means that whatever customization is required must be performed via automated data binding.

This does tend to apply pressure toward having many fine-grained modules.  A well-regarded way to deal with that, among other issues, is to implement the Roles & Profiles pattern.  That won't reduce the number of modules, but it will provide a way to aggregate them into sensible logical units.


John

Reply all
Reply to author
Forward
0 new messages