Puppet users - May 2007 - RFC: Configuration file consolidation (#206)

Hi all,

This has theoretically been a high priority for a long time, and I''m  
finally going to get it done, I think.

Here''s my plan, and I''d appreciate any comments you might have
on it.

Currently, sections only have meaning internally, in that one can  
call ''config.use(section)'' to create any directories needed
for that
section. Additionally, the catch-all section is ''puppet''.

The main change I want to make is making the catch-all section  
''main'', and then enabling a separate section per executable
name.
So, in the current system, you could have ''puppet'',
''puppetd'', and
''puppetmasterd'' sections, each with separate settings if you
wanted.

Then all of the executables would load ''puppet.conf'', which is
unlikely to exist anywhere right now (since it would only configure  
the stand-alone interpreter), although they would preferentially load  
the per-executable configuration file (puppetmasterd.conf et al) if  
present, albeit with a deprecation notice.

How''s that sound?

  --
  An expert is a person who has made all the mistakes that can be made
  in a very narrow field.       - Niels Bohr
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

On May 4, 2007, at 3:55 PM, Luke Kanies wrote:
> Hi all,
>
> This has theoretically been a high priority for a long time, and
I''m
> finally going to get it done, I think.
I''m changing the plan a bit, after talking to Ben.

Sections (as used by config.rb) currently only have meaning in code,  
as I mentioned, not in the configuration file -- you could make a  
section name up and put all of your configuration items there and  
Puppet wouldn''t care.

I believe what I will do is have a ''main'' section that would
get
interpreted by all executables.  Then each executable could have its  
own section, which would override anything in main if necessary.

Thus, the definition of ''section'' in the configuration file
would be
different than that in config.rb, so I''ll need to come up with a  
different term for one of them.  I think ''section'' is pretty
well-
accepted for INI files, which is all that the config files are, so  
I''ll pick a different term for the functional areas in config.rb.

Comments appreciated, as always.

  --
  Computers are not intelligent.  They only think they are.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

On Fri, May 04, 2007 at 04:49:18PM -0500, Luke Kanies
wrote:
> On May 4, 2007, at 3:55 PM, Luke Kanies wrote:
> > Hi all,
> >
> > This has theoretically been a high priority for a long time, and
I''m
> > finally going to get it done, I think.
> 
> I''m changing the plan a bit, after talking to Ben.
> 
> Sections (as used by config.rb) currently only have meaning in code,  
> as I mentioned, not in the configuration file -- you could make a  
> section name up and put all of your configuration items there and  
> Puppet wouldn''t care.
> 
> I believe what I will do is have a ''main'' section that
would get
> interpreted by all executables.  Then each executable could have its  
> own section, which would override anything in main if necessary.
> 
> Thus, the definition of ''section'' in the configuration
file would be
> different than that in config.rb, so I''ll need to come up with a  
> different term for one of them.  I think ''section'' is
pretty well-
> accepted for INI files, which is all that the config files are, so  
> I''ll pick a different term for the functional areas in config.rb.
> 
> Comments appreciated, as always.
Your plan, as amended, makes sense to me.  It''s how I would have done
it if
I''d actually gotten around to doing it.

- Matt

-- 
I still can''t see a wasp without thinking "400K 1W"
		-- Derek Potter, uk.misc

On May 4, 2007, at 5:38 PM, Matthew Palmer wrote:
>
> Your plan, as amended, makes sense to me.  It''s how I would have  
> done it if
> I''d actually gotten around to doing it.
Okay.

First step (which I''m about to commit) is pulling all of the  
configuration parameters into configuration.rb and doing some  
management of section names.

  --
  A government big enough to give you everything you want is big enough
  to take from you everything you have.           --Gerald R. Ford
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

--On Friday, May 04, 2007 15:55:33 -0500 Luke Kanies <luke@madstop.com> 
wrote:
> Currently, sections only have meaning internally, in that one can
> call ''config.use(section)'' to create any directories
needed for that
> section. Additionally, the catch-all section is ''puppet''.
>
> The main change I want to make is making the catch-all section
> ''main'', and then enabling a separate section per
executable name.
> So, in the current system, you could have ''puppet'',
''puppetd'', and
> ''puppetmasterd'' sections, each with separate settings if
you wanted.
How would the subsections look?

-- 
Digant C Kasundra <digant@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University

On May 4, 2007, at 6:48 PM, Digant C Kasundra wrote:
> --On Friday, May 04, 2007 15:55:33 -0500 Luke Kanies  
> <luke@madstop.com>
> wrote:
>
>> Currently, sections only have meaning internally, in that one can
>> call ''config.use(section)'' to create any directories
needed for that
>> section. Additionally, the catch-all section is
''puppet''.
>>
>> The main change I want to make is making the catch-all section
>> ''main'', and then enabling a separate section per
executable name.
>> So, in the current system, you could have ''puppet'',
''puppetd'', and
>> ''puppetmasterd'' sections, each with separate settings
if you wanted.
>
> How would the subsections look?
Just like sections in the config file look right now:

[puppetd]
   configdir = /etc/puppet

  --
  God loved the birds and invented trees. Man loved the birds and  
invented
  cages.  -- Jacques Deval
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Hi Luke

This thread is reminding me, that I''m actually a bit confused about  
the configfiles. Please let me explain:

When I started to implement puppet in our network, I deployed two  
config files, puppetd.conf and puppetmasterd.conf. I''m primarily  
running Debian so my preferred vardir is /var/lib/puppet, and I''d set  
that in the [puppet] section of puppetd.conf. I expected that to be  
read by puppetmasterd also, so that dir wasn''t defined in  
puppetmasterd.conf. I quickly realized that it didn''t and tried to  
get rid of puppetmasterd.conf and only have one file, puppetd.conf,  
with sections for all the different parts of puppet ([puppet],  
[puppetd], [puppetmasterd] etc.). But that didn''t work either :- 
( Puppetd used /var/lib/puppet and puppetmasterd used /var/puppet - I  
expect that this is the reason why I''ve never got reporting working...

My question is: Right now, should I use one config file, with one  
section for each part of puppet, and define $vardir under each  
section? If so, what should that file be named? puppet.conf? Or  
should I have conf files for each part, each with $vardir defined...?

As you can see, I''m confused... ;-)

On May 4, 2007, at 22:55, Luke Kanies wrote:
> Hi all,
>
> This has theoretically been a high priority for a long time, and
I''m
> finally going to get it done, I think.
>
> Here''s my plan, and I''d appreciate any comments you might
have on it.
>
> Currently, sections only have meaning internally, in that one can
> call ''config.use(section)'' to create any directories
needed for that
> section. Additionally, the catch-all section is ''puppet''.
>
> The main change I want to make is making the catch-all section
> ''main'', and then enabling a separate section per
executable name.
> So, in the current system, you could have ''puppet'',
''puppetd'', and
> ''puppetmasterd'' sections, each with separate settings if
you wanted.
>
> Then all of the executables would load ''puppet.conf'',
which is
> unlikely to exist anywhere right now (since it would only configure
> the stand-alone interpreter), although they would preferentially load
> the per-executable configuration file (puppetmasterd.conf et al) if
> present, albeit with a deprecation notice.
>
> How''s that sound?
>
>   --
>   An expert is a person who has made all the mistakes that can be made
>   in a very narrow field.       - Niels Bohr
>    
> ---------------------------------------------------------------------
>   Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
--
Med venlig hilsen
Juri Rischel Jensen

Fab:IT ApS
Vesterbrogade 50
DK-1620 København
Tlf: 70 202 407 / Fax: 33 313 640
www.fab-it.dk / juri@fab-it.dk

On May 21, 2007, at 9:18 AM, Juri Rischel Jensen wrote:
> Hi Luke
>
> This thread is reminding me, that I''m actually a bit confused
about
> the configfiles. Please let me explain:
>
> When I started to implement puppet in our network, I deployed two
> config files, puppetd.conf and puppetmasterd.conf. I''m primarily
> running Debian so my preferred vardir is /var/lib/puppet, and I''d
set
> that in the [puppet] section of puppetd.conf. I expected that to be
> read by puppetmasterd also, so that dir wasn''t defined in
> puppetmasterd.conf. I quickly realized that it didn''t and tried to
> get rid of puppetmasterd.conf and only have one file, puppetd.conf,
> with sections for all the different parts of puppet ([puppet],
> [puppetd], [puppetmasterd] etc.). But that didn''t work either :-
> ( Puppetd used /var/lib/puppet and puppetmasterd used /var/puppet - I
> expect that this is the reason why I''ve never got reporting
working...
This confusion is exactly what I''m hoping to fix by consolidating  
configuration files.
> My question is: Right now, should I use one config file, with one
> section for each part of puppet, and define $vardir under each
> section? If so, what should that file be named? puppet.conf? Or
> should I have conf files for each part, each with $vardir defined...?
It depends on whether you''re using a released version or not --  
0.22.4 still has per-process configuration files, and the code in svn  
uses a single configuration file.  That configuration file defaults  
to puppet.conf, and you would have a single ''main'' section
along
with, optionally, a section per process.
> As you can see, I''m confused... ;-)
Hopefully not for long. :)

  --
  I am a kind of paranoiac in reverse. I suspect people of plotting
  to make me happy.                     --J. D. Salinger
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

