[Mageia-sysadm] Questions about puppet config

[Michael Scherer]

Le mardi 19 juillet 2011 à 02:54 +0200, sebelee at free.fr a écrit :
> After regarding a little bit the puppet configuration, I have some questions about the current puppet configuration.
> 
> 
> 1) Why using both subscribe() and notify() metaparameters ?

Mainly a question of style. 

You can use the graph feature to see everything :
http://bitfieldconsulting.com/puppet-dependency-graphs
( except that we do not provides them purely by slack )

I guess a simple task to learn puppet would be to make them usable by
everybody. But I can also do it quite fast, if you need to look to the
graphs.


> 2) In the same idea, after reading the beginning of the book "Pro Puppet", the author 
> describes a sort of Best Pratice for managing puppet's module.

This seems quite overkill for simple module, and I am not sure it will
help to reduce so much the complexity on complex module ( such as sympa
or subversion ). While I would agree that we should have some shared
style to help rereading the code, I also think this is one issue that
can trigger some heated arguments. Despite being annoyed every day by
the mix of space and tabs in subversion or buildsystem, I never pushed
for uniformisation there, but maybe that should be done. 

> 
> 3) With this schema, we can also classify specials functionnalites or class by creating one or more extra file(s) 
> 
>
> I'm just a beginner with puppet and I don't know if this a method can work 
> for a production environnement day after day...

It greatly depend on what you mean by "work" :)

I do not see obvious reasons it would break something, and to me, the
question is just to know if too much division will really improve
comprehension.

It is like java. I like the java layering and separation of modules, at
least on paper, it is quite clean. In practice, there is this feeling of
awful complexity due to the separation and heavy use of object
hierarchy :/

I can understand your frustration of having to read a large corpus of
code/configuration without having this feeling of a clean base ( ie,
different conventions, lack of style, etc ). And we do have some need
for cleaning and consistency for sure.

But on the other hand, having a too rigid structure of things may have
been too constraining for a small team, to start. 

> But i think instead of having all the module's classes in a same file, split them 
> into specifics items would be more easy for understanding and also give more granularity.

The granularity is already achieved at class level, and I think we are
quite good at this point. Too much would maybe be over-engineering at
this point, we only have 7 servers :)

-- 
Michael Scherer