> Whenever we want to add additional parameters to certain classes,
> unless we update that class and the YAML that drives it atomically
> everywhere, we end up in a situation where the YAML does not match the
> parameterised class and causes errors.
Warning: brainstorm ahead.
As long as you can sensibly default your new parameters there shouldn't
be a problem.
If puppet won't allow the ENC to rely on defaults then that would be a
bug in puppet,
I should think. I haven't tried it, though. So I can't report from
experience.
If you think of your module names as interface handles your problem goes
away.
When you change the interface you naturally change the module name as well.
Did you depart from the foo interface? Great, your new module is named
foo2,
and gets its own YAML and ENC section.
Conversely, any change that does not change the interface (say adding
another distro)
does not require a new name.
This introduces other problems, such as having canonical names for
classes/modules.
Not sure how far this idea could be taken, but aliasing names is sort
of possible:
vagn@nika:~/puppet-nika/patterns$ cat alias.pp
#! /usr/bin/puppet apply
class foo {
notice("this is SPARTA!")
}
$provides_sparta = 'foo'
include $provides_sparta
vagn@nika:~/puppet-nika/patterns$ ./alias.pp
notice: Scope(Class[Foo]): this is SPARTA!
notice: Finished catalog run in 0.15 seconds
--
vagn
--
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.
