-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> dont you find having to specify the relationships of httpd::ssl and
> httpd here to be wrong?
>
> Isn't the fact that the httpd module is designed to have this
> ordering requirement an implementation detail and not a usage
> detail?
>
> Surely people who just want to use the httpd module do not need to
> know this implementation detail? They should just be able to say use
> the module without understanding or knowing the ordering of
> internals.
>
> It's also not very DRY.
Yep, I also recently started thinking about various new introduced
problems I see with parametrized classes. For example, how could I do
the following in the future with parametrized classes:
class apache {}
define apache::vhost(){
include ::apache
...
}
so the user only needs to define:
apache::vhost{'example.com': }
and everything else is pulled in automatically.
This gives a very nice interface, is easy to use and if this way of
writing puppet code wouldn't be anymore possible my infrastracture code
would get *very* overloaded and ugly.
And as R.I.Pienaar outlined later, we learned in the past to deal with
the current scoping problems, but still producing more or less nice
code. Although, I agree that parametrized classes provide a much nicer
interface and I'm very happy they got introduced, I'm already seeing
some problems with them:
class apache($version = 'latest') {}
define apache::vhost(){
class{'apache': }
...
}
This will raise problems if we define a second vhost. With the current
scoping issues and my rule of thumb ("First define all variables, then
include classes") I had no problem with writing:
$apache_version = '2.2.18'
apache::vhost{'example.com': }
apache::vhost{'cdn.example.com': }
But how would I do that now?
A possible solution would be to put the variables in a config class:
class apache::config($version='latest'){}
class apache {
package{'apache':
ensure => "${apache::config::version}",
}
}
define apache::vhost(){
include ::apache
...
}
and then write:
class{'apache::config': version => '2.2.18' }
apache::vhost{'example.com': }
apache::vhost{'cdn.example.com': }
But how can I ensure that apache::config is loaded/included/applied when
we include ::apache?
I currently only see:
class apache {
if !defined(Class['apache::config']){
class{'apache::config': }
}
package{'apache':
ensure => "${apache::config::version}",
}
}
But this raises other ordering problems and breaks another rule of thumb
of mine: Never use defined() as it can be seen as codesmell, for example
exactly due to the ordering problems it raises.
But this is the best solution I can currently come up with. Although, it
still smells in my opinion.
~pete
PS: Sorry, to come up with code examples, however I think I can express
the current *new* limitations with them the best way. I will try to
think about a non-code discussion contribution and maybe add it later to
the thread.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0rgaYACgkQbwltcAfKi38w4gCeJ8j3B6zcilYnXicgambV5Ty7
eqwAn1L86SUkKuMYwKTnVopNNgNntBBW
=ODmw
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
