On Mon, Apr 26, 2010 at 8:51 AM, Bernd Adamowicz <
bernd.adamow...@esailors.de> wrote:
> OK. Actually it worked when I added:
>
>
> $hibernate_connection_dialect=$templates_eval::providevars::hibernate_connection_dialect
>
> This solves the base problem but at the same time creates another one: I do
> not have to include variables from only one class but depending one some
> environment settings from different classes. Maybe I've just picked a
> completely wrong approach, so I'd just like to show what I mean with some
> (none-Puppet) pseudo code:
>
> If (environment == "envX")
> Then
> $hibernate_connection_dialect=$envX::hibernate_connection_dialect
> Else if (environment == "envY")
> Then
> $hibernate_connection_dialect=$envY::hibernate_connection_dialect
> End
>
>
this type of conditional logic looks like its better suited to be set in an
external node classifier. This allows you to specify an external script that
classfies nodes (sets top scope params and classes) based on external
information about that node. This is best implemented using some kind of
inheritance structure that supports overriding of parameters. Variables set
at top scope will be available by their non fully qualified names in all
scopes (unless they are overridden by a local scope). The puppet dashboard
is an implementation of the inheritence driven parameterization of nodes
(called groups).
I actually like the approach of having a MODULE::params class for
parmeterizations that can be handled internally. But for things that need to
be specified by some external categorization of machines, its best to use an
external node classifier to support a more data driven parameterization of
classes.
> But actually I don't want is to have code like this - the redefinition of
> every variable depending on the environment. I was thinking about some kind
> of associative array which would allow to iterate over values 'envX',
> 'envY', etc. But again this would lead to a redefinition and I think Puppet
> does not have the feature of assoc. array. (Right?)
>
not yet, this will be supported in Rwolf, but I dont think that would be the
best way to solve you problem.
>
> Inheritance, as mentioned by Mike, is also not possible since I would then
> need some kind of 'dynamic' inheritance like this (pseudo code again):
>
> If (environment == "envX")
> Then
> class env inhertit $envX::class {
>
> }
> End
>
> Seems this is not possible in Puppet, too. So maybe there's a completely
> different approach in Puppet for accomplishing this problem (?)
>
> Thanks Bernd
>
>
> >> It should work if you just explicitly assign the variable in the scope
> where you execute the template function.
> >
> > 58 class templates_eval::testvars {
> > 59
> > 60 include templates_eval::providevars
> > 61
> >
> >> 61.5
> hibernate_connection_dialect=templates_eval::providevars::hibernate_connection_dialect
> >
> > 62 file {
> > 63 "/tmp/tmplteval.properties":
> > 64 ensure => "present",
> > 65 mode => 644,
> > 66 content =>
> template("templates_eval/global.properties.erb"),
> > 67 }
> > 68 }
>
>
> --
> 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<puppet-users%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
--
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.
