On Feb 8, 12:43 am, jimbob palmer wrote:
> Thanks. but I meant more within the same class: before I was using
> class inheritance to ensure that I don't have to worry about ordering.
Class foo::specific 'include'ing class foo::common on the first line
of its body gives exactly the same orderin
Hi,
On 02/08/2012 02:57 PM, jimbob palmer wrote:
> So say I have a single class which in order I need to ensure a file
> doesn't exist, then after that install a package, then after that call
> a define function.
careful: define() has nothing to do with custom functions.
You create a definded *t
2012/2/8 Felix Frank :
> Hi,
>
> On 02/08/2012 07:43 AM, jimbob palmer wrote:
>> Now I will use includes as you suggest. Say I have a class that has an
>> include, is there a guarantee that the include will always be included
>> before the rest of the class is examined?
>
> Referencing variables sc
Hi,
On 02/08/2012 07:43 AM, jimbob palmer wrote:
> Now I will use includes as you suggest. Say I have a class that has an
> include, is there a guarantee that the include will always be included
> before the rest of the class is examined?
Referencing variables scoped to included classes will *alw
2012/2/7 Nan Liu :
> On Tue, Feb 7, 2012 at 1:13 PM, jimbob palmer wrote:
>> 2012/2/7 Jan Ivar Beddari :
>>> On 02/07/2012 03:54 PM, jimbob palmer wrote:
>
>
> # The right way
> class foo::specific {
> include 'foo::common'
> # specific stuff
> }
So
On Feb 7, 2012, at 2:13 PM, jimbob palmer wrote:
> 2012/2/7 Jan Ivar Beddari :
>> On 02/07/2012 03:54 PM, jimbob palmer wrote:
# The right way
class foo::specific {
include 'foo::common'
# specific stuff
}
>>>
>>>
>>> So can I be sure that the include
On Tue, Feb 7, 2012 at 1:13 PM, jimbob palmer wrote:
> 2012/2/7 Jan Ivar Beddari :
>> On 02/07/2012 03:54 PM, jimbob palmer wrote:
# The right way
class foo::specific {
include 'foo::common'
# specific stuff
}
>>>
>>>
>>> So can I be sure that the include w
2012/2/7 Jan Ivar Beddari :
> On 02/07/2012 03:54 PM, jimbob palmer wrote:
>>>
>>>
>>> # The right way
>>> class foo::specific {
>>> include 'foo::common'
>>> # specific stuff
>>> }
>>
>>
>> So can I be sure that the include will run first, before the "specific
>> stuff" here?
>
>
> Kind of,
On 02/07/2012 03:54 PM, jimbob palmer wrote:
# The right way
class foo::specific {
include 'foo::common'
# specific stuff
}
So can I be sure that the include will run first, before the "specific
stuff" here?
Kind of, but you need to change your thinking. The include does not
_run_ b
2012/2/7 jcbollinger :
>
>
> On Feb 7, 7:33 am, Felix Frank
> wrote:
>> Hi,
>>
>> On 02/07/2012 01:56 PM, jimbob palmer wrote:
>>
>> >> sorry for jumping to conclusions, but your questions suggest that you're
>> >> > committed to some rather horribly design ideas.
>> > Then please educate me! What
On Feb 7, 7:33 am, Felix Frank
wrote:
> Hi,
>
> On 02/07/2012 01:56 PM, jimbob palmer wrote:
>
> >> sorry for jumping to conclusions, but your questions suggest that you're
> >> > committed to some rather horribly design ideas.
> > Then please educate me! What's horrible about it?
>
> There are
Hi,
On 02/07/2012 01:56 PM, jimbob palmer wrote:
>> sorry for jumping to conclusions, but your questions suggest that you're
>> > committed to some rather horribly design ideas.
> Then please educate me! What's horrible about it?
There are few use cases for parameterized classes, and also few for
On Feb 7, 1:21 pm, Felix Frank
wrote:
> Hi,
>
> sorry for jumping to conclusions, but your questions suggest that you're
> committed to some rather horribly design ideas.
Then please educate me! What's horrible about it?
>
> Can you add some meat to your inquiry? What are your trying to achieve?
On Aug 2, 9:11 pm, Karen Loomans wrote:
> I believe I have a related problem. What is the correct way to extend your
> example, to handle the situation where each application class needs to set a
> different var?
In Puppet, class inheritance is appropriate ONLY where it involves
overriding re
Hi,
I believe I have a related problem. What is the correct way to extend your
example, to handle the situation where each application class needs to set a
different var? For example I'm writing a module whereby I need to include
sections of template based on what applications are installed on t
On Aug 1, 1:10 pm, hornet136 wrote:
> I want to start out with an apache class that will disable all modules
> except for a pre-defined list, thus establishing a baseline of active
> modules.
> Then as needed, other classes could enable a module that they require
> that would have been disabled
On Mon, Nov 29, 2010 at 6:46 AM, jcbollinger wrote:
>
>
> On Nov 24, 9:37 am, Chris C wrote:
>> I was able to get override to work correctly.
>
> I'm glad to hear it.
>
>> My classes are inheriting each other. prac inherits all_hosts_redhat which
>> inherits all_hosts.
>> I cleaned up some unnec
On Nov 24, 9:37 am, Chris C wrote:
> I was able to get override to work correctly.
I'm glad to hear it.
> My classes are inheriting each other. prac inherits all_hosts_redhat which
> inherits all_hosts.
> I cleaned up some unnecessary duplicate checks like chmod and own.
> I changed the defin
Thanks for the reply!
I was able to get override to work correctly.
My classes are inheriting each other. prac inherits all_hosts_redhat which
inherits all_hosts.
I cleaned up some unnecessary duplicate checks like chmod and own.
I changed the definition to the overided file to File['/etc/motd']
On Nov 23, 2:22 pm, Chris C wrote:
> I'm trying to establish a simple inheritance
Although people new to Puppet seem to like to try that, especially
when they have a programming background, it's usually not a very good
idea. For one thing, inheritance in Puppet doesn't work the way
newbies typ
20 matches
Mail list logo
