[Puppet Users] Disamiguate Profiles::Logstash and Logstash
I am using the puppet logstash module from Forge installed at
/etc/puppet/modules/logstash
I am trying to setup my profile class as profiles::logstash. My manifest is
at /etc/puppet/modules/profiles/manifests/logstash.pp
In my /etc/puppet/modules/profiles/manifests/logstash directory I have:
install.pp
config.pp
service.pp
In my install.pp:
class profiles::logstash::install() {
$ensure = $profiles::logstash::enable ? {true = present, default =
absent}
class { 'logstash':
ensure = $ensure,
version = $profiles::logstash::version
}
}
Here, class refers to the /etc/puppet/modules/logstash not
/etc/puppet/modules/profiles/manifests/logstash
However, when I do a run, it tells me
Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate declaration: Class[Profiles::Logstash] is already declared;
cannot redeclare at
/etc/puppet/modules/profiles/manifests/logstash/install.pp:8
It is referring to the class {'logstash' line.
What's the proper way to disambiguate so I can still tell the puppet
logstash module to install logstash and ensure the right version?
--
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 email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/137a4a4d-46f9-4e1f-841a-cda87c7e8229%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Disamiguate Profiles::Logstash and Logstash
Here is my logstash.pp at
/etc/puppet/modules/profiles/manifests/logstash.pp:
class profiles::logstash(
$version = 1.4.1-1_bd507eb,
$enable = true,
$start = true
) {
class{'profiles::logstash::install': } -
class{'profiles::logstash::config': } ~
class{'profiles::logstash::service': } -
Class[profiles::logstash]
}
On Saturday, May 31, 2014 8:17:34 AM UTC-4, Brian Wilkins wrote:
I am using the puppet logstash module from Forge installed at
/etc/puppet/modules/logstash
I am trying to setup my profile class as profiles::logstash. My manifest
is at /etc/puppet/modules/profiles/manifests/logstash.pp
In my /etc/puppet/modules/profiles/manifests/logstash directory I have:
install.pp
config.pp
service.pp
In my install.pp:
class profiles::logstash::install() {
$ensure = $profiles::logstash::enable ? {true = present, default =
absent}
class { 'logstash':
ensure = $ensure,
version = $profiles::logstash::version
}
}
Here, class refers to the /etc/puppet/modules/logstash not
/etc/puppet/modules/profiles/manifests/logstash
However, when I do a run, it tells me
Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate declaration: Class[Profiles::Logstash] is already declared;
cannot redeclare at
/etc/puppet/modules/profiles/manifests/logstash/install.pp:8
It is referring to the class {'logstash' line.
What's the proper way to disambiguate so I can still tell the puppet
logstash module to install logstash and ensure the right version?
--
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 email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/b28a3239-f0eb-4ca8-aa35-cb12e2e0ee44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Disamiguate Profiles::Logstash and Logstash
Fully-qualify the class name, ie. use '::logstash'.
R.
On 31 May 2014 13:17, Brian Wilkins bwilk...@gmail.com wrote:
I am using the puppet logstash module from Forge installed at
/etc/puppet/modules/logstash
I am trying to setup my profile class as profiles::logstash. My manifest
is at /etc/puppet/modules/profiles/manifests/logstash.pp
In my /etc/puppet/modules/profiles/manifests/logstash directory I have:
install.pp
config.pp
service.pp
In my install.pp:
class profiles::logstash::install() {
$ensure = $profiles::logstash::enable ? {true = present, default =
absent}
class { 'logstash':
ensure = $ensure,
version = $profiles::logstash::version
}
}
Here, class refers to the /etc/puppet/modules/logstash not
/etc/puppet/modules/profiles/manifests/logstash
However, when I do a run, it tells me
Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate declaration: Class[Profiles::Logstash] is already declared;
cannot redeclare at
/etc/puppet/modules/profiles/manifests/logstash/install.pp:8
It is referring to the class {'logstash' line.
What's the proper way to disambiguate so I can still tell the puppet
logstash module to install logstash and ensure the right version?
--
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
email to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/137a4a4d-46f9-4e1f-841a-cda87c7e8229%40googlegroups.com
https://groups.google.com/d/msgid/puppet-users/137a4a4d-46f9-4e1f-841a-cda87c7e8229%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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 email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAJGKfwCpivu4LiQCQedm6oRENBEz8as3rzHdSNEdERsNOcvKPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Disamiguate Profiles::Logstash and Logstash
Thanks! That worked. I am still learning. I have an additional error. Is
there a way around this or just combine my service.pp and install.pp
together?
Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate declaration: Class[Logstash] is already declared in file
/etc/puppet/modules/profiles/manifests/logstash/install.pp:8; cannot
redeclare at /etc/puppet/modules/profiles/manifests/logstash/service.pp:7
This is my service.pp:
class profiles::logstash::service() {
$status = $profiles::logstash::start ? {true = enabled, default =
disabled}
class { '::logstash':
status = $status,
}
}
On Saturday, May 31, 2014 8:26:54 AM UTC-4, Robin Bowes wrote:
Fully-qualify the class name, ie. use '::logstash'.
R.
On 31 May 2014 13:17, Brian Wilkins bwil...@gmail.com javascript:
wrote:
I am using the puppet logstash module from Forge installed at
/etc/puppet/modules/logstash
I am trying to setup my profile class as profiles::logstash. My manifest
is at /etc/puppet/modules/profiles/manifests/logstash.pp
In my /etc/puppet/modules/profiles/manifests/logstash directory I have:
install.pp
config.pp
service.pp
In my install.pp:
class profiles::logstash::install() {
$ensure = $profiles::logstash::enable ? {true = present, default =
absent}
class { 'logstash':
ensure = $ensure,
version = $profiles::logstash::version
}
}
Here, class refers to the /etc/puppet/modules/logstash not
/etc/puppet/modules/profiles/manifests/logstash
However, when I do a run, it tells me
Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate declaration: Class[Profiles::Logstash] is already declared;
cannot redeclare at
/etc/puppet/modules/profiles/manifests/logstash/install.pp:8
It is referring to the class {'logstash' line.
What's the proper way to disambiguate so I can still tell the puppet
logstash module to install logstash and ensure the right version?
--
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
email to puppet-users...@googlegroups.com javascript:.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/137a4a4d-46f9-4e1f-841a-cda87c7e8229%40googlegroups.com
https://groups.google.com/d/msgid/puppet-users/137a4a4d-46f9-4e1f-841a-cda87c7e8229%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
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 email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/e8af8d24-21ca-4415-8d30-9a5f8e435477%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] params.pp/inheritance/defaults/hiera/hiera functions?
- Don't use automatic hiera lookups. This removes the magic and makes it more clear to everyone that the data is coming from hiera. Hold on a sec; if you mean data bindings with 'automatic hiera lookups', most certainly use them. Do not ever hardcode hiera() functions in parameter lookups in your module as you module can now _only_ work with Hiera and not everyone uses or wants to use hiera. Instead let data bindings take care of it so that everyone can benefit from your code, Hiera, ENC or by explicitly passing data in. -- 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 email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0b5a1a39-ebe1-44dd-a10c-4fc44d340d7d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Puppet 3.6.0... and scaling?
A followup for closure; I've now turned environment_timeout to 'unlimited' and am doing a graceful restart of httpd to reset passenger. This seems to work. The resultant performance is _much_ more sane; I'm still seeing mebbe 20% increase in server CPU requirements, but that's quite manageable. Overall runtime is palpably better (about 10%); haven't identified where I'm getting my savings, though since I'm in parser=future land that may be a fair chunk of it. Upshot: Oh, god, 5s default timeout is nightmarishly bad for large systems, made it look like Puppet suddenly didn't know how to scale. The reality is that this has minimal real effect once you tune and I'm rocking 3.6 in the wild. On Sun, May 25, 2014 at 2:53 PM, Tristan Smith tr...@dreamlibrarian.com wrote: I've been using the default (which if I read correctly is 5s?); seems likely that a good answer here for me would be to push it out to $something_long and use restart.txt or somesuch to uptake changes. I may try that this week. My MaxRequests was already 10k. I'm guessing that 5 seconds of cache was approximately equivalent to jack and squat. I'm not sure if my attempt to tune by granting more workers would've done me any good. On Fri, May 23, 2014 at 5:25 PM, Chuck cssc...@gmail.com wrote: I had it set to 3 minutes for this test. I am going to work on trying some different settings. So far the best result has been with the following settings PassengerMaxRequests 5000 environment_timeout 15 minutes service httpd graceful whenever my svn update script detects a change. I will be working on getting more information. On Friday, May 23, 2014 3:24:43 PM UTC-5, Josh Partlow wrote: Hi Tristan, Chuck, What environment_timeout do you have set currently? On Friday, May 23, 2014 12:20:33 PM UTC-7, Tristan Smith wrote: Whuf. I'm already at 1, so that's not it for me. Seems like the doubled run time was just murdering me in the face. Trying to run 1000 clients in 30m was just too much. Guess I could make it an hour splay, but the overall resource requirement change is sufficiently large I'm probably just going to see about opting out of directory environments for a couple revisions, wait for them to tune up a bit. On Fri, May 23, 2014 at 10:23 AM, Chuck css...@gmail.com wrote: I am noticing increase CPU and Memory requirements from Puppet 3.4.3 I had to set the following passenger config so that my server would not run out of memory: PassengerMaxRequets 1 CPU idle 3.4.3 = 70% - 80% Memory utilization = 52% CPU idle 3.6.1 = 60% - 73% Memory utilization = 85% -- You received this message because you are subscribed to a topic in the Google Groups Puppet Users group. To unsubscribe from this topic, visit https://groups.google.com/d/ topic/puppet-users/arLckU-mPhw/unsubscribe. To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/puppet-users/2c9172e1-6129-46d1-94f1-38c078d72226% 40googlegroups.com https://groups.google.com/d/msgid/puppet-users/2c9172e1-6129-46d1-94f1-38c078d72226%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups Puppet Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/arLckU-mPhw/unsubscribe. To unsubscribe from this group and all its topics, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/490ad0ec-a35a-4ab3-a0a9-88e52e752083%40googlegroups.com https://groups.google.com/d/msgid/puppet-users/490ad0ec-a35a-4ab3-a0a9-88e52e752083%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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 email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAKdO7ceOBXU8wQ4gcY%2BLrWD_FrK4SyVTvb9K%2BU73P1MGAnKSQg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Puppet 3.6.0... and scaling?
What about staggering your runs? It seems trivial but at least it would reduce your load I think. -- 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 email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/97a9d7b0-45a0-468c-b981-34ac9221aa40%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] what is actually undefined method 'include?' for nil:NilClass on node error?
Good catch Ellison; I haven't noticed that but nope, nothing unusual from facter on the affected node. Now running puppet agent -tv with certificate cleared from both master and agent yields these: notice: Starting Puppet master version 2.7.23 info: access[/certificate_request]: allowing * access info: access[/]: adding authentication any info: Inserting default '/status' (auth true) ACL because none were found in '/etc/puppet/auth.conf' info: Could not find certificate for 'serv106.syst.local' info: Could not find certificate_request for 'serv106.syst.local' notice: serv106.syst.local has a waiting certificate request notice: Signed certificate request for serv106.syst.local notice: Removing file Puppet::SSL::CertificateRequest serv106.syst.local at '/var/lib/puppet/ssl/ca/requests/serv106.syst.local.pem' info: Expiring the node cache of /usr/lib/ruby/site_ruby/1.8/puppet/node.rb:110:in `names' /usr/lib/ruby/site_ruby/1.8/puppet/parser/compiler.rb:212:in `evaluate_ast_node' /usr/lib/ruby/site_ruby/1.8/puppet/parser/compiler.rb:101:in `compile' It does sign the certificate just right but again the same wired info: Expiring the node cache of after that. -San On Saturday, May 31, 2014 12:26:09 AM UTC+1, Ellison Marks wrote: It's weird, but it looks like the hostname isn't being defined, or isn't being sent properly. See info: Expiring the node cache of With just a blank afterwards. Does running facter on the affected node show anything unusual? -- 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 email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5d18a945-01f6-4087-b20e-b1be9cf5099b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] params.pp/inheritance/defaults/hiera/hiera functions?
On Sat, 2014-05-31 at 07:12 -0700, Daniele Sluijters wrote: - Don't use automatic hiera lookups. This removes the magic and makes it more clear to everyone that the data is coming from hiera. Hold on a sec; if you mean data bindings with 'automatic hiera lookups', most certainly use them. Do not ever hardcode hiera() functions in parameter lookups in your module as you module can now _only_ work with Hiera and not everyone uses or wants to use hiera. Instead let data bindings take care of it so that everyone can benefit from your code, Hiera, ENC or by explicitly passing data in. I think the most important thing is to not hardcode hiera() functions in modules. That gives the flexibility for the users of the modules to either rely on automatic parameter lookup (APL) or explicitly pass in the parameters. My own preference is to use explicit hiera lookups in profiles and pass in the data to modules. APL is just a bit too magic, in my experience, and avoiding it makes it easier to work out where data comes from. R. -- 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 email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1401572800.13490.5.camel%40hero.robinbowes.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Puppet 3.6.0... and scaling?
I've plenty of possible mechanisms to experiment with for lessening the load, but I honestly don't _have_ to now that I've fixed the caching problem. 20% higher load == the system peaks out at 40%idle, now. I've got some headroom. With the 5s cache, it was bringing the server to its knees. That's no longer an issue. On Sat, May 31, 2014 at 11:41 AM, Brian Wilkins bwilk...@gmail.com wrote: What about staggering your runs? It seems trivial but at least it would reduce your load I think. -- You received this message because you are subscribed to a topic in the Google Groups Puppet Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/arLckU-mPhw/unsubscribe. To unsubscribe from this group and all its topics, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/97a9d7b0-45a0-468c-b981-34ac9221aa40%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. -- 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 email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAKdO7ceQzCd0bBiG86ztT7Zspqq-GEXCv%2B_9kD9pNreYd6MoYA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
