On Wednesday, May 21, 2014 1:59:09 PM UTC-3, Doug_F wrote:
>
> I organize my setup so that hiera looks for my nodes under
> hieradata/nodes/certname.yaml I see no reason not to allow further nesting
> if needed.
>
It may be the only solution for me, but I'd rather not use YAML files as
the ris
On Wednesday, May 21, 2014 1:14:31 PM UTC-3, Garrett Honeycutt wrote:
>
> I believe you mean the deprecation of 'import'.
Woops, indeed.
> The easiest way to fix
> this is to cat all of your files together into one site.pp file.
>
Now that's even worse than having all node files in a single
Hello
I have a fairly large repository (~100 modules, ~50 classes, ~200 nodes).
It is currently organized like this:
modules/
apache2/
manifests/
files/
templates/
iptables/
manifests/
files/
templates/
postfix/
manifests/
files/
On Friday, February 21, 2014 10:15:01 AM UTC-3, Andre Nathan wrote:
>
> On Thursday, February 20, 2014 12:06:15 PM UTC-3, jcbollinger wrote:
>>
>> File a ticket if you wish, but personally, I'm inclined to say that
>> *any*reliance on iteration order of a hash
On Thursday, February 20, 2014 12:06:15 PM UTC-3, jcbollinger wrote:
>
> File a ticket if you wish, but personally, I'm inclined to say that
> *any*reliance on iteration order of a hash is dodgy. If iteration order
> matters
> then you need to take proactive measures to ensure that you reliably
Hello
Sorry to ressurect this old thread, but I've just found this issue
upgrading from Puppet 2.7.x to Puppet 3. It's true that ruby 1.8 hash order
cannot be relied on, but it should always be the same, right? I mean, one
doesn't know which order the hash contents will be iterated on, but
wha
Hello John
On Friday, April 27, 2012 9:58:09 AM UTC-3, jcbollinger wrote:
>
> I know it's not what you want to hear, but Hiera is your best bet. I
> don't think the code base size is relevant, because I don't think the
> time and effort to implement an Hiera-based class data source is
> likely
Hello
I have some code that works like the simplified clase shown below. The idea
is to have a define "foo" that includes a class "foo::pre" which contains
resources that need to be executed before the define is called. The define
can be called multiple times but the initialization has to be do
Hello
I have some puppet code that does the equivalent of the following. The
idea is to have a define "foo" with some actions that must be executed
before it runs ("foo::pre"). Since the resources in "foo::pre" can
only be defined once, it's implemented as a class, and included from
the define:
c
Hello
I'm experimenting with the new resource chaining syntax. Here's the
code:
class first { notice("first") }
class second { notice("second") }
class third { notice("third") }
include third
include second
include first
Class["first"] -> Class["second"] -> Class["third"]
Shouldn
10 matches
Mail list logo
