It seems to me that a few puppet modules do access variables from non-included classes (for example https://github.com/puppetlabs/puppetlabs-mysql/blob/master/manifests/config.pp look at how stuff is pulled out of mysql::params). I do not understand how this is supposed to work. What happens if you do this from a parameterized class, and include it later with distinct parameters ? Is that even legal ? What about resources that might be in mysql::params ? Or is that just working because of the inheritance ? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/1cTUWR_1HGcJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Monday, October 15, 2012 4:27:06 AM UTC-5, Simon Marechal wrote:> > It seems to me that a few puppet modules do access variables from > non-included classes (for example > https://github.com/puppetlabs/puppetlabs-mysql/blob/master/manifests/config.pp look > at how stuff is pulled out of mysql::params). > >That example works because the class inherits from mysql::params. It is a pattern that has come into vogue for making another class''s variables accessible for use as class parameter defaults. Included classes'' superclasses are automatically included, much as if the superclass were ''include''d just prior to each declaration of the subclass (whether via parametrized syntax, ''include'', or ''require'').> I do not understand how this is supposed to work. What happens if you do > this from a parameterized class, and include it later with distinct > parameters ? >What''s "this"? Are you asking about what happens if the superclass is itself parametrized? That is not supported. If you happen to do it anyway, however, the result is similar to what would happen if you ''include''d the superclass instead of inheriting from it -- as long as the parametrized declaration is parsed first, everything will compile and the class will have the parameters from the parametrized-form declaration. If the parametrized declaration is parsed second, however, then catalog compilation will fail. I advise you to avoid all that, and instead just don''t inherit from parametrized classes. In fact, in a reprise of my "voice crying in the wilderness" routine, I will urge you to avoid writing new parametrized classes for any context or purpose. Puppet 3''s integration of hiera with class parameter resolution provides a nice backstop for people who invested in developing parametrized classes, but parametrized classes still have serious deficiencies in Puppet 3 (and worse deficiencies in Puppet 2). Do write them. If you need to use parametrized classes written by someone else, then at all costs avoid parametrized class declaration syntax; instead use the good old ''include'' function (or the ''require'' function). Feed non-default parameter data to them via hiera (requires Puppet 3).> Is that even legal ? What about resources that might be in mysql::params ? > Or is that just working because of the inheritance ? >Any resources declared in class mysql::params are assigned to nodes that declare any of its subclasses. That''s an aspect of Puppet class inheritance. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/L49ZS0nKgVsJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Monday, October 15, 2012 9:03:50 AM UTC-5, jcbollinger wrote:> > [...] parametrized classes still have serious deficiencies in Puppet 3 > (and worse deficiencies in Puppet 2). Do write them. > >I meant do *not* write them, of course. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/XVUvUQtZj74J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mon, Oct 15, 2012 at 9:38 AM, jcbollinger <John.Bollinger@stjude.org> wrote:> > > On Monday, October 15, 2012 9:03:50 AM UTC-5, jcbollinger wrote: >> >> [...] parametrized classes still have serious deficiencies in Puppet 3 >> (and worse deficiencies in Puppet 2). Do write them. >> > > I meant do not write them, of course.John, Can you suggest an alternative to parameterized classes? -mz -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Monday, October 15, 2012 9:43:48 AM UTC-5, Matt Zagrabelny wrote:> > Can you suggest an alternative to parameterized classes? > >Funny that you ask. I just did exactly that a few doors down: https://groups.google.com/forum/#!msg/puppet-users/dICUPHn3azY/b0wJaiSbs8kJ . I''m afraid I waxed long-winded, but there is an example in there. Basically, though, it''s to use hiera, and to do so explicitly instead of via 3.0''s hiera / class parameter integration. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/ZNXpUwtq3UgJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 16 October 2012 01:03, jcbollinger <John.Bollinger@stjude.org> wrote:> In fact, in a reprise of my "voice crying in the wilderness" routine, I > will urge you to avoid writing new parametrized classes for any >I hear you -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
John, I''m new to puppet and your mails confuse me a little bit... if parameterized classes are not recommended and you suggest when dealing with someone else parameterized class to set it through hiera (Puppet 3). Then I don''t understand how to proceed with puppet 2 modules... Should I hack every module I need to set the defaults inside the module? If this is the way, what if I need to reuse the module with different defaults? I thought a good module was a module I don''t need to touch and I can set my defaults from my call, with this approach as soon I start using a module I''ll likely not keep up to date with it, as it will have to deal with all the hacked code during upgrades. And if making a module, without using parameters, how I can reuse the module with different defaults ? Should I create a different params.pp for each scenario I need and then include it inheriting each one of the defaults, this would be a mess to deal with large arquitectures with many different types of nodes. I''m sorry to ask but since we started using puppet (a few months ago) we started doing everything with parameters as puppet docs said on http://docs.puppetlabs.com/guides/parameterized_classes.html and since then we had no issue (yet) with it. And now you say that parameters are a sickness and should not be used. Then how on Puppet 2? And why it''s still puppet docs still recommending it? Thanks in advance for your time! Guzmán On Mon, Oct 15, 2012 at 6:56 PM, jcbollinger <John.Bollinger@stjude.org>wrote:> > > On Monday, October 15, 2012 9:43:48 AM UTC-5, Matt Zagrabelny wrote: >> >> Can you suggest an alternative to parameterized classes? >> >> > Funny that you ask. I just did exactly that a few doors down: > https://groups.google.com/forum/#!msg/puppet-users/dICUPHn3azY/b0wJaiSbs8kJ. I''m afraid I waxed long-winded, but there is an example in there. > Basically, thoug >h, it''s to use hiera, and to do so explicitly instead of via 3.0''s hiera /> class parameter integration. > > > John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/ZNXpUwtq3UgJ. > > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- GuruHub - Guzmán Brasó http://www.guruhub.com.uy - +59898674020 Rivera 3565 - CP11400 - Montevideo, Uruguay -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Sunday, October 21, 2012 6:02:39 PM UTC-5, Guzmán Brasó wrote:> > John, > > I''m new to puppet and your mails confuse me a little bit... if > parameterized classes are not recommended and you suggest when dealing with > someone else parameterized class to set it through hiera (Puppet 3). > Then I don''t understand how to proceed with puppet 2 modules... >Here are some of your better choices, none of them especially good: 1. Upgrade your master to Puppet 3. The clients can stay at 2.7 if you wish. 2. Avoid third-party modules whose interfaces involve parametrized classes, unless they have built-in hiera support. 3. Be very careful and deliberate with the placement of your parametrized-style class declarations, and expect to troubleshoot parse order issues from time to time.> > Should I hack every module I need to set the defaults inside the module? >That''s an option too, but I wouldn''t recommend it.> > And if making a module, without using parameters, how I can reuse the > module with different defaults ? Should I create a different params.pp for > each scenario I need and then include it inheriting each one of the > defaults, this would be a mess to deal with large arquitectures with many > different types of nodes. >That is what hiera is for. Although not integrated into the core until Puppet 3, hiera is a widely-used add-on to Puppet 2. Instead of class mymodule::foo ( $param1 = ''default1'', $param2 = ''default2'' ) { # declarations } I recommend some variation on class mymodule::foo { $param1 = hiera(''foo::param1'', ''default1'') $param2 = hiera(''foo::param2'', ''default2'') # declarations } Then put any needed ''parameter'' customizations into your hiera data. That way not only can you avoid parametrized-style class declarations, but you also achieve separation of your data from your code.> > I''m sorry to ask but since we started using puppet (a few months ago) we > started doing everything with parameters as puppet docs said on > http://docs.puppetlabs.com/guides/parameterized_classes.html and since > then we had no issue (yet) with it. And now you say that parameters are a > sickness and should not be used. Then how on Puppet 2? And why it''s still > puppet docs still recommending it? > >Puppetlabs heavily promoted parametrized classes starting with their release as part of Puppet 2.6. Evidently, they perceived and continue to perceive substantial demand for such a feature. That doesn''t mean it was ever a good idea. Having promoted the feature so effectively puts PuppetLabs in a difficult position. At least some of their people will acknowledge the problems with parametrized classes, at least in Puppet 2.x. I can only speculate about company policy here, but it would be reasonable for PL to judge that doing an about-face on parametrized classes could present credibility and trust issues for the company. PL put a lot of effort into improving parametrized classes for Puppet 3, and they are indeed better. As I have lately written, I think the result rescues a lot of parametrized classes that are already in use. That doesn''t mean that it''s a good idea to write new parametrized classes even for Puppet 3, however. And of course, a lot of people are using parametrized classes successfully. My argument has never been that they don''t work, only that they exact unneeded costs in productivity and stability relative to the best available alternative. Those costs will scale with the number of dependencies between classes. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/r53hq-Tk8CsJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
John: Very concise and helpful answer, thank you very much for your time! Best regards from Montevideo, Guzmán On Mon, Oct 22, 2012 at 12:37 PM, jcbollinger <John.Bollinger@stjude.org>wrote:> > > On Sunday, October 21, 2012 6:02:39 PM UTC-5, Guzmán Brasó wrote: >> >> John, >> >> I''m new to puppet and your mails confuse me a little bit... if >> parameterized classes are not recommended and you suggest when dealing with >> someone else parameterized class to set it through hiera (Puppet 3). >> Then I don''t understand how to proceed with puppet 2 modules... >> > > > Here are some of your better choices, none of them especially good: > > 1. Upgrade your master to Puppet 3. The clients can stay at 2.7 if > you wish. > 2. Avoid third-party modules whose interfaces involve parametrized > classes, unless they have built-in hiera support. > 3. Be very careful and deliberate with the placement of your > parametrized-style class declarations, and expect to troubleshoot parse > order issues from time to time. > > > >> >> Should I hack every module I need to set the defaults inside the module? >> > > > That''s an option too, but I wouldn''t recommend it. > > >> >> And if making a module, without using parameters, how I can reuse the >> module with different defaults ? Should I create a different params.pp for >> each scenario I need and then include it inheriting each one of the >> defaults, this would be a mess to deal with large arquitectures with many >> different types of nodes. >> > > > That is what hiera is for. Although not integrated into the core until > Puppet 3, hiera is a widely-used add-on to Puppet 2. Instead of > > class mymodule::foo ( > $param1 = ''default1'', > $param2 = ''default2'' ) { > # declarations > } > > I recommend some variation on > > class mymodule::foo { > $param1 = hiera(''foo::param1'', ''default1'') > $param2 = hiera(''foo::param2'', ''default2'') > # declarations > } > > Then put any needed ''parameter'' customizations into your hiera data. That > way not only can you avoid parametrized-style class declarations, but you > also achieve separation of your data from your code. > > > >> >> I''m sorry to ask but since we started using puppet (a few months ago) we >> started doing everything with parameters as puppet docs said on >> http://docs.puppetlabs.com/**guides/parameterized_classes.**html<http://docs.puppetlabs.com/guides/parameterized_classes.html> and >> since then we had no issue (yet) with it. And now you say that parameters >> are a sickness and should not be used. Then how on Puppet 2? And why it''s >> still puppet docs still recommending it? >> >> > Puppetlabs heavily promoted parametrized classes starting with their > release as part of Puppet 2.6. Evidently, they perceived and continue to > perceive substantial demand for such a feature. That doesn''t mean it was > ever a good idea. > > Having promoted the feature so effectively puts PuppetLabs in a difficult > position. At least some of their people will acknowledge the problems with > parametrized classes, at least in Puppet 2.x. I can only speculate about > company policy here, but it would be reasonable for PL to judge that doing > an about-face on parametrized classes could present credibility and trust > issues for the company. > > PL put a lot of effort into improving parametrized classes for Puppet 3, > and they are indeed better. As I have lately written, I think the result > rescues a lot of parametrized classes that are already in use. That > doesn''t mean that it''s a good idea to write new parametrized classes even > for Puppet 3, however. > > And of course, a lot of people are using parametrized classes > successfully. My argument has never been that they don''t work, only that > they exact unneeded costs in productivity and stability relative to the > best available alternative. Those costs will scale with the number of > dependencies between classes. > > > John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/r53hq-Tk8CsJ. > > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- GuruHub - Guzmán Brasó http://www.guruhub.com.uy - +59898674020 Rivera 3565 - CP11400 - Montevideo, Uruguay -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mon, Oct 22, 2012 at 7:37 AM, jcbollinger <John.Bollinger@stjude.org> wrote:> PL put a lot of effort into improving parametrized classes for Puppet 3, and > they are indeed better. As I have lately written, I think the result > rescues a lot of parametrized classes that are already in use. That doesn''t > mean that it''s a good idea to write new parametrized classes even for Puppet > 3, however.I''m curious what''s your perceived shortcomings in Puppet 3 with parametrized classes with hiera lookup builtin? Thanks, Nan -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Monday, October 22, 2012 12:26:15 PM UTC-5, Nan Liu wrote:> > On Mon, Oct 22, 2012 at 7:37 AM, jcbollinger <John.Bo...@stjude.org<javascript:>> > wrote: > > PL put a lot of effort into improving parametrized classes for Puppet 3, > and > > they are indeed better. As I have lately written, I think the result > > rescues a lot of parametrized classes that are already in use. That > doesn''t > > mean that it''s a good idea to write new parametrized classes even for > Puppet > > 3, however. > > I''m curious what''s your perceived shortcomings in Puppet 3 with > parametrized classes with hiera lookup builtin? > >The key problem is not with the parametrized classes themselves, but with using parametrized-style class declarations. Puppet 3 still will not accept a parametrized-style class declaration except as the first declaration of that class, and that makes such declarations dangerous at best and useless at worst. Given that Puppet cannot accept inconsistent declarations of a given class, why does it make sense for the language to facilitate them? Isn''t this similar in kind to the problem with dynamic scoping? Sure, you can use ''include'' everywhere instead, but then what did you need class parametrization for in the first place? We had a bit of a discussion on that question last week, actually: https://groups.google.com/forum/#!topic/puppet-users/dICUPHn3azY . I''m not persuaded that class parametrization any longer has any value beyond backwards compatibility now that hiera is in the core. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/UT-8Kb_aQkMJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> On Mon, Oct 22, 2012 at 12:37 PM, jcbollinger <John.Bollinger@stjude.org> wrote: > $param1 = ''default1'', > $param2 = ''default2'' ) { > # declarations > } > > I recommend some variation on > > class mymodule::foo { > $param1 = hiera(''foo::param1'', ''default1'') > $param2 = hiera(''foo::param2'', ''default2'') > # declarations > }As puppet is changing way of setting parameters every 6 month (and me too, as i changed my mind about the best way to do it), I really dislike to put hiera usage inside my class definition. I rather use a configuration class where I can easily change way of settings values. It might look like for example : class config::module { $param=mood_of_the_day(something) } and then calling class {''module::foo'': param =>p config::module::param } Using this method I have been able to switch from extdata to hiera in a few hours of works. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.