On Thursday, 19 March 2015 20:30:08 UTC+1, John Bollinger wrote: > > Why? You have two separate masters managing disjoint aspects of the > target machines, via disjoint sets of agents. Why do they need (or even > want) to share *anything*? > Right. So what is the advantage in them sharing anything at all? >
You are right to ask that question. Sharing modules in the same repository instead of having two repos is kind of easier, it means less fiddling around with clones and pulls. - both puppet masters use the same ENC already >> > > Why? Each master needs to classify nodes altogether differently than the > other. How does it make sense for them to use the same ENC? Not that it > really matters, I guess. > The truth is you could go about this two ways: 1. two puppet masters, serving content for each node by the same environment name 2. single puppet master, and having two puppet environments for each "environment", one with certain suffix I prefer first method, as secondary duplicates the effort when deploying updates, as noted before. With this feature, I could downsize the management to: >> - single environment repository, with environment.conf for primary and >> environment.conf-secondary for secondary puppet master process >> - (please note that I have already patched puppet master so that it >> supports configurable name for "environment.conf") >> > > > Wait, are you trying to get rid of your need for separate > `environment.conf` files, or not? It sounds like you intend to continue > with that mod, but if so, then I don't see why it doesn't already address > all the issues you describe. > Having two environment.conf files is the least of my worries, as this is "set and forget" thing. All I am striving for is replacing two dirs where I need to "git pull" with a single dir, where I do that only once for each environment. I can achieve what I describe here by doing the following: - have two masters using same paths for directory environments - secondary master has environment.conf filename changed to something else, i.e. added suffix -secondary - in each environment, environment.conf and environment.conf-secondary exist. The second one points puppet to the same module dir, but to different manifest dir. - secondary manifest is a single catch-all node definition (well, almost) that only includes module for primary puppet's installation - as this secondary manifest/catalog is so simple, there is little reason to keep it in separate dir/gitrepo - it is better to keep in in the same repo and point puppet to it when needed Now, this works, but it feels a bit clunky. It feels like it could be done in a more generic way. This is the reason why I came up with the EEL idea. The more I think about it, the more natural it seems for puppet. Maybe it is just me. Best regards, b. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/dfbf2d80-10d5-4339-9097-6dbe627bc042%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
