+1, I think this is terrific.
I need to examine this against my normal workflow, which uses much more
bootstrapping (orchestrated hiera checkouts + additional puppet runs) - this
seems like it’s a much cleaner way to do the same thing.
I have a back-of-mind worry about a run stages-like level o
I agree. I hope to find some time to dig into the transaction layer and
make some of the catalog manipulation a bit cleaner.
I've done something similar a few times but never thought about doing it
this way so I'm very happy with this and hope to contribute!
Trevor
On Sat, Dec 20, 2014 at 3:53 P
This is awesome. I've recommended it to my old work. This is absolutely
necessary when automating some of the hairy enterprise apps I've worked
with.
--
Spencer Krum
n...@spencerkrum.com
On Sat, Dec 20, 2014, at 10:00 AM, David Schmitt wrote:
> On 2014-12-19 22:14, Reid Vandewiele wrote:
> >
On 2014-12-19 22:14, Reid Vandewiele wrote:
transition { 'stop myapp service':
resource => Service['myapp'],
attributes => { ensure => stopped },
prior_to => File['/etc/myapp/myapp.cfg'],
}
file { '/etc/myapp/myapp.cfg':
ensure => file,
content => 'mycontent',
notify => S
This thread is introducing a simple workaround for an observed limitation
in Puppet's ability to automate inelegant but real configuration
requirements. The desired outcome is to get feedback on the suitability of
the workaround or its approach, how well it fits with Puppet's paradigm,
and whet
