Thanks but it remains the same.
Even if I put an ${fqdn}.csv it will read that file but only take the
first entry in the CSV and apply that to every extlookup call in the
module.
It's a little curious. This is running on PE1.2 but I suspect this is
running the same code base as 2.6.9
--
You rec
On Oct 24, 2:25 am, "ollies...@googlemail.com"
wrote:
> On Oct 21, 12:55 pm, Andrew Thompson wrote:> On Oct
> 20, 10:18 am, "ollies...@googlemail.com" wrote:
> > > Taking a brief look at extlookup()
>
> > > We have a module to setup resolv.conf based on location so we have a %
> > > {domain}.c
looks like that's it. i'll use the workaround nigel recommended in
that issue (same as my diff above) until that issue is resolved.
thanks for the quick response, R.I.!
On Oct 24, 6:10 pm, "R.I.Pienaar" wrote:
> - Original Message -
> > I'm trying to upgrade from 2.6.7 to to 2.7.6 and I
I diff'd the extlookup.rb between 2.6.7 and 2.7.6 and noticed this was
different, so I changed it back and things are working again:
--> git diff ./lib/puppet/parser/functions/extlookup.rb
diff --git a/lib/puppet/parser/functions/extlookup.rb b/lib/puppet/
parser/functions/extlookup.rb
index 5fbf
On Oct 21, 12:55 pm, Andrew Thompson wrote:
> On Oct 20, 10:18 am, "ollies...@googlemail.com"
> wrote:
> > Taking a brief look at extlookup()
>
> > We have a module to setup resolv.conf based on location so we have a %
> > {domain}.csv file
>
> Can you post your $extlookup_datadir and $extlooku
On Oct 20, 10:18 am, "ollies...@googlemail.com"
wrote:
> Taking a brief look at extlookup()
>
> We have a module to setup resolv.conf based on location so we have a %
> {domain}.csv file
Can you post your $extlookup_datadir and $extlookup_precedence values?
>
> more /etc/puppetlabs/puppet/envs/
On Wed, Aug 3, 2011 at 3:50 PM, Douglas Garstang wrote:
> Can't get the extlookup() that supports yaml to work.
>
> I did this...
>
> On server:
> mv /usr/lib/ruby/site_ruby/1.8/puppet/parser/functions/extlookup.rb
> /usr/lib/ruby/site_ruby/1.8/puppet/parser/functions/extlookup.rb.orig
> Replaced
jcbollinger:
> 1) The "include" statement expresses a requirement that the specified
> class be included in the resulting catalog, but it says nothing about
> the class's parameters.
>
> 2) If a class is named in at least one "include" statement that is
> executed while compiling a catalog, then t
On Thu, Apr 14, 2011 at 12:24 AM, Felix Frank <
felix.fr...@alumni.tu-berlin.de> wrote:
> Hi John,
>
> On 04/13/2011 05:47 PM, jcbollinger wrote:
> > Given my position that the good use cases for parameterized classes
> > are specialized and few, I tend to agree about different uses. That
> > par
On Apr 14, 2:24 am, Felix Frank
wrote:
> Hi John,
>
> On 04/13/2011 05:47 PM, jcbollinger wrote:
[...]
> > For instance, perhaps you
> > have a user::virtual class that on some nodes declares virtual LDAP
> > users, but on other nodes delares the same virtual users as local.
> > Such a class
Hi John,
On 04/13/2011 05:47 PM, jcbollinger wrote:
> Given my position that the good use cases for parameterized classes
> are specialized and few, I tend to agree about different uses. That
> parameterized and ordinary classes are different concepts appears to
> be more a de facto result than a
On Wed, Apr 13, 2011 at 9:40 AM, R.I.Pienaar wrote:
> Soon puppet will start warning
> if you use dynamic scoping and after that dynamic scoping will stop working
> this means 'include' as we know it will stop working and might as well
> be removed from the language.
Just to address this point...
On Apr 12, 2:13 pm, Dan Bode wrote:
> I completely agree that this recommendation is a little lacking without an
> existing ENC to back it up.
It is lacking to the extent that it depends on an ENC at all, even if
PL provided an outstanding one. Allowing an ENC to specify data is
good. Requi
>
> > Background is that we are still investing a somewhat
> > disproportionate amount of time into puppet development (when using puppet
> > for
> > managing customers' systems). Nobody's going to pay us for refactoring work.
> > A style guide that recommends practices that are prone to need
> >
On Apr 13, 3:17 am, Felix Frank
wrote:
> On 04/12/2011 08:24 PM, R.I.Pienaar wrote:
>
> > This demonstrates the problem. You have had to spend time working
> > with customers to explain how to build these. It's a very complex
> > subject, something our target audience in many cases dont get.
On Apr 13, 2:42 am, Felix Frank
wrote:
> On 04/13/2011 12:34 AM, jcbollinger wrote:
>
> > You can include unparameterized classes any number of times, and it
> > means the same thing whether you include a class once or a hundred
> > times. This is one of the fundamental characteristics of Puppe
On 04/13/2011 12:34 AM, jcbollinger wrote:
> You can include unparameterized classes any number of times, and it
> means the same thing whether you include a class once or a hundred
> times. This is one of the fundamental characteristics of Puppet
> classes, and a feature that I personally put to
On Apr 12, 10:49 am, Patrick wrote:
> On Apr 12, 2011, at 8:03 AM, jcbollinger wrote:
>
> > 1) parameterized classes can be included only once, unlike
> > unparameterized ones. This tends to require modules to have an
> > hierarchical structure, which isn't very suitable in many
> > circumstanc
On Apr 12, 2011, at 8:03 AM, jcbollinger wrote:
> 1) parameterized classes can be included only once, unlike
> unparameterized ones. This tends to require modules to have an
> hierarchical structure, which isn't very suitable in many
> circumstances. (More on that below.) It does, however, sor
On Apr 12, 12:45 am, Dan Bode wrote:
> On Mon, Apr 11, 2011 at 9:25 PM, John Warburton wrote:
>
> > OK, I'll bite
>
> > In the newly published Style Guide (
> >http://docs.puppetlabs.com/guides/style_guide.html), right at the end it
> > says
>
> > Modules should avoid the use of extlookup()
20 matches
Mail list logo