Re: [Puppet Users] stdlib module causes puppet failure

Thanks. Unfortunately that doesn't seem to be the issue. There is no file named .resource_types within the puppet configuration dir. > > You may be running into > https://tickets.puppetlabs.com/browse/PUP-9602. Try deleting > /mnt/live/puppeteer/conf.d/puppet/.resource_types > > Josh > >

Re: [Puppet Users] stdlib module causes puppet failure

On Thu, Jun 20, 2019 at 10:45 AM Michael Watters wrote: > > I'm having an issue with the puppetlabs-stdlib module causing compilation > failures using the puppet apply command. > > > Error: Class 'stdlib' is already defined (file: > >

[Puppet Users] stdlib module causes puppet failure

I'm having an issue with the puppetlabs-stdlib module causing compilation failures using the puppet apply command. > Error: Class 'stdlib' is already defined (file: /mnt/live/puppeteer/conf.d/puppet/modules/stdlib/manifests/init.pp, line: 16); cannot redefine (file:

[Puppet Users] stdlib keys() and values()

Hello List, I can't think of a more basic question, but... $hash = {'a'=>1, 'b'=>2, 'c'=>3} notify { "sdf": message => values($hash), } -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving

Re: [Puppet Users] stdlib module invalid

Definitely... Right on: https://github.com/zend-patterns/ZendServerPuppet/blob/master/metadata.json#L6 Thanks a lot, I submitted a PR. Sorry for the noise, but now I understand the role of metadata.json better. On Friday, July 21, 2017 at 12:11:30 AM UTC-4, Rob Nelson wrote: > > It is

Re: [Puppet Users] stdlib module invalid

It is possible that zendserver may specifically request 4.3.2, rather then >=4.3.2, which means 4.17.1 is an invalid version for dependencies. You can check metadata.json in zendserver to see what specifically it says. On Thu, Jul 20, 2017 at 9:11 PM Ugo Bellavance wrote: > Hi, >

[Puppet Users] stdlib module invalid

Hi, I wonder why, on all my puppet servers, I always get an "invalid" message besides stdlib. # puppet module list Warning: Module 'puppetlabs-stdlib' (v4.17.1) fails to meet some dependencies: 'zend-zendserver' (v0.2.0) requires 'puppetlabs-stdlib' (v4.3.2)

Re: [Puppet Users] stdlib

My bad, I had deleted the files in /etc/puppet/modules/stdlib/ on the server. The agent deleted files in /var/lib/puppet/lib/puppet/parser/functions/. I restored the files from svn and the problem doesn't occur. Thanks, -- You received this message because you are subscribed to the Google

Re: [Puppet Users] stdlib

Possibly. If an agent has stdlib 1.0.0 already synced and the master has 1.0.2, there may be files added, removed, or changed. It does seem unlikely that the node would have synced files on a first run, but it is possible depending on who the agent was packaged and installed. Can you provide a

Re: [Puppet Users] stdlib

Hi, So it is normal to see files that are removed on the client the first time it connects to the master with a config that uses stdlib? On Thursday, April 14, 2016 at 5:23:39 PM UTC-4, Rob Nelson wrote: > > Yes, all modules in an environment would be pluginsynced. > > > Rob Nelson >

Re: [Puppet Users] stdlib

Yes, all modules in an environment would be pluginsynced. Rob Nelson rnels...@gmail.com On Thu, Apr 14, 2016 at 3:48 PM, Ugo Bellavance wrote: > Hi, > > Is it normal that when a new client connects to a master, stdlib is > sync'd? Is that part of pluginsync? > > Thanks, > > --

[Puppet Users] stdlib

Hi, Is it normal that when a new client connects to a master, stdlib is sync'd? Is that part of pluginsync? Thanks, -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an

[Puppet Users] stdlib keys()

Hello guys, I have the next problem to get value of keys from hieradata(common.yaml) 1- I have common.yaml : host_key: - server1: alias: webserver ipadress: 192.168.0.4 port : 80 - server2: alias: dbserver ipadress: 192.168.0.5 port : 80 2) init.pp

Re: [Puppet Users] stdlib keys()

