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 whether or not people would find it acceptable to implement this kind of pattern in their own environments.
tl;dr: What do people think of https://forge.puppetlabs.com/puppetlabs/transition ? The Problem: Puppet has always been tightly focused on a single, final target state. When iterating over resources in the graph, Puppet examines resources one by one and if necessary makes configuration changes to bring them into compliance with that one true target state. It is expected that at the end of the run, every resource in the graph will still be in that target state. This is generally a decent way to model things, but there are some situations where it isn't quite enough. For example, if a running service locks a file (Windows often does this), that file cannot be changed unless the service is stopped. Procedurally, to edit the file one would be expected to stop the service, make the change to the file, and then start the service back up. Similarly, when installing software a procedure may say to download the installation media to a temporary directory, use it to install the software, and finally remove the installation media (as it is no longer necessary to keep it). Unless the underlying provider has built-in logic that handles those kinds of temporary changes within the context of a single resource, it is very difficult to model these "transitional states" in Puppet. There are a few contexts where it kinda makes sense to extend a provider to encompass a transition state, such as a package provider downloading a source file to keep temporarily, but often times supporting transitional states in the context of a provider would feel like bloat, and not good design. The Experiment: What if we had the ability to model transitional states as part of the catalog? Chris Barker, myself and a few others were brainstorming about this a little while back and came up with the idea to insert a resource into the graph that had a kind of reverse-notify behavior, where it would enact a specified state on another resource, temporarily, if and only if another specified resource ahead of it in the graph was going to change. For example: 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? ~Reid -- 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/6b2b305c-fb2c-4832-9990-35cfe89a6a06%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
