Fwd: run_mode, conf section, module path! Oh my!

[Andy Parker]

For a little context into some of the thinking that led to trying to create a section in puppet.conf for each application here are two emails between Josh and myself.

Forwarded conversation
Subject: run_mode, conf section, module path! Oh my!
------------------------

From: Andy Parker <an...@puppetlabs.com>
Date: Thu, Nov 8, 2012 at 8:04 AM
To: Josh Cooper <jo...@puppetlabs.com>



I started writing in all of the ideas that we had been going over into that document last night. I also started putting in an explanation of why the idea would not really solve the problem. As I put them in the issues started to crystalize around the problem of there not being any static data about what the settings are. Every thing we were dealing with was because it wasn't until we had loaded some other code and run it did we know what to do.

So what if we just change that? The puppet.conf already has a [master] section used by the master, an [agent] section used by the agent. Why not say that it can have an [apply] section used by apply, and so on where the subcommand name is the name of the section we use for deciding configuration. This brings up the question of what to do with [user]. Well, right now [agent], [master], and [user] all inherit from [main]. Why don't we say that everything except [master] and [agent] (and environments) inherits from [user]. This also opens us up to being able to put options for faces in the configuration file.

We would need to deprecated the [user] section and move more quickly on splitting the environment configurations into a separate file (there is a bug filed about this). This would also require a lot of changes to how we handle the configuration file and looking up settings, but I don't think that would block it.

What do you think?

----------
From: Josh Cooper <jo...@puppetlabs.com>
Date: Thu, Nov 8, 2012 at 3:21 PM
To: Andy Parker <an...@puppetlabs.com>



Hi Andy,

It makes sense to have static configuration data... but in researching
this it appears that's how puppet used to work:

    http://projects.puppetlabs.com/issues/2935

Puppet (2.7.x) goes through the trouble of looking at legacy sections
in the config and mapping those to run_modes, in
Puppet::Util::Settings#legacy_to_mode. That's been removed in master
though.

I'm guessing, but issues like this:

    http://projects.puppetlabs.com/issues/2808

help explain why run_mode was created. It would be annoying to
configure puppetmasterd settings and then have puppetqd not work,
because those settings weren't configured. With that said, I don't
think run_mode is the right way to do it.

I need to think about this some more...

Josh

--
Josh Cooper
Developer, Puppet Labs