Supporting puppet.conf - design discussion

[gregswift]

I have been trying to figure out how to manage the puppet.conf contents, and my preference is always augeasproviders. I'm trying to determine how best to tackle this.

1: A single giant type/provider set that handles the whole file. This just doesnt seem like it would work to me, because of sections like environments.

2: A separate type per section (main, master, agent, environments) with a shared provider? Is that even doable?

3: Separate type/provider per section. seems like lots of dupe work.

[raphink]

Can you provide examples of puppet DSL as you imagine it for each case!

On Sat, 20 Jun 2015 06:13 Greg Swift [email protected] wrote:

I have been trying to figure out how to manage the puppet.conf contents,
and my preference is always augeasproviders. I'm trying to determine how
best to tackle this.

1: A single giant type/provider set that handles the whole file. This just
doesnt seem like it would work to me, because of sections like environments.

2: A separate type per section (main, master, agent, environments) with a
shared provider? Is that even doable?

3: Separate type/provider per section. seems like lots of dupe work.

—
Reply to this email directly or view it on GitHub
#1.

[gregswift]

Configuration reference for 4.1

Now that i've looked at that, and trying to write a few examples.. and i dunno anymore.

[gregswift]

1: This one has a problem when sections have parameters with the same name. Which can be handled with the second...

puppet_conf { 'param':
  section => 'main', #default
  value => 'blah',
}

puppet_conf { 'param for main':
  section => 'main', #default
  key => 'param',
  value => 'blah',
}

2: names for the resources are kinda ugly...

puppet_master { '?':
  dns_alt_names => ['',''],
  environmentpath => '',
  basemodulepath => '',
  environment_timeout => '',
  reports => '',
  extra_parameters => {'tags' => ['',''], 'usercacheonfailure' },
}

puppet_main { '?':
  server => '',
  certname => '',
  environment => '',
  priority => '',
  report => '',
  tags => [''],
  runinterval => '',
  extra_parameters => {'tags' => ['',''], 'usercacheonfailure' },
}

puppet_agent { '?':
  server => '',
  certname => '',
  environment => '',
  priority => '',
  report => '',
  tags => [''],
  runinterval => '',
  extra_parameters => {'tags' => ['',''], 'usercacheonfailure' },
}

puppet_environment { 'myenv':
    modulepath => '/etc/puppet/environments/myenv/modules/',
    manifest => '/etc/puppet/environments/myenv/manifest.pp',
    parser => '',
    config_version => '',
    environment_timeout => '',
    path => '', #would default to a sane path
}

[mcanevet]

@gregswift what is exactly the problem with the first proposal?
As discussed on IRC we could create a cli provider when using puppet 3.5+ using puppet config set --section foo bar, and in any case we could use puppet config print for self.instances

[gregswift]

Where i was saying it was a problem was the resource name. I hate having weird names that mean nothing, and personally i'm not as skilled as @raphink or @domcleal re: names that translate out to kewl things

[mcanevet]

@gregswift you can use composite namevars so that you can name your param section/param for example.

[gregswift]

yes, composites. thats what i meant when i said it the long drawn out way :)

[mcanevet]

@gregswift I started something here: https://github.com/camptocamp/puppet-puppet_conf_providers