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 -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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. -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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Aug 16, 2012 at 11:34 PM, Garrett Honeycutt <garrett@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. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 17/08/2012, at 17:19, Douglas Garstang <doug.garstang@gmail.com> wrote:> On Thu, Aug 16, 2012 at 11:34 PM, Garrett Honeycutt > <garrett@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 HTH Den -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Friday, August 17, 2012 2:52:42 AM UTC-5, denmat wrote:> > > > On 17/08/2012, at 17:19, Douglas Garstang <doug.g...@gmail.com<javascript:>> > wrote: > > > On Thu, Aug 16, 2012 at 11:34 PM, Garrett Honeycutt > > <gar...@puppetlabs.com <javascript:>> 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 > >In fact, init.pp can be entirely empty. If you have a class with the same name as the module then the autoloader expects to find it in init.pp, but such a class is not required as far as I know. I''m not on the most recent Puppet at the moment, but I definitely have working modules with empty init.pp. If init.pp serves any essential purpose beyond its significance to the autoloader, it seems to be simply to (redundantly) mark the directory containing it as a module''s base manifest directory. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/JyTCa7XIG94J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Fri, Aug 17, 2012 at 12:52 AM, Denmat <tu2bgone@gmail.com> wrote:> > > On 17/08/2012, at 17:19, Douglas Garstang <doug.garstang@gmail.com> wrote: > >> On Thu, Aug 16, 2012 at 11:34 PM, Garrett Honeycutt >> <garrett@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::serverI 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? 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Fri, Aug 17, 2012 at 9:33 AM, Douglas Garstang <doug.garstang@gmail.com> wrote:> On Fri, Aug 17, 2012 at 12:52 AM, Denmat <tu2bgone@gmail.com> wrote: >> >> >> On 17/08/2012, at 17:19, Douglas Garstang <doug.garstang@gmail.com> wrote: >> >>> On Thu, Aug 16, 2012 at 11:34 PM, Garrett Honeycutt >>> <garrett@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Friday, August 17, 2012 11:43:43 AM UTC-5, Douglas wrote:> > > > > 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* > >Of course they would.. you just have to fully qualify them. module::config::variable> Doug. >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/zs0cajDFH4kJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 8/17/12 9:43 AM, Douglas Garstang wrote:> On Fri, Aug 17, 2012 at 9:33 AM, Douglas Garstang > <doug.garstang@gmail.com> wrote: >> On Fri, Aug 17, 2012 at 12:52 AM, Denmat <tu2bgone@gmail.com> wrote: >>> >>> >>> On 17/08/2012, at 17:19, Douglas Garstang <doug.garstang@gmail.com> wrote: >>> >>>> On Thu, Aug 16, 2012 at 11:34 PM, Garrett Honeycutt >>>> <garrett@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.