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.
--
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.
