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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
