On 8/17/12 9:43 AM, Douglas Garstang wrote:
> On Fri, Aug 17, 2012 at 9:33 AM, Douglas Garstang
> <doug.garst...@gmail.com> wrote:
>> On Fri, Aug 17, 2012 at 12:52 AM, Denmat <tu2bg...@gmail.com> wrote:
>>>
>>>
>>> On 17/08/2012, at 17:19, Douglas Garstang <doug.garst...@gmail.com> wrote:
>>>
>>>> On Thu, Aug 16, 2012 at 11:34 PM, Garrett Honeycutt
>>>> <garr...@puppetlabs.com> wrote:
>>>>> On 8/16/12 10:44 PM, Douglas Garstang wrote:
>>>>>> So, this has always puzzled me a bit. By convention, init.pp contains
>>>>>> one class, named the same as the module. However, what is the
>>>>>> convention when the module may have multiple external access points?
>>>>>> Say you have a module called 'syslog' which provides both a client and
>>>>>> a server class. I typically have used syslog::server and
>>>>>> syslog::client. I've ended up using this convention more than init.pp
>>>>>> because I don't know when I first put the class together exactly what
>>>>>> it's going to do. In module mymodule, rather than create init.pp with
>>>>>> class mymodule, I'll call it mymodule::base or something and stick it
>>>>>> in base.pp. Confused...
>>>>>>
>>>>>> Doug
>>>>>>
>>>>>
>>>>> Not all classes are meant to be directly included by nodes. A common
>>>>> practice would be having a module where you might have a base class,
>>>>> such as syslog and other sub classes, such as syslog::client and
>>>>> syslog::server. Class syslog would contain resources that were common to
>>>>> both syslog::client and syslog::server (ie: they both have a package and
>>>>> a config file). Both syslog::client and syslog::server might include (or
>>>>> possibly inherit) the syslog class. In this setup, a node might include
>>>>> syslog::server or syslog::client, but not syslog directly. When using
>>>>> this pattern, be sure to comment in your base class that it is not meant
>>>>> to be included directly.
>>>>
>>>> Garrett, thanks. Aware of all that, but I'm not sure you really answer
>>>> my question. :)
>>>>
>>>> Doug.
>>>>
>>> Well you can leave init.pp blank, ie,
>>> class name {
>>> }
>>>
>>> Then you can put whatever you like in the module's manifest dir.
>>>
>>> I tend to write 90% of modules with the following:
>>> name::config
>>> name::install
>>> name::service
>>> name::client
>>> name::server
>>>
>>> All of those refer to individual .pp files of course.
>>>
>>> Then something like:
>>> include name::server
>>
>> I guess you would normally include ::client or ::server, and it would
>> in turn, include (inherit?) ::config, ::install and ::service?
>>
>> Ie:
>>
>> class foo::client {
>> include foo::config
>> include foo::install
>> include foo::service
>> }
>>
>> If variables are defined in ::config, does that cause any issues with scope?
>
> So... I just gave this a try, and variables I defined in ::config have
> gone out of scope in ::install. *sigh*
>
> Doug.
>
I would be careful of using imperative terms such as install, configure,
build..
Puppet ensures state, so these words can be misleading.
-g
--
Garrett Honeycutt
206.414.8658
http://puppetlabs.com
--
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.
