Bug 1290076 - mymodule class example has no httpd_port parameter
mymodule class example has no httpd_port parameter
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Docs Puppet Guide (Show other bugs)
Unspecified Unspecified
medium Severity unspecified (vote)
: GA
: 6.2
Assigned To: Dan Macpherson
Stephen Wadeley
: Documentation
: 1273743 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2015-12-09 10:56 EST by Stephen Wadeley
Modified: 2016-11-13 23:57 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-09-21 03:34:09 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stephen Wadeley 2015-12-09 10:56:44 EST
Document URL: 


Section Number and Name: 
section 3.7 "Configuring Smart Variables from Puppet Classes"

Describe the issue: 

The Puppet guide seems to have a consistency issue in the section referring to building your own class and configuring smart variables.  In section 3.7 the comment is: 

For example, mymodule contains a parameter for the HTTP port of our web server. This parameter, httpd_port, is set to a default of 8120.

Except the mymodule class that is built in the tutorial doesn't include an httpd_port parameter. There is an httpd_port variable referenced in the template and in the SELinux rule, but it's not a parameter with a default value in the mymodule class. From section 2.9 of the same document (no parameter in mymodule class declaration)

class mymodule {
  include mymodule::httpd
  include mymodule::app

I also believe the way the firewall and SELinux exec resources are configured in the example mymodule is likely to cause problems. They are both subscribed to the httpd package resource and are configured for refresh only, so will only fire/execute if the httpd package resource changes. If the httpd package is already installed on the server Puppet won't change the state of the httpd package resource, so I don't believe it will execute these Execs. Additionally, if you run the module and it configures the port (say 8120) and you then change the port and re-run Puppet, the firewall and iptables Exec won't execute to update the port because the httpd package state won't change (it's already installed), so your saved firewall and SELinux configuration will be out of step with your passed in parameter. Apologies for formatting, there is currently something wrong with the discussion forum that is breaking formatting in responses.

Suggestions for improvement: 

Additional information: 

Reported here: https://access.redhat.com/discussions/1987953#comment-994313
Comment 1 Stephen Wadeley 2015-12-09 10:58:32 EST
PixelDrift.NET Support wrote:

To follow up on the 'mymodule' example Puppet module problems, here is an example of the issue. I have created a basic manifest to run locally that triggers an exec in the same way as the sample module (httpd_port variable provided inline rather than a parameter, but same outcome). 

$httpd_port = 4000

  package { "httpd":
    ensure => installed,

  exec { "firewall-cmd ${httpd_port}":
    command => "/bin/echo \"this message in place of iptables\"",
    refreshonly => true,
    subscribe => Package['httpd'],

Results from the first run are in the below code block. httpd is installed and exec fires because state of 'httpd' package changes from not installed to installed. 

[root@cupcake ~]# puppet apply mymodule.pp
Notice: Compiled catalog for cupcake.pixeldrift.local in environment production in 0.40 seconds
Notice: /Stage[main]/Main/Package[httpd]/ensure: created
Notice: /Stage[main]/Main/Exec[firewall-cmd 4000]: Triggered 'refresh' from 1 events
Notice: Finished catalog run in 10.15 seconds

Now that the package is installed, the Exec will no longer fire, so the firewall port will never be updated. To demonstrate this, you can change the httpd_port variable at the start of the mymodule.pp file, eg.

$httpd_port = 3000

Now when you re-run the script the Exec (firewall) update won't occur because the httpd package is already installed even though the variable/parameter has changed.

[root@cupcake ~]# puppet apply mymodule.pp
Notice: Compiled catalog for cupcake.pixeldrift.local in environment production in 0.39 seconds
Notice: Finished catalog run in 0.53 seconds

This problem exists for both the firewall and semanage commands in the example mymodule Puppet module. I think the example needs reworking. 


Source: https://access.redhat.com/discussions/1987953#comment-994733
Comment 13 Andrew Dahms 2016-11-13 23:57:07 EST
*** Bug 1273743 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.