Hi John, Thanks for the info.
By the way, I started using the inherit pattern with params because of the myriad of Splunk modules out there that do it, including this one from Puppet Labs https://github.com/puppetlabs/puppetlabs-splunk I understand why the pattern is used, it makes it a bit easier to deal with variables, particularly with hiera. I also understand what you are saying. This is the sort of thing that can drive one nuts, heh. It would be nice if there was only one way to do things and the one way was also the right way, but such nirvana is hard to find. Thanks, Alex On Wed, Apr 30, 2014 at 7:15 AM, jcbollinger <john.bollin...@stjude.org>wrote: > > > On Tuesday, April 29, 2014 11:37:02 AM UTC-5, Alex Scoble wrote: >> >> Hi John, >> >> Thanks so much for your feedback. It's extremely useful for me at this >> stage of my education in the Puppet DSL. >> >> Here is the Puppet Users group thread where R.I. Pienaar said that he >> felt that using create_resources() was bad: https://groups.google. >> com/forum/?fromgroups#!searchin/puppet-users/create_ >> resources$20pienaar/puppet-users/lxYDKf7dgc0/TppS_7BFB9IJ >> > > > For the record, then, R.I. said "I dont tend to use create_resources as I > consider it about as bad as eval() :) ". I hardly find that an emphatic > and categorical condemnation. In fact, I think that lines up relatively > well with my own position on the matter, expressed earlier in this thread. > > > >> Responses to comments: >> >> 2. As far as I can see, I'm using class inheritance solely to make sure >> that class parameters are available to the main and sub classes. Maybe you >> are seeing that I'm using inheritance where it's not yet strictly needed? >> I'll have to look more closely at my code and fix any instances of >> inheritance where it's unnecessary. Thanks. >> >> > I think I was looking primarily at class kvm::virtnet. It is not > parameterized itself and it does not contain any resource parameter > overrides, so it cannot have any need to inherit from class kvm. Moreover, > class kvm is parameterized, so *nobody* should inherit from it. It looks > like you may be inheriting simply to avoid prefixing class kvm's variables > with 'kvm::' where you reference them, but that's poor form even when you > do use inheritance. > > If you are concerned about a possibility that class kvm::virtnet will be > evaluated before class kvm, so that the references to kvm's variables are > not resolved correctly, then 'include' class kvm instead of inheriting from > it. But that's dangerous and nearly pointless. It is dangerous because if > class kvm is declared via a parameterized-style declaration, and class > kvm::virtnet really is evaluated first, then catalog compilation will fail > -- as it would also do under the same circumstances with classes as you > present. It is nearly pointless because if you can rely on class kvm being > evaluated first so that catalog compilation succeeds, then class > kvm::virtnet doesn't need to inherit, include, or do anything else along > those lines to work properly. > > The caveat is that if class kvm is declared via 'include' or (I think) > hiera_include(), and class kvm::virtnet is also independently declared, > then it is possible for class kvm::virtnet to be evaluated first without > the catalog compiler crashing later. One possible approach to that problem > is basically just to say "don't do that". If class kvm::virtnet is > intended only for internal use by the module, as appears may be the case, > then document that clearly and be done with it. None of this is an issue > with respect to class kvm::virtnet being declared by class kvm, by the way; > if that's the only declaration of class kvm::virtnet then class kvm is > certain to be evaluated first. > > > John > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Puppet Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/puppet-users/QNZyd4ipB0U/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/35a23857-cc2c-445e-adb0-aa8ce404e760%40googlegroups.com<https://groups.google.com/d/msgid/puppet-users/35a23857-cc2c-445e-adb0-aa8ce404e760%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAETmVfTQ-SNAksDYGpDEbZs_7wA0ka--z_%2Bc6v49fc5qHZwSaA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