On May 21, 2007, at 19:42, Luke Kanies wrote:
> It depends on whether you''re using a released version or not --
> 0.22.4 still has per-process configuration files, and the code in svn
> uses a single configuration file.  That configuration file defaults
> to puppet.conf, and you would have a single ''main''
section along
> with, optionally, a section per process.
I''m using 0.22.4. So I have to at least have puppetd.conf and  
puppetmasterd.conf on the master (which I also manage with puppet),  
right...?
>> As you can see, I''m confused... ;-)
>
> Hopefully not for long. :)
Thanks for not keeping me in the dark! ;-)

--
Med venlig hilsen
Juri Rischel Jensen

Fab:IT ApS
Vesterbrogade 50
DK-1620 København
Tlf: 70 202 407 / Fax: 33 313 640
www.fab-it.dk / juri@fab-it.dk

On May 21, 2007, at 11:54 PM, Juri Rischel Jensen wrote:
>
> On May 21, 2007, at 19:42, Luke Kanies wrote:
>
>> It depends on whether you''re using a released version or not
--
>> 0.22.4 still has per-process configuration files, and the code in svn
>> uses a single configuration file.  That configuration file defaults
>> to puppet.conf, and you would have a single ''main''
section along
>> with, optionally, a section per process.
>
> I''m using 0.22.4. So I have to at least have puppetd.conf and
> puppetmasterd.conf on the master (which I also manage with puppet),
> right...?
Correct.  These individual files will still work in the next release,  
albeit with a warning.  You''ll preferentially want to create a single  
puppet.conf, though.

  --
  You will notice that BeOS has taken the best parts from all the major
  operating systems and made them its own.  We''ve got the power of the
  Unix command line, the ease of use of the Macintosh interface, and
  Minesweeper from Windows.     -Tyler Riti
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com