On Mon, Nov 12, 2012 at 06:32:02AM -0800, jcbollinger wrote:
>
> On Friday, November 9, 2012 9:15:38 PM UTC-6, erkules wrote:
> >
> > Ups sorry for the confusion.
> > Right now Ive got defines like:
> >
> > lxc_builder{'starter01': ensure => 'define', ipadd=>'10.0.3.101/24' }
> > lxc_builder{'starter02': ensure => 'define', ipadd=>'10.0.3.102/24' }
> > lxc_builder{'starter03': ensure => 'define', ipadd=>'10.0.3.103/24' }
> > lxc_builder{'starter04': ensure => 'define', ipadd=>'10.0.3.104/24' }
> >
> > The build an LXC application container on the host.
> > This works sufficient. Depending of the host there can be easily 100
> > Containers on
> > every host. (It is no KVM :)
> >
> > So adding a container is writing a new line.
> >
> > My intention was to put my configuration into an ENC.
> > Thats where the trouble started, as no place for defined types in ENC.
> >
> > And now I wonder how a class would look like to transform my defined types
> > into a representation suitable for ENC
> >
> >
> Thanks, that gives me a clearer picture.
>
> I think you should consider whether en ENC is really what you want, or at
> least whether it's the way you want to approach this issue (because you
> might want an ENC for other reasons as well). What an ENC has to offer in
> this area is dynamic determination of the containers that should be managed
> on each node, and possibly of those containers' parameters. Unless that's
> a bona fide computation, however, you would be better off with a tool
> dedicated to data externalization, such as Hiera.
>
> If you insist on doing this via an ENC, then you must use global variables
> or class parameters to inform some class about which containers to manage.
> The parameter value would need to be an array (if you need only resource
> titles) or a richer data structure such as a hash of hashes (if you need to
> associate per-container parameters with some containers). The class might
> look something like this:
>
> # A class declaring one container for each
> # element of its $container_names parameter
> class lxc_containers($container_names) {
> lxc_builder{ ${container_names}:
> ensure => 'define',
> ipadd=>'10.0.3.101/24'
> }
> }
>
> If the idea behind your ENC is simply to feed canned data -- possibly from
> some configuration file -- to such a class, however, then you are
> reinventing the wheel. That is exactly the job to which Hiera is
> dedicated. If you are using Puppet 3 then you can even use the exact same
> class as above, and let Hiera look up the value for $container_names
> (instead of writing or configuring an ENC to do it). If you want
> compatibility with Puppet 2.[67], or if you want your class to be more
> explicit about what's happening then you can modify it slightly to:
>
> class lxc_containers {
> $container_names = hiera('lxc_containers::container_names')
> lxc_builder{ ${container_names}:
> ensure => 'define',
> ipadd=>'10.0.3.101/24'
> }
> }
>
> Of course, you do need to then configure Hiera and write your data files,
> but that's not so hard.
>
>
Great thx.
Even Im not allowed to use Hiera right now it is a good solution.
I will check the arrays and trying to look into puppet-virt to make my
containers a type (in the end).
Think this could make things easier even for ENC.
thx for the patience
Erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
