On 23.2.2012 15:52, Nigel Kersten wrote: > > > On Thu, Feb 23, 2012 at 5:21 AM, Markus Falb <[email protected] > <mailto:[email protected]>> wrote: > > > And Question 3, finally: Does it make sense to you what I am trying to > do, actually? > > > It feels significantly simpler for you to use hiera to pick out values > that you then pass to instances of defines, rather than baking hiera > into the definition of the define itself? > > Might be easier to give advice if you post what the defined types that > you're planning to do this with actually do though?
I want puppet managed phpmyadmin. phpmyadmin config has a global part
and one part of the config for every db instance. So I thought I'd try
define phpmyadmin::instance (
...
$extension = hiera('mysql')
)
{
file { "phpmyadmin instance $name":
path => "/etc/phpMyAdmin/$name.instance.inc.php",
content => template("phpmyadmin/instance.inc.php.erb"),
}
}
Defaults should be set in a data class
class phpmyadmin::instance::data
{
if $osfamily == 'RedHat' { $extension = 'mysql' }
}
Configuration values therefore could come from:
1. explicitly set in manifest
2. external set value, pulled in by hiera
3. default value set in phpmyadmin::instance::data class, pulled in by
hiera (But hiera seems not to look. For the phpmyadmin class it looks in
the phpmyadmin::data class)
I am afraid of name clashes. If it came to me mind to indroduce a
define phpmyadmin::instance::monitor (... = hiera(...)) {...}
then I could have
phpmyadmin::instance {'x': ...}
phpmyadmin::instance::monitor { 'x': ...}
How can I avoid that the phpmyadmin::instance::monitor is not looking in
the yaml file for phpmyadmin::instance or vice versa?
Thanks
--
Kind Regards, Markus Falb
signature.asc
Description: OpenPGP digital signature
