On Wednesday, January 30, 2013 3:41:31 PM UTC-6, Ti Leggett wrote:
>
>
> On Jan 30, 2013, at 2:33 PM, jcbollinger wrote:
>
> > Maybe we're just having a terminology problem. Puppet has no concept of
> sub-modules, and the only construct available to hold reference-able,
> non-global variables
On Jan 31, 2013, at 4:03 AM, Luke Bigum wrote:
> For this specific example I would not model it this way. I would make the
> Apache module provide an interface to allow other modules to add to itself. I
> would make something like an 'apache::vhost' or 'apache::extra_conf_file',
> which is jus
On Wednesday, January 30, 2013 9:41:31 PM UTC, Ti Leggett wrote:
>
> On Jan 30, 2013, at 2:33 PM, jcbollinger wrote:
>
> >> not mash all the public bits in to one globally public class that has
> no nitty gritty bits to implement. In my example ::params is
> considered the header for the module
On Jan 30, 2013, at 2:33 PM, jcbollinger wrote:
>> not mash all the public bits in to one globally public class that has no
>> nitty gritty bits to implement. In my example ::params is considered
>> the header for the module (granted a header that exposes values, but that
>> can't be helped d
On Wednesday, January 30, 2013 10:21:44 AM UTC-6, Ti Leggett wrote:
>
>
> On Jan 30, 2013, at 9:31 AM, jcbollinger wrote:
> [...]
> > And now that you drop the idea of a common data module, we come back
> around to using other modules' classes' variables. Are you honestly
> arguing that it is
On Jan 30, 2013, at 9:31 AM, jcbollinger wrote:
>
>> I'm not sure I fully agree with this from a design standpoint. In
>> object-oriented programming, one of the design principles is that variables
>> relating to the object are encapsulated within the object and exposed or not
>> depending o
On Tuesday, January 29, 2013 9:07:29 AM UTC-6, Ti Leggett wrote:
>
>
> On Jan 29, 2013, at 8:51 AM, jcbollinger wrote:
>
> >> The only way to force parse-time ordering right now is to do a direct
> >> include, unfortunately.
> >>
> >
> >
> > Yes, but I'm not sure I would say "unfortunately
On Jan 29, 2013, at 4:19 PM, Matthew Pounsett wrote:
>
>
> On Tuesday, 29 January 2013 13:58:20 UTC-5, Ti Leggett wrote:
>> I include that in the module that installs the shell packages and configures
>> them, in my case, I call it base. In other words, the variables should be as
>> close to
On Tuesday, 29 January 2013 13:58:20 UTC-5, Ti Leggett wrote:
>
> I include that in the module that installs the shell packages and
> configures them, in my case, I call it base. In other words, the variables
> should be as close to the things they affect or are affected by. Just
> because eve
On Jan 29, 2013, at 12:42 PM, Matthew Pounsett wrote:
>
>
> On Tuesday, 29 January 2013 10:07:29 UTC-5, Ti Leggett wrote:
> I'm not sure I fully agree with this from a design standpoint. In
> object-oriented programming, one of the design principles is that variables
> relating to the object
On Tuesday, 29 January 2013 10:07:29 UTC-5, Ti Leggett wrote:
>
> I'm not sure I fully agree with this from a design standpoint. In
> object-oriented programming, one of the design principles is that variables
> relating to the object are encapsulated within the object and exposed or
> not dep
On Jan 29, 2013, at 8:51 AM, jcbollinger wrote:
>> The only way to force parse-time ordering right now is to do a direct
>> include, unfortunately.
>>
>
>
> Yes, but I'm not sure I would say "unfortunately" there. The problem is not
> so much with any limitation of Puppet DSL in this area
On Monday, January 28, 2013 11:17:03 AM UTC-6, Calvin Walton wrote:
>
> On Mon, 2013-01-28 at 09:12 -0800, Luke Bigum wrote:
> > On Monday, January 28, 2013 5:00:24 PM UTC, Ti Leggett wrote:
>
> > However, let me warn you against going overboard with having classes
> > include other classes fr
On Mon, 2013-01-28 at 09:12 -0800, Luke Bigum wrote:
> On Monday, January 28, 2013 5:00:24 PM UTC, Ti Leggett wrote:
> However, let me warn you against going overboard with having classes
> include other classes from other modules. It can be annoying to track down
> where resources coming from f
On Monday, January 28, 2013 5:00:24 PM UTC, Ti Leggett wrote:
>
> Thanks for the response.
>
> Can multiple classes include the same class. Let's say I instantiate the
> apache class from manifests/nodes.pp which in turns includes
> apache::params. Can kibana include apache::params then as well
On Mon, 2013-01-28 at 11:00 -0600, Ti Leggett wrote:
> On Jan 28, 2013, at 10:56 AM, Calvin Walton wrote:
>
> > The fix is trivial, just add an "include apache::params" (or even just
> > "include apache") at the top of your kibana::apache class, like so:
> >
> > # modules/kibana/manifests/apache
On Jan 28, 2013, at 10:56 AM, Calvin Walton wrote:
> The fix is trivial, just add an "include apache::params" (or even just
> "include apache") at the top of your kibana::apache class, like so:
>
> # modules/kibana/manifests/apache.pp
> class kibana::apache (
>$version = $kibana::params::pa
On Mon, 2013-01-28 at 08:24 -0800, Ti Leggett wrote:
> I have one module, kibana, that defines a file snippet for the apache
> module to fulfill (e.g., /etc/https/conf.d/kibana.conf). The apache::params
> class defines a variable of the path of where this snippet should be
> placed, $config_d. T
I have one module, kibana, that defines a file snippet for the apache
module to fulfill (e.g., /etc/https/conf.d/kibana.conf). The apache::params
class defines a variable of the path of where this snippet should be
placed, $config_d. The snippet uses this variable in its definition.
However, i
19 matches
Mail list logo
