On Friday, December 19, 2014 3:14:23 PM UTC-6, Reid Vandewiele wrote: > > 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 > [...], 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. >
I agree that this is a longstanding issue, with no particularly good solution up to now: "write a full-blown type and/or provider" is not a realistic recommendation for most people and most requirements. I'd go so far as to say that it is an *inappropriate* solution in some cases. > What if we had the ability to model transitional states as part of the > catalog? > [...] > 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? > > I went looking for holes to poke in this approach, and didn't find any. I like that it builds on Puppet's core concepts of resources and state, and that it appears to be general enough to be adapted to a wide variety of situations. Having read the docs but not examined the code, I am curious about management of the Transition type's own state. How does it "look ahead" to determine whether it is already in sync? I guess it invokes 'in_sync?' on each of the 'prior_to' resources, or something like that? Also, I presume a Transition resource fails if it is not initially in sync and it cannot apply the transitional state it describes. Is that correct? And does the transitional state copy/inherit anything from the target final state given for the named resource, or does it have only the (explicit) attributes specified in the Transition resource? I'm also curious about the nature of some of the documented limitations. With regard to the transitioned resource being of native type, don't defined type instances have a representation in the catalog? Classes do. For that matter, are classes excluded from being the transitioned resource? The more I think about it, the more I foresee potential for difficulties if defined type instances or classes were eligible for transitioning. On the other hand, I'd be open to the argument that it's ok to offer additional capability to manifest writers in exchange for opening (more) possibilities for shooting themselves in the foot. With regard to 'noop' parameters, is it your thinking that the transition should not be performed if all the 'prior_to' resources have 'noop' enabled? What about the transitioned resource? I'd be inclined to say that the Transition resource *shouldn't* look at 'prior_to' resources' 'noop' parameters. If 'noop' is being applied on a per-resource basis, then the responsibility should be on the manifest developer to apply 'noop' to the Transition resource where needed. On the other hand, I think you should consider whether the transitional state should automatically be marked with the same 'noop' value as the final state of the transitioned resource, at least by default. I haven't reached a conclusion on that myself, but it seems more likely to be appropriate than basing the Transition's noop on the 'prior_to' resources'. I also have to ask: will this work with Puppet 4? All my questions notwithstanding, I think this is a really cool and useful idea. Thanks! John -- 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/e8eba24f-4424-4eff-b533-ce99f93892a8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
