Bug 1381824

Please see further discussion in relation to support "puppet defines"


 An example of a puppet module that uses a define to manage plugins.
#########################################################
https://github.com/datacentred/puppet-telegraf

 apache::vhost { $mydomains: }                              ----------> this statement would iterate through all the values in the above array declaration.

Resulting with three vhosts with exactly the same settings.   Not very useful.

Lets take the Telegraf puppet module as an other example:

telegraf::input { 'my_exec':
  plugin_type => 'exec'
  options     => {
    'commands'    => ['/usr/local/bin/my_input.py',],
    'name_suffix' => '_my_input',
    'data_format' => 'json',
  },
  require     => File['/usr/local/bin/my_input.py'],
}

telegraf::input { 'influxdb-dc':
  plugin_type => 'influxdb',
  options     => {
    'urls' => ['http://remote-dc:8086',],
  },
}

telegraf::input { 'my_snmp':
  plugin_type => 'snmp',
  options     => {
    'interval' => '60s',
  },
  sections    => {
    'snmp.host' => {
      'address'   => 'snmp_host1:161',
      'community' => 'read_only',
      'version'   => 2,
      'get_oids'  => ['1.3.6.1.2.1.1.5',],
    },
  },
}

Now assume you want to change one or two parameters based on the host it's running on and the number of times you call telegraf::input can vary from hosts to host.
This is easy using the Open Source tools using hiera file or just call the define multiple times in the manifest.   I can't do that using the UI because, to my knowledge, it does not support defines.   Instead I have to rework  everything to work within classes so I can include it using the Satellite UI.
#######################################



2) Current response is to use classes with config variables.
--> ==> https://access.redhat.com/documentation/en/red-hat-satellite/6.2/single/puppet-guide/#sect-Red_Hat_Satellite-Puppet_Guide-Adding_Puppet_Modules_to_Red_Hat_Satellite_6-Configuring_Smart_Variables_from_Puppet_Classes

Defined resources are just resources, like 'file', 'user', etc are in Puppet - that
are usually used in combination with one another to define a particular state a machine
should be in.  The modules like puppetlabs-apache should be thought of as libraries, not
things you apply to servers.

You would use vhosts from puppetlabs-apache, combined with other resources - say files,
services, selinux rules, firewall rules, etc to come up with a 'profile' *class* for
a machine.  You can parameterize what needs to be different (say, dns servers, etc)
and manage them with smart class in parameters.  The profile class is what you would
select to get applied to the server in Satellite.

Say you had a puppet class for redhat.com web servers.  You'd have the vhost in there,
maybe some stuff that would ensure httpd is running, maybe a few users defined that
can access the box, root ssh keys, maybe it configures for LDAP login, etc.   That class
is what you would apply to the server.

If you really insist on trying to manage individual resources through Satellite,
the upstream documentation has details on some approaches,
  http://projects.theforeman.org/projects/foreman/wiki/Instantiate_Puppet_resources

The last one being 'hash_resources' module which some customers seem to like.
--> https://docs.puppet.com/puppet/latest/reference/lang_resources_advanced.html


3) This example will create excessive work as puppet defines is a universally accepted format for some time now.
Would prefer to use puppet defines that is supported by default without the need to setup classes or hiera.

Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.

Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.