Re: Puppet modules organization

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XQefpraS2ml66TDEdfxCbQkDxHiGFq4FF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue 17 Jun 2014 04:54:45 PM CEST, Ewoud Kohl van Wijngaarden wrote: are: k), that in working. m for easy That's not against the modules view I expressed before, and it's against = what we have now, let me explain: A basic example, right now we have the class ovirt_infra::user, that is n= ot a profile, and it does not belong inside a profile module. If you see the link that you sent [1] it has this structure: Node -> Role -> Profiles -> Modules -> Resources Where a profile is: "Unlike roles, which are named in a more human representation of the serv= er function, a profile incorporates individual components to represent a log= ical technology stack" The users class does not fit in any case in that definition. Instead it's= in the modules level. But right now, our modules level is empty (we just have external modules = there) and what I propose is to extract all the individual classes that do not f= it the profiles definition to their own module (one per class, as they should be= logically independent at that level). Just as it explains on the same paragraph: "the webserver profile is made up of the httpd, memcache and php componen= ts. In Puppet, these lower level components are represented by your modules." So we are not using the profiles/roles pattern right now. And I proposed = using it (maybe not that explicitly, but that was the idea), and that require t= he modularization of a few classes that we already have. That post also agrees with modularization: "I=E2=80=99ve talked about profiles and roles like they are some special = case and modules being something else. In reality, all of these classes can be, an= d should be modularised. I make a logical distinction between the profile a= nd role modules, and everything else (e.g.: modules that provide resources)." a I vote for this also, so we will end up with a layout similar to this: site | - role | | - manifests | | | - puppetmaster.pp | | | - jenkins_master.pp | | | - jenkins_slave.pp | | ... | - profile | | - manifests | | - base.pp | | - jnlp_slave.pp | | - www.pp | | - nagios.pp | ...=09 | - ovirt_mod1 (custom module that is not a profile, like ovirt_user) | - ovirt_mod2 (custom module 2, for example, ovirt_repo) =2E.. That will help us easily control changes on the configuration of the host= groups, and review changes on that configuration too. But we will need another re= po to hold the sensitive parameters (passwords and all), maybe using hiera (I'v= e been playing with non-public gerrit repos, that can be useful). t I don't see this as a disadvantage, but as an advantage, having tests for= each module means that the tests are specific to that module, are clearer and = easier to write and troubleshoot. From that same author you can see that he's qu= ite used to create modules, instead of having one big module per installation= =2E It's fairly easy to write a script to run the tests on each module, that = should be no problem. --=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Email: dcaro(a)redhat.com Web: www.redhat.com RHT Global #: 82-62605 --XQefpraS2ml66TDEdfxCbQkDxHiGFq4FF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" --XQefpraS2ml66TDEdfxCbQkDxHiGFq4FF--