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 => Service['myapp'], } service { 'myapp': ensure => running, enable => true, } We implemented a prototype and published it at https://forge.puppetlabs.com/puppetlabs/transition. It's 0.1.0 code, basically first cut, just enough to build out and test the idea, but not all the rough edges are sanded off. There's more detail in the readme on the Forge page.We implemented a prototype and published it at https://forge.puppetlabs.com/puppetlabs/transition. It's 0.1.0 code, basically first cut, just enough to build out and test the idea, but not all the rough edges are sanded off. There's more detail in the readme on the Forge page. Does this pattern or capability make sense in the general context of Puppet? Is this a decent interim solution for something better currently under development? What do people think of this?
More flexible state management is something that is very much on my mind in recent times. As other products (like ansible) solve this much better.
Given the restricted malleability of the manifest language, I think your implementation is already quite advanced and will solve problems.
Regards, David -- * Always looking for people I can help with awesome projects * Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt Blog: http://club.black.co.at/log/ LinkedIn: http://at.linkedin.com/in/davidschmitt -- 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/5495B94C.8050000%40dasz.at. For more options, visit https://groups.google.com/d/optout.
