Hi folks, last week I asked a question on how to sensibly structure a puppet setup:
https://ask.puppetlabs.com/question/1932/how-to-tier-a-puppet-setup/ I received a quite sensible request, even though it's not what I wanted to hear. The reason it's not, might be because I haven't been quite able to get my point across: Let's go with the example of hosting and develop that: We have (among other things) a hosting service. Each customer gets their own instance of httpd running on a seperate port and a seperate user. They can have any number of vhosts, but most only have one. They can have any kind of setup, but most choose PHP + MySQL, the rest has static pages. Each of these vhosts has a separate scp-user. (The db/user and scp-user for each vhost have the same name). The web is terminated by a caching proxy (Apache Traffic Server). If I were to express this as data of its own, not data that will fill a puppet apache, or puppet trafficserver or mysql module, I'd express it like this in yaml: --- excom: instance: example.com port: 8005 vhosts: - servername: www user: excomwww scp_password: xxx type: static - servername: beta user: excombeta scp_password: zzz db_password: yyy --- exorg: instance: example.org port: 8006 vhosts: - servername: www user: exorgwww scp_password: xxx db_password: zzzz - servername: mail user: exorgmail scp_password: sseeecret db_password: reellyyseecrreet With the implicit defaults in mind for this service, we specify only when something deviates from them. With 90% of vhosts being PHP, we specify that the `www` vhost is `static` This `static` may in turn overwrite other defaults such as `db_provider => mysql` with `db_provider => none`. What I'm trying to say here is: Rather than building this data as each puppet module would expect it, I build it such that it makes sense to us admins and developers. * * * This whole aproach has a number of implications. First of which is that we don't treat hiera as a nice-to-have tack on, but that we intristically rely on it. Second, the data in hiera does in no way reflect what a puppet module that finally writes the configuration would expect. This in turn means that we need a puppet module which can make sense of the data, enriching it and filling the gaps where necessary. If we continue from the hosting example, we can roughly split it in `hosting::lb` (for trafficserver), `hosting::web` (for handling the httpd config, as well as the creation of users as necessary), and `hosting::db` module (which, as we've seen can be optional in some cases where the site is static). There are two competing solutions to my problem: #1: have the "parsing" code in each of those classes #2: have the "parsing" code in an über class. This would be the web class, and it would dispatch the data to the other two via exports. The first solution has the obvious problem of code-duplication. The second doesn't scale with large numbers when customer grow beyond a couple of thousand, as export/collect will be very slow. However, this is not a problem we're facing right now… ;) I'm leaning towards the über-class, but would love to hear some feedback on whether I'm making any sense at all and how you would aproach such problems! Thank you very much in advance, -- i Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
