I''ve been rewriting our modules as and when to the more fashionable
parameterised structure. Running Puppet 3.x : our modules would look like
node ''bigEndian'' {
include app1::install, app2::install
}
class app1::install {
include/require nodejs
...app stuff..
}
class app2::install {
include/require nodejs
...app stuff..
}
rewriting them their more like:
node ''bigEndian'' {
include app1, app2
}
class app1 {
class { ''nodejs'' : running => true }
...app stuff..
}
class app2 {
class { ''nodejs'' : running => true }
...app stuff..
}
This fails as class nodejs can''t be called twice. I understand the
issue
with this as it''s paramerterised different values could be passed
through
in to the class.
Interested to see how people are handling this? inheritance?
Matt
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Okay, I searched the group (duh!) and seen that this has been covered multiple times already. On 25 July 2013 08:14, <foomatty@gmail.com> wrote:> > I''ve been rewriting our modules as and when to the more fashionable > parameterised structure. Running Puppet 3.x : our modules would look like > > node ''bigEndian'' { > include app1::install, app2::install > } > > class app1::install { > include/require nodejs > ...app stuff.. > } > > class app2::install { > include/require nodejs > ...app stuff.. > } > > rewriting them their more like: > > node ''bigEndian'' { > include app1, app2 > } > > class app1 { > class { ''nodejs'' : running => true } > ...app stuff.. > } > > class app2 { > class { ''nodejs'' : running => true } > ...app stuff.. > } > > This fails as class nodejs can''t be called twice. I understand the issue > with this as it''s paramerterised different values could be passed through > in to the class. > > Interested to see how people are handling this? inheritance? > > Matt > > -- > 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+unsubscribe@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users. > For more options, visit https://groups.google.com/groups/opt_out. > > >-- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
On Thursday, July 25, 2013 2:14:17 AM UTC-5, foom...@gmail.com wrote:> > > I''ve been rewriting our modules as and when to the more fashionable > parameterised structure. >Why? If your modules already do everything you want them to do, then switching to parameterized-style declarations has no upside, but (as you discovered) significant downside. Especially for classes that aren''t parameterized in the first place. Even if you choose to parameterize your classes, you are best off relying on automated data binding via Hiera and avoiding parameterized-style class declarations in your manifests. John -- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.