Thanks. I will look at that as we move forward. To your NFS issue, that was one of the design decisions we made. I have 3 GIT repos (Dev, Stage, Prod). The Stage and Prod are on the same server. On dev I have every OS we support connected to it to run through all code before we push to Stage. With Foreman it is easy enough to move a host from PROD to Stage and then test the changes. We move hosts to Stage so we test across the board. Once all testing details are clean and the team / customer approves, we do a change to push into PROD.
Our old setup was on a single environment with Puppet 0.25 and a monolithic build. We had a lot of admins hacking the code with no version management. many with no understanding of puppet or even checking their syntax. As for Foreman we chose it to keep the first level admins from actually messing with code / configs. They trashed a lot of setups when we let them do that on the old config. On Wednesday, April 26, 2017 at 11:54:24 AM UTC-4, Rob Nelson wrote: > > > On Wed, Apr 26, 2017 at 10:45 AM James Perry <jjpe...@gmail.com > <javascript:>> wrote: > >> Since all of our Puppet code is in a source code repo and requires a >> change control to push to PROD, I don;t want to have to manually create a >> per host entry, either via the* case* statement or a *node.yaml* file as >> that requires a full regression test and verification before it moves to >> PROD. >> >> Via Foreman I can add puppet classes for *userX *and *userQ* to a >> specific server. As long as *sudo::sudoers::userX *and *sudo::sudoers::userQ >> *are defined in the Puppet code, then no change to modify code or custom >> hiera yaml files is required. This takes the sudo setups from having to be >> done per node in code to a point and click for the team that handles the >> tickets for the host definitions in Foreman. >> > > This is a complete aside to sudo, but I think your controls here do not > operate as you expect them to. Foreman, like hiera, is just separating your > data from your code, which is great. But changing data in either system can > have adverse effects in production. For example, I once changed the value > for an nfs exports list from an array to a string. That ... did not go > well! If only an integration test had been used to catch that, I could have > avoided a small outage and a remediation change. > > Personally, I prefer hiera to foreman or the PE Console classifier because > it's integrated with version control of the control repo and into my test > setup. But the point is, we use the same controls on data as code because > they have similar potentials for impacts in production. You may want to > revisit your controls, even if it's just to acknowledge the risk. > >> -- > Rob Nelson > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/7531f867-71b2-4782-b0fe-46c363d806b1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
