On Mon, Dec 22, 2014 at 9:11 AM, John Bollinger <john.bollin...@stjude.org> wrote:
> > [...] > > 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? > Effectively, yes. For each prior_to resource the provider will retrieve it from the catalog, call insync?() against each of its properties, and if any are found that are not in sync that triggers the transition. For specifics see https://github.com/puppetlabs/puppetlabs-transition/blob/master/lib/puppet/provider/transition/ruby.rb#L49-L66 (about 16 lines). > 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? > Yes. Right now all attribute defaults in the transition resource are inherited from the target final state resource. Now that you mention it I can imagine that this might not always be the desired behavior, so it could make sense to introduce a parameter that affected whether or not the transitional state had this implicit relationship to the target state. The current behavior was mostly chosen for convenience. I'd be curious to think through a specific scenario where the difference was important. One doesn't spring to mind immediately for me. Obviously it's possible already to be explicit about many/all attributes in the transition declaration. > 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. > Allowing defined types or classes to be eligible for transitioning certainly makes things more complicated. The problem is that defined types and classes could have logic in Puppet code that dictates which resources to create and add to the graph. If statements, case statements, variables - the provider doesn't have access to any of that Puppet code. If a property or parameter on a defined type or a class is set to a different value in Puppet code, it's possible that an entirely different set of resources could be created. This is the root of the native type only limitation. At the time transition operates, none of the Puppet code exists anymore, only the raw catalog itself. To the best of my knowledge, the graph-level representation of a class is a pair of whits with relationships to each resource from the class. I've been imagining defined types to be the same. This is likely enough to identify which resources came from a particular class or defined type, but I suspect it isn't enough to confidently change a defined type or class parameter. I would appreciate a check though on that from someone more familiar with how the catalog is put together and what information is available. > 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 think marking the transitional state with the target resource's noop value as default would be the way to go. This is not a design limitation, just work that has yet to be done. I also have to ask: will this work with Puppet 4? > It should absolutely work with Puppet 4! :-) If it doesn't I think it'll be because of interface-level changes, and I can't imagine it would take too much work to fix it. ~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/CAHNFGkNa7oSouQNJGQQZgtJe2W0TC9ttNLp1t-Q218bQiE08Qw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
