Hiera documentation bug

[jowrjowr]

The workaround described here https://github.com/jfryman/puppet-nginx/blob/master/docs/hiera.md in regards to specifying nginx::config options without using hiera does not work.

Including nginx will construct the nginx::config class, which then errors out when you later construct it because nginx::config will be duplicated.

My preferred solution is this:

class { 'nginx::config': }-> class { 'nginx': }

This enforces the proper ordering, and eased a bit of frustration I was having.

[jfryman]

Thanks @jowrjowr. What would you change to make this actionable for new users? Docs need updating, or is this better a code change in your opinion?

[jowrjowr]

I think it needs to be made explicit that if you specify a nginx::config,
you have to fully populate it because the module won't merge in other
defaults.

It would be really nice if folks weren't pushed so strongly into hiera. Why
not just construct nginx::config as a normal class, and allow parameters to
be overrided as needed?

On Thu, Jan 29, 2015 at 9:13 AM, James Fryman notifications@github.com
wrote:

Thanks @jowrjowr https://github.com/jowrjowr. What would you change to
make this actionable for new users? Docs need updating, or is this better a
code change in your opinion?

—
Reply to this email directly or view it on GitHub
#556 (comment)
.

[jfryman]

It would be really nice if folks weren't pushed so strongly into hiera. Why
not just construct nginx::config as a normal class, and allow parameters to
be overrided as needed?

It's not a push. I'm really trying to find a nice medium between those that do use hiera, and those that do not. We're sitting on two worlds here... and it seems to be difficult to truly find that.

The ideal is that what I do specify in the documents does work, and you do not have to fully populate nginx::config. That just means there is more work to be done.

[devopsdevon]

For anyone that stumbles across this issue and needs a temporary work around, here is a fully functional example of instantiating nginx::config manually using version 0.2.2 of the nginx module.

As far as I can tell, this example sets all of the same defaults that would normally get set (skipping over anything set to undef by default):

  include ::nginx::params
  class { '::nginx::config':
    client_body_temp_path          => $::nginx::params::client_body_temp_path,
    conf_dir                       => $::nginx::params::conf_dir,
    daemon_user                    => $::nginx::params::daemon_user,
    global_owner                   => $::nginx::params::global_owner,
    global_group                   => $::nginx::params::global_group,
    global_mode                    => $::nginx::params::global_mode,
    http_access_log                => $::nginx::params::http_access_log,
    log_dir                        => $::nginx::params::logdir,
    nginx_error_log                => $::nginx::params::nginx_error_log,
    pid                            => $::nginx::params::pid,
    proxy_temp_path                => $::nginx::params::proxy_temp_path,
    sites_available_owner          => $::nginx::params::sites_available_owner,
    sites_available_group          => $::nginx::params::sites_available_group,
    sites_available_mode           => $::nginx::params::sites_available_mode,
    super_user                     => $::nginx::params::super_user,
    temp_dir                       => $::nginx::params::temp_dir,
  } -> class { '::nginx': }

[3flex]

@jowrjowr does this documentation update help? #669

[wyardley]

We are going to be reworking this, and probably flattening things out. So, I'm going to close this ticket for now, feel free to follow #950