Re: [Puppet Users] Re: defined types and enc

erkan yanar
Wed, 14 Nov 2012 14:23:35 -0000

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