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

jcbollinger
Mon, 29 Oct 2012 13:15:55 -0000

On Friday, October 26, 2012 3:53:42 PM UTC-5, erkules
wrote:
>
>
> On Fri, Oct 26, 2012 at 12:24:52PM -0700, jcbollinger wrote:
> >
> [snip]
> >
> >
> > > If not is there a trick to call a class many times for a node.
(Maybe
> by
> > > manipulating the name?)
> > >
> > >
> > You can create classes with different names but similar content, or
you
> can
> > use one class that wraps all the resources you want.  For example,
> >
> > class mymodule::lxc_application_containers {
> >   mymodule::lxc_application_container { ''container1:
> >     application => ''Awesomeness1.1''
> >     # other parameters
> >   }
> >   mymodule::lxc_application_container { ''container2:
> >     application => ''Moneymaker3.2''
> >     # other parameters
> >   }
> >   # other containers ...
> > }
>
> Ok my defined types in a class.
> How would that look like in a yaml-output?
>


It would just look like the class.  The declarations inside a class are not
represented in the ENC output that declares the class.  I presented a model
of how the class itself might look in my previous message.


>
> >
> > Supposing that the point is to select a subset of the available
> > applications for each target node, using the one-class approach, you
can
> do
> > that via global variables (yuck), class parameters (meh), or data from
> an
> > external source (best bet).
>
> Hmm, right now it is the same application running multiple times.
>
>
It makes little difference, really, whether it is multiple instances of one
application or of different ones.  That the applications are all the same
does favor modeling that application itself via a definition instead of a
class, however.


>
> >
> > On the other hand, don''t discard the idea of different
classes too
> > lightly.  In many cases it makes a lot of sense.  In particular, it
may
> > relieve pressure on your defined type to be sufficiently flexible to
do
> > everything needed for any application you might ever want to use.
>  Having a
> > separate class for each module could make it a lot easier to deal with
> the
> > special needs of each application.
> >
>
> Right, in my case it is (for now) the same application. Having for every
> application
> a different name would no be that dynamic I would suggest/hope it to be.
> As the differ in IP and some dirs only.
> So this would suggest to write a class for every application I want to run
> then?
>
>
You''ll have to judge for yourself what makes the most sense for your
site.
What I''m saying is that if you find yourself writing a lot of
conditionals
and special cases to support various different applications, then that
suggests you might be better off creating separate classes for those
applications.  Such classes might or might not leverage whatever
general-purpose application resources you create, however works best for
you.

As for being dynamic, as long as you do not rely on parametrized-style
declarations -- either because your classes are not parametrized, or
because you rely on hiera (in Puppet 3) to provide any needed parameter
customization -- you can have entirely as much dynamic behavior in your
manifests with classes as with definitions.  On the other hand, I think
that''s rather a straw man in the context of an ENC.  The whole point of
an
ENC is to provide whatever dynamic behavior you want, therefore you
don''t
need a lot of dynamism in the manifests of an ENC-driven site.


John

--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit