Hey John,
Thank you for the info on this one. I never even considered the sync and
your answer provides some great insight.
Thanks again,
m.
On Wednesday, October 1, 2014 11:57:04 AM UTC-7, Mike Reed wrote:
>
> Hello all,
>
> My thanks in advance to anybody with thoughts on this. I have a mo
Wil,
Thanks for the reply. I will look up the module functions you reference.
Though, part of this was writing the custom function as a learning
exercise.
So if I have a file with the following in it and run it through ruby it
works.
require 'resolv'
Resolv::DNS.open do |dns|
ress = dns
Eric Shamow writes:
> Not based on experience specifically with beaker but have you tried
> using SCLs to install ruby 1.9.3?
That was going to be my next task, if I didn't get an adequate
response here. I don't expect it to be an *easy* one, though.
Michael Stahnke writes:
>> If using the Beaker framework is going to be a core part of
>> determining that a puppet module has been "tested", I figure I'd better be
>> able to use Beaker. And so far, this seems tricky, at least on my RHEL 6
>> systems.
>> Perhaps Puppet Labs sho
All-
I'm hoping there are at least a few people on the list that are
successfully using the puppetlabs-apache module with the httpd24
packages from the Red Hat Software Collections Library, aka SCL.
If you're one of those people, can you share what parameters you've
had to override, or anything
On Thu, Oct 2, 2014 at 6:39 PM, Stephen Wallace
wrote:
> Thanks rob!
>
Ticket has been created at https://tickets.puppetlabs.com/browse/PUP-3387
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop
Tim,
Not based on experience specifically with beaker but have you tried using SCLs
to install ruby 1.9.3?
-Eric
--
Eric Shamow
Sent with Airmail
On October 3, 2014 at 7:53:09 AM, Tim Skirvin (tskir...@fnal.gov) wrote:
If using the Beaker framework is going to be a core part of
determining
On Fri, Oct 3, 2014 at 7:53 AM, Tim Skirvin wrote:
> If using the Beaker framework is going to be a core part of
> determining that a puppet module has been "tested", I figure I'd better be
> able to use Beaker. And so far, this seems tricky, at least on my RHEL 6
> systems.
>
>
Disregard...
In my app_tier::class_A file I needed to define the "class::module".
#cat class_A.pp
class app_tier::class_A {
On Fri, Oct 3, 2014 at 1:06 PM, Tom Tucker wrote:
>
> I am trying to call another class that is not located in the current
> working directory. What is the correct way
On Fri, Oct 3, 2014 at 7:23 AM, jcbollinger
wrote:
>
>
> On Thursday, October 2, 2014 12:54:06 PM UTC-5, Chris Pitman wrote:
>>
>> Hey everyone,
>>
>> I'm hoping someone can enlighten me here: Why is it so hard/complicated
>> to use third party gems when developing a custom provider? It seems to
I am trying to call another class that is not located in the current
working directory. What is the correct way of doing this?
$mypath/modules/web_app/init.pp
if $hostname =~ /^some_www_regex$/ {
include some_class_A
include some_class_B
include app_tier::class_A # Doesn't work...
If using the Beaker framework is going to be a core part of
determining that a puppet module has been "tested", I figure I'd better be
able to use Beaker. And so far, this seems tricky, at least on my RHEL 6
systems.
Perhaps Puppet Labs should provide RPMs?
Failing that,
On Thursday, October 2, 2014 9:07:42 AM UTC-5, JonY wrote:
>
> I've been having problems (documented here) with upgrading my clients from
> p-ver 3.5.1 and facter 1.7.5 to 3.7 and 2.2 respectively. (TL;DR - the
> client gives a facter error with every run and is essentially wedged).
>
> I filed
On Thursday, October 2, 2014 12:54:06 PM UTC-5, Chris Pitman wrote:
>
> Hey everyone,
>
> I'm hoping someone can enlighten me here: Why is it so hard/complicated to
> use third party gems when developing a custom provider? It seems to me that
> pulling in gems should be priority #1, since it al
I was wrong, Jonathan. That error is actually somewhere in a manifest. You can
troubleshoot it the same way, though. Just start commenting out sections of
code in the order that your manifests are invoked in, until you find the
culprit.
--
You received this message because you are subscribed t
On Thursday, September 25, 2014 3:33:00 PM UTC-5, Andy Parker wrote:
> The language will remain in ruby for a while yet (the puppet-server uses
> JRuby to run the puppet ruby code), and even after the interpreter gets
> reimplemented in a faster language, ruby will be available for extension
On 03/10/14 13:43, Brian Morris wrote:
This is bombing on your facters. I would try commenting out successively more
facters, from the bottom of each facter file, until you locate the source of
the error.
OK. How do you tell this? I couldn't really make head or tail of the
error message.
This is bombing on your facters. I would try commenting out successively more
facters, from the bottom of each facter file, until you locate the source of
the error.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this grou
I am having a tough time finding an answer to this, probably due to my lack of
Google skills.
I have been working to get hiera-eyaml plugin working.
Hiera from the command line is able to look up the values in the eyaml files.
Implying that it is loading up the correct gems etc. The puppetmaste
> Alternatively, you should be able to overcome any autorequire by declaring
> a contradictory explicit relationship. For example, you could try this:
>
> define crond::job($jobs,$comment,$mail="root") {
> include crond::cleanup
> file {
> "/etc/cron.d/${name}.puppet.cron":
>
20 matches
Mail list logo