On 10/06/2014 08:29 PM, Juan Andres Ramirez wrote: host_key: - server1: alias: webserver ipadress: 192.168.0.4 port : 80 - server2: alias: dbserver ipadress: 192.168.0.5 port : 80 The keys function works on hashes only. Rather than [ { server1 = undef, alias

[Puppet Users] stdlib: result from join_keys_to_values() is unstable

Hi there, Say I have a hash like {a='1',b='2'} and I'd like to get a string that looks like a=1,b=2. I tried using a combination of join_keys_to_values() and join() and the result looked correct, but was unstable. That unstability is because hashes are not always sorted the same way. An unstable

Re: [Puppet Users] stdlib: result from join_keys_to_values() is unstable

Gabriel, I don't know about the specific implementation of join_keys_to_values, but ruby's hash behavior changed between the 1.8 series and 1.9 and later[1]. In ruby 1.8 hashes are enumerated in a seemingly unsorted manner, while in ruby 1.9 and later hashes are enumerated in insertion order. If

Re: [Puppet Users] stdlib: result from join_keys_to_values() is unstable

On 11/03/14 12:58 PM, Matthaus Owens wrote: I don't know about the specific implementation of join_keys_to_values, but ruby's hash behavior changed between the 1.8 series and 1.9 and later[1]. In ruby 1.8 hashes are enumerated in a seemingly unsorted manner, while in ruby 1.9 and later hashes

[Puppet Users] Stdlib and Defined Types

All, Does anyone know of a way to add a file-centric backtrace to the validate functions in the Stdlib? If you use a validator in a defined type, you end up not having any idea what actually threw the error. Though much has moved to parameterized classes, there are still times when defines are

[Puppet Users] stdlib file_line type

Hi I am just testing file_line type in puppetlabs stdlib library. It is a very simple line file_line { 'testing file_line' : ensure = present, line = 'This is a test' path = '/etc/puppet/puppet-test' } It works but when I look at client log

[Puppet Users] stdlib parseyaml

https://forge.puppetlabs.com/puppetlabs/stdlib Has anyone worked with parseyaml? could you provide an example of how this works? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it,

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

Hi Kirk, Sorry, I've only just noticed this thread. I've also experienced the same problem. I've commented on this issue (although it might not be the correct bug after all, since it's not quite the same problem): https://projects.puppetlabs.com/issues/18812#note-1 It would be great to

[Puppet Users] stdlib::member support for strings and hashes todo

I am curious as to how support for strings would work. To me, it seems there are two possibile use-cases for support for strings. Take the following example: Assume: - extdata exists, identified by 'array' - extlookup('array') may return an array or a single string (in the case that the

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

Josh, thanks for the info. Based on your description, I think I was seeing a bug. Because the agents were all definitely getting certificates. When I did the tcpdump, I could see them being used in the exchange. So, it sounds like the puppetmaster running in webrick was still performing a

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

SOLVED: I didn't have the VMs in the host's /etc/hosts. Once I put all of them into the host (i.e, the Puppet Master), then everything sped up to full speed on the clients. (I had been thinking it was a problem on the client side, so all of my troubleshooting had been isolated to the clients.

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

Huh, good find. I'm guessing you're still running webrick? Based on a quick google it looks like it by does reverse DNS by default. Most web servers have this disabled by default but I think webrick does not (Apache at least disabled dns lookups I'm sure by default). I think if Puppet passes

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

Hi Kirk On Thu, Jan 10, 2013 at 7:58 AM, Kirk Steffensen k...@steffensenfamily.com wrote: SOLVED: I didn't have the VMs in the host's /etc/hosts. Once I put all of them into the host (i.e, the Puppet Master), then everything sped up to full speed on the clients. (I had been thinking it was a

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

John, I don't believe there is any name resolution issue. Both the CentOS and Ubuntu base boxes have 192.168.33.1 puppet in their /etc/hosts. From inside the Vagrant VM, a ping to puppet responds immediately, and a tracepath to puppet returns as quickly as I can hit enter, showing

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

Damn, I thought John had it :-(. Here's a question I hadn't asked - whats your plugin sync performance like on the puppetmaster node itself? ie. clear all synced files and run it locally and time it, comparing to the other nodes. On Wed, Jan 9, 2013 at 4:02 PM, Kirk Steffensen

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

Ken, thanks. Unfortunately, (from a troubleshooting standpoint), it only took one or two seconds to sync stdlib on the local box. rm -rf /var/lib/puppet/lib/* puppet agent --test I saw the same stream of File notices, but they streamed by in real time, instead of taking 10 seconds per notice.

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

Ken, thanks. Unfortunately, (from a troubleshooting standpoint), it only took one or two seconds to sync stdlib on the local box. rm -rf /var/lib/puppet/lib/* puppet agent --test I saw the same stream of File notices, but they streamed by in real time, instead of taking 10 seconds per

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

Here is the strace output from one of the 10-second periods while waiting for the File notice to appear. https://gist.github.com/4497263 The strace output came in two bursts during this 10-seconds. The thing that leaps out at me is that of the 4061 lines of output, 3754 of them are

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

Hi Kirk, Do you happen to have SRV lookups enabled via the `use_srv_records` setting? You may want to run tcpdump and look for extraneous DNS lookups. Josh On Wed, Jan 9, 2013 at 2:00 PM, Kirk Steffensen k...@steffensenfamily.com wrote: Here is the strace output from one of the 10-second

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

Josh, use_srv_records is not set in puppet.conf. 'puppet config print use_srv_records shows it set to the default of false. I ran tcpdump from inside the Vagrant VM during pluginsync. On eth1, where the VM is connecting to the puppet master running on the host, the only calls are puppet

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

On Monday, January 7, 2013 3:03:06 PM UTC-6, Kirk Steffensen wrote: The second time it runs (with pluginsync enabled), it only pauses at the Info: Retrieving plugin notice for a few seconds. So, it sounds like the md5sum is not the bottleneck. Is it possible that you have a name

[Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

Hi, I have a fresh CentOS 5.8 Vagrant VM that I'm using to emulate a customer's server. During the first Puppet run, it takes 13 minutes and 48 seconds to sync the Puppet Labs stdlib module. On a similar Ubuntu 12.04.1 Vagrant VM, Puppet starts up, and almost instantly goes from plugin sync

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

My immediate gut feeling on this would be network not Puppet being the issue actually, especially if another client is having success at doing the sync. Its a virt so it could be hypervisor drivers or some other issue, its an old version of the kernel as well - its more likely to happen -

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

Ken, Thanks. I agree with your gut feeling, but after running the first round of tests you suggested, I don't think that's it. Bandwidth is good and there are no netstat errors. (Test results at the end of this email.) Actually, I just realized that the Puppet client on the Ubuntu box is

Re: [Puppet Users] stdlib take almost 14 minutes to sync on CentOS Vagrant VM

The second time it runs (with pluginsync enabled), it only pauses at the Info: Retrieving plugin notice for a few seconds. So, it sounds like the md5sum is not the bottleneck. The specific setup that I'm using is a pretty beefy Xeon workstation with 24 GB of RAM acting as the puppetmaster for

Re: [Puppet Users] stdlib empty() function not working?

Success! I've figured out what happened! It looks like not just custom functions disappeared, but also functions that are part of puppet disappeared (like split()). In fact, it looks like anything that was loaded into puppet via Puppet::Parser::Functions had disappeared (not knowing much about

Re: [Puppet Users] stdlib empty() function not working?

Nan: Since my test module worked and copying and pasting would be at best cumbersome, I've just created a github project with my module: https://github.com/ibikestl/puppet-netif Examples should be in the tests. Thanks again for your help on this, --dlloyd -- You received this message because

Re: [Puppet Users] stdlib empty() function not working?

Nan: I also coded up a test module using empty() and it works just fine, so it seems that the issue is in how my module uses the empty() function. It almost seems as though the empty() function is getting redefined somewhere else, yet I don't find any other definitions anywhere in /etc/puppet/* .

[Puppet Users] stdlib empty() function not working?

Running 2.7.14 both on the client and server. I've created a defined type for managing network interface IPs and static routes. The routes are passed in as an array of hashes. I used the empty() function to see if the array is empty before attempting to call another defined type to write out the

Re: [Puppet Users] stdlib empty() function not working?

On Mon, Jul 16, 2012 at 7:46 AM, Dave Lloyd d...@davelloyd.com wrote: Running 2.7.14 both on the client and server. I've created a defined type for managing network interface IPs and static routes. The routes are passed in as an array of hashes. I used the empty() function to see if the array

Re: [Puppet Users] stdlib empty() function not working?

On Mon, Jul 16, 2012 at 10:56 AM, Nan Liu n...@puppetlabs.com wrote: empty() should be an rvalue function. In this case posting the empty() function would be more helpful than the puppet manifests. Nan It's the standard one shipped with stdlib:

Re: [Puppet Users] stdlib empty() function not working?

On Mon, Jul 16, 2012 at 9:48 AM, Dave Lloyd d...@davelloyd.com wrote: On Mon, Jul 16, 2012 at 10:56 AM, Nan Liu n...@puppetlabs.com wrote: empty() should be an rvalue function. In this case posting the empty() function would be more helpful than the puppet manifests. Nan It's the

Re: [Puppet Users] stdlib/range issue

I think you are wrong, check the source code: # Check whether we have integer value if so then make it so ... if start.match(/^\d+$/) start = start.to_i stop = stop.to_i else start = start.to_s stop = stop.to_s end Besides, the change made by

Re: [Puppet Users] stdlib/range issue

Hi, [...] I changed how the range works (also making it resists Ruby's string permutation bomb). Ideas implemented so far: https://gist.github.com/2277148 https://gist.github.com/2277144 https://gist.github.com/2270106 Also, the a..b and a...b notation should also be supported. I will push

Re: [Puppet Users] stdlib module not working

On 30 March 2012 20:18, Stefan Wiederoder stefanwiedero...@googlemail.comwrote: thanks Eric, ensure did the trick, now I´m stuck while trying to use a facter variable within the line statement: file_line { tmpfs entry: line = tmpfs /dev/shmtmpfs size=${kis_tmpfs_size} 0

Re: [Puppet Users] stdlib/range issue

Hi, It looks like range(host01, host99) works fine, returning [ host01, host02, ..., host98, host99 ] Is this what you're looking for, or is it an issue only if the leading portion of the string is zero padded? This is exactly what I was looking for, which indeed is much nicer than doing

Re: [Puppet Users] stdlib module not working

thanks Eric, ensure did the trick, now I´m stuck while trying to use a facter variable within the line statement: file_line { tmpfs entry: line = tmpfs /dev/shmtmpfs size=${kis_tmpfs_size} 0 0, path = /etc/fstab.d/system.fstab, ensure = present } maybe

Re: [Puppet Users] stdlib/range issue

On Thu, Mar 29, 2012 at 11:50 PM, Pablo Fernandez pablo.fernan...@cscs.chwrote: Hi, It looks like range(host01, host99) works fine, returning [ host01, host02, ..., host98, host99 ] Is this what you're looking for, or is it an issue only if the leading portion of the string is zero

[Puppet Users] stdlib module not working

I´m trying to utilize the new stdlib module, but got stuck after installation on my puppet server. I´ve tried to use the included test file file_line.pp on the server, but it´s only creating the file - but not managing the content. the same problem on my clients (the new provider file_line has

[Puppet Users] stdlib/range issue

Dear stdlib'ers... I have just discovered the wonders of the parser functions, and got impressed with the tens of functions that come with stdlib. First things first... good work!!! Thanks!! And now the issue. It seems like the writer of the range() function did not think about ranges with

Re: [Puppet Users] stdlib/range issue

I needed this just yesterday, actually, for NFS mounts. $PO_0_9 = prefix(range(0,9),'/PO_0') $PO_10_31 = prefix(range(10,31),'/PO_') $PO_32_76 = prefix(range(32,76),'/PO_') nfs::po_mounts_50{ $PO_0_9: options = 'soft,bg,tcp', } nfs::po_mounts_50{ $PO_10_31: options =

Re: [Puppet Users] stdlib/range issue

Hi, irb(main):008:0 (08..12).to_a = [08, 09, 10, 11, 12] irb(main):010:0 (8..12).to_a = [8, 9, 10, 11, 12] But then, the range() function in stdlib, makes a type conversion, that breaks this possibility. I don't understand why do you do that conversion... the function is just an

Re: [Puppet Users] stdlib/range issue

On Thu, Mar 29, 2012 at 8:48 AM, Pablo Fernandez pablo.fernan...@cscs.chwrote: Dear stdlib'ers... I have just discovered the wonders of the parser functions, and got impressed with the tens of functions that come with stdlib. First things first... good work!!! Thanks!! And now the issue.

Re: [Puppet Users] stdlib module not working

Why not use host instead of file_line ? http://docs.puppetlabs.com/references/latest/type.html#host host { 'puppet master host entry': ip = '172.16.240.200', name = 'master.dev.puppetlabs.com', host_aliases = ['master'], } On Mar 29, 2012, at 11:08 AM, Stefan Wiederoder wrote: I´m

Re: [Puppet Users] stdlib module not working

Stefan, Looks related to https://projects.puppetlabs.com/issues/13530, which I just opened. Make sure you ensure = present in the file_line resource. -Eric -- Eric Shamow Professional Services http://puppetlabs.com/ (c)631.871.6441 On Thursday, March 29, 2012 at 6:17 PM, Dan White