sjm...@pobox.com (Simon J Mudd) writes: > john.bollin...@stjude.org (jcbollinger) writes: > > > In fact, Puppet Labs's own recently updated style guide recommends > > against using extlookup(), though that position is controversial. > > I found the URL: http://docs.puppetlabs.com/guides/style_guide.html > > "The extlookup() Function > > Modules should avoid the use of extlookup() in favor of ENCs or other > alternatives." > > The statement is clear, but it would be nice to know the reasoning. > That is if there's a problem with extlookup() then it would be good to > know what it is. This may have been discussed elsewhere but it > shouldn't be necessary to have to go and search for this.
In the end I did. http://groups.google.com/group/puppet-users/browse_thread/thread/34e4dfb4828a2835/d9f6d8d6c7bba841?show_docid=d9f6d8d6c7bba841 It is a good read. However, from the discussion a few things strike me: 1. the use of parameterised classes is recommended heavily. I've just found out about this "new feature" inspite of using puppet for a long time. Hence many recipes that I'm using are not paremeterised and I have a large number of similar classes. This is certainly worth fixing but is quite a painful transition to make given the number of systems in use and the chance of creating heavy breakage during that change. So if you haven't used parameterised classes much that's the first thing that needs looking at. 2. Does puppet provide an ENC? The dashboard? Again if you're not using one switching over is a heavy tasks as you have to define _everything_ first before you can use it. (that's how it seems to me). I recently attended a puppet master course and it's content was interesting, but despite there was little emphasis on this sort of thing "getting the high level design right" and more on the nitty gritty of the usage of the lower-level resource types. To push the use of an ENC it seems that this higher level planning would be most helpful. Also a real-life overview of how this would be implemented. Saying how to configure an ssh server doesn't count. I'd be interested in the "deployment" of a series of database servers, their configuration, setup, and how to take into account differences between one set of boxes and another. If I can relate to a use case that fits my own (using an ENC) and there's a way to slowly bring in more systems into using this ENC then it makes it easier to follow that path. The alternative of using an extlookup() behaviour does indeed have the inconvenience of hiding some behaviour depending on external aspects which are picked up by the extlookups, but if you already have working recipes perhaps and aren't using an ENC this gives you a way to clearly remove the conditional logic the recipes currently have. It's then a smaller step "up" to using an ENC if you want to go that way. For those that don't it still becomes reasonably clear where the configuration is parameterised and how/why that's done, so it's still a more flexible approach. Judging from people I've listened to at the last puppet camp there are many ways to use puppet. Sites vary from small to very large and there's no clear "one solution" fits all. So I'm inclined to agree that a extlookup() [ or get_config_by_key lookup] mechanism may work fine for a lot of people. As long as you know and understand the limitations of the approach you are taking that's fine. Again the ENC setup described to me at the course I went on did not mention parameterised classes, but simple variable settings and classes. I guess that will change as perhaps if you use parameterised classes the enc should do nothing other than provide a definition of the parameterised classes to use and their initial setup valus. Removing the global variables would ensure that each class's behaviour is encapsulated only by it's input parameters and that does sound much more reasonable. Simon -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
