Vladimir Rutsky
2013-Jan-10 18:38 UTC
[Puppet Users] Access variables defined in defined type
Hello!
How can I access variable defined inside defined type?
For example I have following define:
define python_virtualenv( $directory ) {
# Setup virtualenv in directory here
$easy_install = "${directory}/bin/easy_install"
}
And use it in this way:
python_virtualenv { ''env for Django'':
directory => ''/opt/django/env''
}
python_virtualenv { ''env for Worker'':
directory => ''/opt/worker/env''
}
# Now I want to use easy_install from created virtual environments:
class { ''django'':
easy_install => ???$Python_virtualenv[''env for
Django'']::binary_dir???
}
class { ''django-cache'':
easy_install => ???$Python_virtualenv[''env for
Django'']::binary_dir???
}
class { ''worker'':
easy_install => ???$Python_virtualenv[''env for
Worker'']::binary_dir???
}
How to access $easy_install from created resources?
Thanks in advance,
Vladimir Rutsky
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/Ql6_ZaIIQAcJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Vladimir Rutsky
2013-Jan-10 20:53 UTC
[Puppet Users] Re: Access variables defined in defined type
Sorry, there is a typo in example:
define python_virtualenv( $directory ) {
# Setup virtualenv in directory here
...
$easy_install = "${directory}/bin/easy_install"
}
And use it in this way:
python_virtualenv { ''env for Django'':
directory => ''/opt/django/env''
}
python_virtualenv { ''env for Worker'':
directory => ''/opt/worker/env''
}
# Now I want to use easy_install from created virtual environments:
class { ''django'':
easy_install => ???$Python_virtualenv[''env for
Django'']::easy_install???
}
class { ''django-cache'':
easy_install => ???$Python_virtualenv[''env for
Django'']::easy_install???
}
class { ''worker'':
easy_install => ???$Python_virtualenv[''env for
Worker'']::easy_install???
}
Question remains the same: how to access $easy_install variable defined
inside type define resource?
Vladimir Rutsky
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/ocFhp6JW43cJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Thursday, January 10, 2013 2:53:34 PM UTC-6, Vladimir Rutsky wrote:> > Sorry, there is a typo in example: > > define python_virtualenv( $directory ) { > # Setup virtualenv in directory here > ... > > $easy_install = "${directory}/bin/easy_install" > } > > And use it in this way: > > python_virtualenv { ''env for Django'': > directory => ''/opt/django/env'' > } > > python_virtualenv { ''env for Worker'': > directory => ''/opt/worker/env'' > } > > # Now I want to use easy_install from created virtual environments: > class { ''django'': > easy_install => ???$Python_virtualenv[''env for Django'']::easy_install??? > } > > class { ''django-cache'': > easy_install => ???$Python_virtualenv[''env for Django'']::easy_install??? > } > > class { ''worker'': > easy_install => ???$Python_virtualenv[''env for Worker'']::easy_install??? > } > > Question remains the same: how to access $easy_install variable defined > inside type define resource? > >You can''t. Defines, or as the are more formally called, defined types, act more like the built in resource types rather than classes. The variables and parameters from a define can only be accessed from the define itself, and from templates invoked within the define.> > Vladimir Rutsky > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/ZIhCgvZ_C6oJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Vladimir Rutsky
2013-Jan-11 10:45 UTC
Re: [Puppet Users] Re: Access variables defined in defined type
Thank you for your reply. On Fri, Jan 11, 2013 at 1:06 AM, llowder <llowderiv@gmail.com> wrote:> > > On Thursday, January 10, 2013 2:53:34 PM UTC-6, Vladimir Rutsky wrote: >> >> Sorry, there is a typo in example: >> >> define python_virtualenv( $directory ) { >> # Setup virtualenv in directory here >> ... >> >> $easy_install = "${directory}/bin/easy_**install" >> } >> >> And use it in this way: >> >> python_virtualenv { ''env for Django'': >> directory => ''/opt/django/env'' >> } >> >> python_virtualenv { ''env for Worker'': >> directory => ''/opt/worker/env'' >> } >> >> # Now I want to use easy_install from created virtual environments: >> class { ''django'': >> easy_install => ???$Python_virtualenv[''env for Django'']::easy_install??? >> } >> >> class { ''django-cache'': >> easy_install => ???$Python_virtualenv[''env for Django'']::easy_install??? >> } >> >> class { ''worker'': >> easy_install => ???$Python_virtualenv[''env for Worker'']::easy_install??? >> } >> >> Question remains the same: how to access $easy_install variable defined >> inside type define resource? >> >> > You can''t. Defines, or as the are more formally called, defined types, > act more like the built in resource types rather than classes. The > variables and parameters from a define can only be accessed from the define > itself, and from templates invoked within the define. > >Can you suggest solution to my problem? I want to create multiple Python virtual environments in different directories and use files from them in other resources (like Django installation and some other Python programs) in such way, that single Python virtual environment can be used in multiple other resources. I don''t want to manually specify paths relative to environment root because it differs depending on OS (e.g. easy_install in GNU/Linux will be in bin/easy_install, in Windows in Scripts/easy_install.exe)> > >> >> Vladimir Rutsky >> >> -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/ZIhCgvZ_C6oJ. > > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- Vladimir Rutsky -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
llowder
2013-Jan-11 13:54 UTC
Re: [Puppet Users] Re: Access variables defined in defined type
On Friday, January 11, 2013 4:45:49 AM UTC-6, Vladimir Rutsky wrote:> > Thank you for your reply. > > On Fri, Jan 11, 2013 at 1:06 AM, llowder <llow...@gmail.com <javascript:>>wrote: > >> >> >> On Thursday, January 10, 2013 2:53:34 PM UTC-6, Vladimir Rutsky wrote: >>> >>> Sorry, there is a typo in example: >>> >>> define python_virtualenv( $directory ) { >>> # Setup virtualenv in directory here >>> ... >>> >>> $easy_install = "${directory}/bin/easy_**install" >>> } >>> >>> And use it in this way: >>> >>> python_virtualenv { ''env for Django'': >>> directory => ''/opt/django/env'' >>> } >>> >>> python_virtualenv { ''env for Worker'': >>> directory => ''/opt/worker/env'' >>> } >>> >>> # Now I want to use easy_install from created virtual environments: >>> class { ''django'': >>> easy_install => ???$Python_virtualenv[''env for >>> Django'']::easy_install??? >>> } >>> >>> class { ''django-cache'': >>> easy_install => ???$Python_virtualenv[''env for >>> Django'']::easy_install??? >>> } >>> >>> class { ''worker'': >>> easy_install => ???$Python_virtualenv[''env for >>> Worker'']::easy_install??? >>> } >>> >>> Question remains the same: how to access $easy_install variable defined >>> inside type define resource? >>> >>> >> You can''t. Defines, or as the are more formally called, defined types, >> act more like the built in resource types rather than classes. The >> variables and parameters from a define can only be accessed from the define >> itself, and from templates invoked within the define. >> >> > Can you suggest solution to my problem? > > I want to create multiple Python virtual environments in different > directories and use files from them in other resources (like Django > installation and some other Python programs) in such way, that single > Python virtual environment can be used in multiple other resources. > > I don''t want to manually specify paths relative to environment root > because it differs depending on OS (e.g. easy_install in GNU/Linux will be > in bin/easy_install, in Windows in Scripts/easy_install.exe) > >You might be able to create a custom fact, have it look at the hostname then set the value of the fact to the proper easy_install value (bin/easy_install or Scripts_easy_install.exe) then you can reference the fact like you would any top scope variable.> > >> >> >>> >>> Vladimir Rutsky >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/puppet-users/-/ZIhCgvZ_C6oJ. >> >> To post to this group, send email to puppet...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> puppet-users...@googlegroups.com <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > -- > Vladimir Rutsky >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/4lE4BveUp_0J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
jcbollinger
2013-Jan-11 14:14 UTC
Re: [Puppet Users] Re: Access variables defined in defined type
On Friday, January 11, 2013 4:45:49 AM UTC-6, Vladimir Rutsky wrote:> > Can you suggest solution to my problem? > >Generally speaking, the Puppet way of approaching such problems is to have all the relevant resources draw on the same data, instead of some resources getting it indirectly from others. The data may reside in an external source and be accessed via a Puppet function, they may reside in one or more class variables, or they may be received in the form of definition parameters (or class parameters, though I advise against that).> I want to create multiple Python virtual environments in different > directories and use files from them in other resources (like Django > installation and some other Python programs) in such way, that single > Python virtual environment can be used in multiple other resources. >Are you suggesting that some nodes will have multiple distinct Python environments, or just that Python environments of different nodes will differ? It makes a big difference to which solution(s) I might recommend. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/LE6iFr5dq2sJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Vladimir Rutsky
2013-Jan-15 10:56 UTC
Re: [Puppet Users] Re: Access variables defined in defined type
On Fri, Jan 11, 2013 at 6:14 PM, jcbollinger <John.Bollinger@stjude.org>wrote:> > > On Friday, January 11, 2013 4:45:49 AM UTC-6, Vladimir Rutsky wrote: > >> Can you suggest solution to my problem? >> >> > > Generally speaking, the Puppet way of approaching such problems is to have > all the relevant resources draw on the same data, instead of some resources > getting it indirectly from others. The data may reside in an external > source and be accessed via a Puppet function, they may reside in one or > more class variables, or they may be received in the form of definition > parameters (or class parameters, though I advise against that). > > > >> I want to create multiple Python virtual environments in different >> directories and use files from them in other resources (like Django >> installation and some other Python programs) in such way, that single >> Python virtual environment can be used in multiple other resources. >> > > > Are you suggesting that some nodes will have multiple distinct Python > environments, or just that Python environments of different nodes will > differ? It makes a big difference to which solution(s) I might recommend. >Nodes can have multiple distinct Python environments. For example I want test my python programs with multiple versions of libraries: Linux host: virtualenv1 with LibA version 1.0, LibB version 2.0 - test programC, programD virtualenv2 with LibA version 0.1, LibB version 0.2 - test programC, programD Windows host: virtualenv1 with LibA version 1.0, LibB version 2.0 - test programC, programD virtualenv2 with LibA version 0.1, LibB version 0.2 - test programC, programD So on each host I want to create two virtual environments, something like this: node ''windows-testing-host'', ''linux-testing-host'' { # Setup python with dependencies. Suppose "python" executable is added in global path on Windows and Linux, so no problems with finding it. class {''python'': } # Setup virtualenv1 python::virtualenv::env { ''virtualenv1'': } # Setup virtualenv2 python::virtualenv::env { ''virtualenv2'': } # easy_install LibA v1.0, LibB v2.0 in virtualenv1 - needs path to bin/easy_install or Scripts/easy_install.exe ... # easy_install LibA v1.0, LibB v2.0 in virtualenv2 - needs path to bin/easy_install or Scripts/easy_install.exe ... # Install and test programC, programD in virtual environments } I''m new to Puppet and as temporary solution I done something like this: node ''windows-testing-host'' { class {''python'': } $virtualenv1_dir = ''C:/virtualenv1'' python::virtualenv::env { ''virtualenv1'': directory => $virtualenv1_dir, } libA { ''virtualenv1 libA'': virtualenv_dir => $virtualenv1_dir, version => ''1.0'', } libB { ''virtualenv1 libB'': virtualenv_dir => $virtualenv1_dir, version => ''0.1'', } programC { ''virtualenv1 programC'': virtualenv_dir => $virtualenv1_dir, } programD { ''virtualenv1 programD'': virtualenv_dir => $virtualenv1_dir, } $virtualenv2_dir = ''C:/virtualenv2'' python::virtualenv::env { ''virtualenv1'': directory => $virtualenv2_dir, } libA { ''virtualenv2 libA'': virtualenv_dir => $virtualenv2_dir, version => ''2.0'', } libB { ''virtualenv2 libB'': virtualenv_dir => $virtualenv2_dir, version => ''0.2'', } programC { ''virtualenv2 programC'': virtualenv_dir => $virtualenv2_dir, } programD { ''virtualenv2 programD'': virtualenv_dir => $virtualenv2_dir, } } node ''linux-testing-host'' { class {''python'': } $virtualenv1_dir = ''/opt/virtualenv1'' python::virtualenv::env { ''virtualenv1'': directory => $virtualenv1_dir, } libA { ''virtualenv1 libA'': virtualenv_dir => $virtualenv1_dir, version => ''1.0'', } libB { ''virtualenv1 libB'': virtualenv_dir => $virtualenv1_dir, version => ''0.1'', } programC { ''virtualenv1 programC'': virtualenv_dir => $virtualenv1_dir, } programD { ''virtualenv1 programD'': virtualenv_dir => $virtualenv1_dir, } $virtualenv2_dir = ''/opt/virtualenv2'' python::virtualenv::env { ''virtualenv2'': directory => $virtualenv2_dir, } libA { ''virtualenv2 libA'': virtualenv_dir => $virtualenv2_dir, version => ''2.0'', } libB { ''virtualenv2 libB'': virtualenv_dir => $virtualenv2_dir, version => ''0.2'', } programC { ''virtualenv2 programC'': virtualenv_dir => $virtualenv2_dir, } programD { ''virtualenv2 programD'': virtualenv_dir => $virtualenv2_dir, } } And in libA, libB, programC, programC I check OS fact and select correct easy_install binary.> > > John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/LE6iFr5dq2sJ. > > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- Vladimir Rutsky -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
jcbollinger
2013-Jan-15 17:43 UTC
Re: [Puppet Users] Re: Access variables defined in defined type
On Tuesday, January 15, 2013 4:56:13 AM UTC-6, Vladimir Rutsky wrote:> > > On Fri, Jan 11, 2013 at 6:14 PM, jcbollinger <John.Bo...@stjude.org<javascript:> > > wrote: > >> >> >> On Friday, January 11, 2013 4:45:49 AM UTC-6, Vladimir Rutsky wrote: >> >>> Can you suggest solution to my problem? >>> >>> >> >> Generally speaking, the Puppet way of approaching such problems is to >> have all the relevant resources draw on the same data, instead of some >> resources getting it indirectly from others. The data may reside in an >> external source and be accessed via a Puppet function, they may reside in >> one or more class variables, or they may be received in the form of >> definition parameters (or class parameters, though I advise against that). >> >> >> >>> I want to create multiple Python virtual environments in different >>> directories and use files from them in other resources (like Django >>> installation and some other Python programs) in such way, that single >>> Python virtual environment can be used in multiple other resources. >>> >> >> >> Are you suggesting that some nodes will have multiple distinct Python >> environments, or just that Python environments of different nodes will >> differ? It makes a big difference to which solution(s) I might recommend. >> > > Nodes can have multiple distinct Python environments. For example I want > test my python programs with multiple versions of libraries: > > Linux host: > virtualenv1 with LibA version 1.0, LibB version 2.0 - test programC, > programD > virtualenv2 with LibA version 0.1, LibB version 0.2 - test programC, > programD > > Windows host: > virtualenv1 with LibA version 1.0, LibB version 2.0 - test programC, > programD > virtualenv2 with LibA version 0.1, LibB version 0.2 - test programC, > programD > > So on each host I want to create two virtual environments, something like > this: > > node ''windows-testing-host'', ''linux-testing-host'' { > # Setup python with dependencies. Suppose "python" executable is added > in global path on Windows and Linux, so no problems with finding it. > class {''python'': } > > # Setup virtualenv1 > python::virtualenv::env { ''virtualenv1'': } > > # Setup virtualenv2 > python::virtualenv::env { ''virtualenv2'': } > > # easy_install LibA v1.0, LibB v2.0 in virtualenv1 - needs path to > bin/easy_install or Scripts/easy_install.exe > ... > # easy_install LibA v1.0, LibB v2.0 in virtualenv2 - needs path to > bin/easy_install or Scripts/easy_install.exe > ... > > # Install and test programC, programD in virtual environments > } > > > I''m new to Puppet and as temporary solution I done something like this: > [...] >Someone with more Puppet experience would probably wrap that up a little more neatly, possibly by using hashes and defined types. An experienced Puppeteer would certainly put all the logic in a class instead of in a node block, and would consider loading the data from an external source via hiera instead of encoding it directly into the manifest. For example (leaving hiera out of it): manifests/init.pp: node default { include ''test::environments'' } modules/test/manifests/environments.pp: class test::environments { include ''test::params'' # the ''keys'' function comes from Puppetlabs ''stdlib'' # add-in module $environments = keys($test::params::environment_config) # When a resource title is given as an array, it means one # resource instance for each element of the array test::environment { $environments: } } modules/test/manifests/params.pp: class test::params { $env_root = $osfamily ? { ''Windows'' => ''C:/'', default => ''/'' } # the parameters for each environment, and, via its keys, # a master list of the environments needed. It would be # better to load this via hiera, though. $environment_config = { ''env1'' => { directory => "${env_root}env1", libA_version => ''1.0'', libB_version => ''2.0'' }, ''env2'' => { directory => "${env_root}env2", libA_version => ''0.1'', libB_version => ''0.2'' } } } modules/test/manifests/environment.pp: # One virtual environment define test::environment() { include ''python'' $config = $test::params::environment_config[$name] python::virtualenv::env { $name: directory => $config[''directory''] } libA { "$name_libA": virtualenv_dir => $config[''directory''] version => $config[''libA_version''] } libB { "$name_libB": virtualenv_dir => $config[''directory''] version => $config[''libB_version''] } programC { "$name_programC": virtualenv_dir => $config[''directory''] } programD { "$name_programC": virtualenv_dir => $config[''directory''] } } That''s a bit shorter than your version, I think, but the most important distinction is that it is much less repetitive. If the per-environment details were more complex, or there were more distinct virtual environments needed, then you would start seeing a lot of space savings, too. Also, much greater maintainability. Please do understand, though, that I don''t put that forward as the One True Way. I don''t even suggest that it is necessarily the best way, but I hope it will serve as an adequate introduction to some of the techniques of data-driven configuration. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/9waDqbSwq4AJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Vladimir Rutsky
2013-Jan-21 12:41 UTC
Re: [Puppet Users] Re: Access variables defined in defined type
John, thank you for providing such complete example! I definitely will use ideas from it in my scripts. -- Vladimir Rutsky On Tue, Jan 15, 2013 at 9:43 PM, jcbollinger <John.Bollinger@stjude.org>wrote:> > > On Tuesday, January 15, 2013 4:56:13 AM UTC-6, Vladimir Rutsky wrote: >> >> >> On Fri, Jan 11, 2013 at 6:14 PM, jcbollinger <John.Bo...@stjude.org>wrote: >> >>> >>> >>> On Friday, January 11, 2013 4:45:49 AM UTC-6, Vladimir Rutsky wrote: >>> >>>> Can you suggest solution to my problem? >>>> >>>> >>> >>> Generally speaking, the Puppet way of approaching such problems is to >>> have all the relevant resources draw on the same data, instead of some >>> resources getting it indirectly from others. The data may reside in an >>> external source and be accessed via a Puppet function, they may reside in >>> one or more class variables, or they may be received in the form of >>> definition parameters (or class parameters, though I advise against that). >>> >>> >>> >>>> I want to create multiple Python virtual environments in different >>>> directories and use files from them in other resources (like Django >>>> installation and some other Python programs) in such way, that single >>>> Python virtual environment can be used in multiple other resources. >>>> >>> >>> >>> Are you suggesting that some nodes will have multiple distinct Python >>> environments, or just that Python environments of different nodes will >>> differ? It makes a big difference to which solution(s) I might recommend. >>> >> >> Nodes can have multiple distinct Python environments. For example I want >> test my python programs with multiple versions of libraries: >> >> Linux host: >> virtualenv1 with LibA version 1.0, LibB version 2.0 - test programC, >> programD >> virtualenv2 with LibA version 0.1, LibB version 0.2 - test programC, >> programD >> >> Windows host: >> virtualenv1 with LibA version 1.0, LibB version 2.0 - test programC, >> programD >> virtualenv2 with LibA version 0.1, LibB version 0.2 - test programC, >> programD >> >> So on each host I want to create two virtual environments, something like >> this: >> >> node ''windows-testing-host'', ''linux-testing-host'' { >> # Setup python with dependencies. Suppose "python" executable is added >> in global path on Windows and Linux, so no problems with finding it. >> class {''python'': } >> >> # Setup virtualenv1 >> python::virtualenv::env { ''virtualenv1'': } >> >> # Setup virtualenv2 >> python::virtualenv::env { ''virtualenv2'': } >> >> # easy_install LibA v1.0, LibB v2.0 in virtualenv1 - needs path to >> bin/easy_install or Scripts/easy_install.exe >> ... >> # easy_install LibA v1.0, LibB v2.0 in virtualenv2 - needs path to >> bin/easy_install or Scripts/easy_install.exe >> ... >> >> # Install and test programC, programD in virtual environments >> } >> >> >> I''m new to Puppet and as temporary solution I done something like this: >> [...] >> > > > Someone with more Puppet experience would probably wrap that up a little > more neatly, possibly by using hashes and defined types. An experienced > Puppeteer would certainly put all the logic in a class instead of in a node > block, and would consider loading the data from an external source via > hiera instead of encoding it directly into the manifest. For example > (leaving hiera out of it): > > > manifests/init.pp: > node default { > include ''test::environments'' > } > > > modules/test/manifests/environments.pp: > class test::environments { > include ''test::params'' > > # the ''keys'' function comes from Puppetlabs ''stdlib'' > # add-in module > $environments = keys($test::params::environment_config) > > # When a resource title is given as an array, it means one > # resource instance for each element of the array > test::environment { $environments: } > } > > > modules/test/manifests/params.pp: > class test::params { > $env_root = $osfamily ? { ''Windows'' => ''C:/'', default => ''/'' } > > # the parameters for each environment, and, via its keys, > # a master list of the environments needed. It would be > # better to load this via hiera, though. > $environment_config = { > ''env1'' => { > directory => "${env_root}env1", > libA_version => ''1.0'', > libB_version => ''2.0'' > }, > ''env2'' => { > directory => "${env_root}env2", > libA_version => ''0.1'', > libB_version => ''0.2'' > } > } > } > > > modules/test/manifests/environment.pp: > # One virtual environment > define test::environment() { > include ''python'' > > $config = $test::params::environment_config[$name] > > python::virtualenv::env { $name: > directory => $config[''directory''] > } > > libA { "$name_libA": > virtualenv_dir => $config[''directory''] > version => $config[''libA_version''] > } > > libB { "$name_libB": > virtualenv_dir => $config[''directory''] > version => $config[''libB_version''] > } > > programC { "$name_programC": > virtualenv_dir => $config[''directory''] > } > > programD { "$name_programC": > virtualenv_dir => $config[''directory''] > } > } > > > That''s a bit shorter than your version, I think, but the most important > distinction is that it is much less repetitive. If the per-environment > details were more complex, or there were more distinct virtual environments > needed, then you would start seeing a lot of space savings, too. Also, > much greater maintainability. > > Please do understand, though, that I don''t put that forward as the One > True Way. I don''t even suggest that it is necessarily the best way, but I > hope it will serve as an adequate introduction to some of the techniques of > data-driven configuration. > > > John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/9waDqbSwq4AJ. > > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.