Re: [Puppet Users] Re: Import Class vs Require vs Inherits Options
Thx you very much this helps a lot.
Just have a last point unclear from your example 4. As you said for example
1: Puppet will ensure that class_B's definition is evaluated before
anything following the include line inside class_A's definition so
what's the use of declaring: Class['class_B'] - Class['class_A'], isn't it
redundant?
On Wed, Jan 18, 2012 at 6:03 PM, jcbollinger john.bollin...@stjude.orgwrote:
On Jan 18, 4:32 am, Antidot SAS antidot...@gmail.com wrote:
Hi everyone,
I am just rediting an old post because don't see any answer regarding
this
matter:
I observe that your thread title refers to import, but there is no
importing in the examples you asked about. I point this out only to
be sure you recognize that there is a big difference between import
and include -- much bigger, in fact, than the one between include
and inherits.
As for the questions posed:
In a class, what's the diff between:
*don't take in count syntax, please.
--
class class_B {
package { fortune }
file { dummy }
}
--
example 1)
class class_A {
include class_B
package { foo }
}
In this case, any node that declares class_A, directly or indirectly,
will also declare class_B (on account of the include statement).
Furthermore, Puppet will ensure that class_B's definition is evaluated
before anything following the include line inside class_A's
definition. All of these are server-side considerations.
example 2)
class class_A {
file { bogus
before = Package [foo],
}
package { foo
require =Class[class_B],
}
}
In this case, the Puppet agent will manage all resources declared by
class_B before managing Package foo, and it will manage File bogus
before it manages Package foo *provided that* the node's manifests are
compiled successfully. There is no guarantee that the manifests will
compile, however, because class_A does not ensure that class_B has
been evaluated before refering to it (contrary to Mr. Bria's
assertion). One way to solve that problem would be to include
class_B, as in example (1).
example 3)
class class_A inherits class_B {
package { foo }
}
Functionally, this is the same as example (1), but as Felix describes,
it is an inappropriate use of class inheritance.
Just to muddy the waters, I'll add that in addition to the require
metaparameter, there is a require function related to both the
metaparameter and to the include function. To illustrate its use,
these two examples are thoroughly equivalent:
example 4)
class_A {
include class_B
package { foo: }
}
# On nodes, apply class_B before class_A
Class['class_B'] - Class['class_A']
---
example 5)
class_A {
# include class_B AND apply it to nodes
# before this class
require class_B
package { foo: }
}
HTH,
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Import Class vs Require vs Inherits Options
On Jan 19, 2:33 am, Antidot SAS antidot...@gmail.com wrote: Thx you very much this helps a lot. Just have a last point unclear from your example 4. As you said for example 1: Puppet will ensure that class_B's definition is evaluated before anything following the include line inside class_A's definition so what's the use of declaring: Class['class_B'] - Class['class_A'], isn't it redundant? Not at all. Evaluating the definition is part of parsing the manifests to compile them into a catalog for the node. This happens on the master. Resource and class relationships, such as those defined via resource chaining and the 'before' metaparameter, affect only the order in which the Puppet agent *applies* resources to the node. It is very important to understand the distinction between evaluation / parse order on one hand, and application order on the other. The former affects only the master's compilation of manifests into a catalog, and the latter affects only the agent's sequence of actions. That's what Felix was talking about when he wrote require = is largely orthogonal to the other mentioned concepts. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: How to handle multiple modules requiring the same packages
On Jan 18, 5:52 am, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: Hi, On 01/17/2012 04:11 PM, jcbollinger wrote: The first is simpler only if you get lucky, and you don't intend to modify your manifests ever again. basically correct, but you can even play it safe: You must make sure each and every invocation of the resource in question is protected by such an if defined(), ever. And in that case you must also make sure that the package is defined with the same parameters everywhere, and that it stays that way. Yes, it's terrible design. Indeed. Even for a one-off it's more complicated to use the conditional approach correctly than to just put the package definition in a class. Is there a good reason that this function is even retained in recent versions of puppet? I have yet to encounter an instance where it can be used cleanly. I assume the function remains for backwards compatibility. That's a pretty strong motivation for keeping it, but the function could at least be deprecated. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Network config module won't work. -Mac address errors
If you omit the macaddress in the ifcfg-eth0 file, it should work properly if there are no persistent network configs. On Redhat, the 70-persistent-net.rules assigns a specific ethx device to a specific nic. Your 'ignoring' messages strongly point in the direction of such a mechanism. So if you have a template with a macaddress, the 70-persistent-net.rules file always assigns eth0 to it. The nic in the cloned machine (with a new mac) will be named eth1. I do not use puppet to configure the network, but made a script that combines a few parts of PE and configures the network too. (See http://www.gerapeldoorn.nl/freelance/linux-automation for the script..) Regards, Ger. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/AQkU3kahyncJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Investigating catalog compile times and cpu utilization
So recently I deployed some new puppet code in our environment and noticed CPU utilization on our puppetmasters went up a bit. This lead me to wonder what exactly did I add to cause catalog compiling to utilize more CPU? I was wondering if there is a way to check how long different parts in a recipe take to compile for a node(s) ... I know sometimes things I want to do can maybe be done in several different ways so if I was able to find a part in my recipe that is causing compiling to take longer maybe I can change it to be handled in a different way. I'll obviously be going back to see exactly what changes I actually made, but just curious if there is some way to check into something like this. Thanks, Jake -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: How to handle multiple modules requiring the same packages
On Wed, Jan 18, 2012 at 3:52 AM, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: Is there a good reason that this function is even retained in recent versions of puppet? I have yet to encounter an instance where it can be used cleanly. I'll start another thread about this, but I'd quite like us to deprecate it for Telly. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] RFC: Deprecate defined() function for Telly.
I'm looking for strong opinions on whether we should or shouldn't deprecate the defined() function for Telly, the next major Puppet release this year. jcbollinger put it quite well in another thread: Use of the defined function introduces a parse-order dependency, and the additional work you need to do to ensure that that dependency is always fulfilled overcomes any simplicity advantage that might otherwise exist. -- Nigel Kersten Product Manager, Puppet Labs -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
- Original Message - I'm looking for strong opinions on whether we should or shouldn't deprecate the defined() function for Telly, the next major Puppet release this year. First choice would be to make it reliable, that seems unlikely though +1, I'd also make the scope.classes variable private somehow for similar reasons. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] RFC: Deprecate defined() function for Telly.
+1 to ditch it. As the other thread said well: use of defined() is only done in badly designed code. Getting rid of it will force people to use better designs. cheers, Walter Heck On Thu, Jan 19, 2012 at 19:19, R.I.Pienaar r...@devco.net wrote: - Original Message - I'm looking for strong opinions on whether we should or shouldn't deprecate the defined() function for Telly, the next major Puppet release this year. First choice would be to make it reliable, that seems unlikely though +1, I'd also make the scope.classes variable private somehow for similar reasons. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Walter Heck -- follow @walterheck on twitter to see what I'm up to! -- Check out my new startup: Server Monitoring as a Service @ http://tribily.com Follow @tribily on Twitter and/or 'Like' our Facebook page at http://www.facebook.com/tribily -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: RFC: Deprecate defined() function for Telly.
Defined() doesn't suck! It's a 100% reliable way to check what classes and defined types are available to the autoloader. I challenge anyone to find me an example of this usage that fails. But trying to use it to see whether a specific resource instance has been declared is pure madness and must be stopped. It's defined(), not declared(), and it shouldn't accept resource references as arguments at all. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: RFC: Deprecate defined() function for Telly.
- Original Message - Defined() doesn't suck! It's a 100% reliable way to check what classes and defined types are available to the autoloader. I challenge anyone to find me an example of this usage that fails. can you give an example of this use case pls? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: RFC: Deprecate defined() function for Telly.
On Jan 19, 11:01 am, R.I.Pienaar r...@devco.net wrote:
- Original Message -
Defined() doesn't suck! It's a 100% reliable way to check what
classes and defined types are available to the autoloader. I challenge
anyone
to find me an example of this usage that fails.
can you give an example of this use case pls?
Well... that's something I realized after I posted that, is I'm not
sure if anyone WANTS a reliable way to test the autoloader. (Obviously
people do want a way to check for resource instances, which is why
defined() keeps getting used for that...)
But anyway! Say you make a module for a network service and you want
it to be able to manage its own firewall rule. You know of a defined
type for firewall rules, and you're using it, but you want your module
to be portable and you know of good reasons why someone wouldn't be
using your iptables module.
So, you can conditionally declare the rule if the defined type is
available to the autoloader, and otherwise you don't attempt to manage
the firewall and expect that the user has read the documentation and
will make a hole for the service themselves.
if defined(firewall::iptables::rule) {
firewall::iptables::rule {'mysql_server':
...etc. etc.
}
}
See? It's just a way to peek around at what the user has installed.
Which... maybe implies that it should be renamed to installed().
Dunno.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: RFC: Deprecate defined() function for Telly.
- Original Message -
On Jan 19, 11:01 am, R.I.Pienaar r...@devco.net wrote:
- Original Message -
Defined() doesn't suck! It's a 100% reliable way to check what
classes and defined types are available to the autoloader. I
challenge anyone
to find me an example of this usage that fails.
can you give an example of this use case pls?
Well... that's something I realized after I posted that, is I'm not
sure if anyone WANTS a reliable way to test the autoloader.
(Obviously
people do want a way to check for resource instances, which is why
defined() keeps getting used for that...)
But anyway! Say you make a module for a network service and you want
it to be able to manage its own firewall rule. You know of a defined
type for firewall rules, and you're using it, but you want your
module
to be portable and you know of good reasons why someone wouldn't be
using your iptables module.
So, you can conditionally declare the rule if the defined type is
available to the autoloader, and otherwise you don't attempt to
manage
the firewall and expect that the user has read the documentation and
will make a hole for the service themselves.
if defined(firewall::iptables::rule) {
firewall::iptables::rule {'mysql_server':
...etc. etc.
}
}
See? It's just a way to peek around at what the user has installed.
right, I must have missed this behavior previously, yeah this has value
and should be retained, checking for declared resources should go then
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: RFC: Deprecate defined() function for Telly.
I use defined every so often so I would be sad if it was removed, it's
handy for certain things of things:
common/foreman_proxy/manifests/params.pp: if
defined(Class['puppet::server::ca']) {
common/foreman_proxy/manifests/params.pp: } elsif
defined(Class['puppet::server']) {
common/foreman_proxy/manifests/params.pp: if
defined(Class['foreman_proxy::role::build']) {
common/mysql/manifests/rights.pp:if ! defined(Mysql_user
[${user}@${host}])
{
An example:
if ! defined(Mysql_user [${user}@${host}]) {
mysql_user { ${user}@${host}:
password_hash = mysql_password($password),
require = File[/root/.my.cnf],
}
}
In my foreman_proxy stuff:
# puppetca settings
if defined(Class['puppet::server::ca']) {
$puppetca = true
$autosign_location = /etc/puppet/autosign.conf
$puppetca_cmd = /usr/sbin/puppetca
$puppet_group = puppet
# puppetrun settings
$puppetrun = true
$puppetrun_cmd = /usr/sbin/puppetrun
} elsif defined(Class['puppet::server']) {
# puppetrun settings
$puppetca = false
$puppetrun = true
$puppetrun_cmd = /usr/sbin/puppetrun
} else {
$puppetca = false
$puppetrun = false
}
I'm sure there are other ways to do it but this seems elegant and makes
sense at times. I could set variables in those other classes and then
check for them I suppose but what is the harm in doing things this way? I
don't see why defined() couldn't be implemented properly rather than being
removed.
On Thu, Jan 19, 2012 at 3:17 PM, Nick Fagerlund
nick.fagerl...@puppetlabs.com wrote:
On Jan 19, 11:01 am, R.I.Pienaar r...@devco.net wrote:
- Original Message -
Defined() doesn't suck! It's a 100% reliable way to check what
classes and defined types are available to the autoloader. I challenge
anyone
to find me an example of this usage that fails.
can you give an example of this use case pls?
Well... that's something I realized after I posted that, is I'm not
sure if anyone WANTS a reliable way to test the autoloader. (Obviously
people do want a way to check for resource instances, which is why
defined() keeps getting used for that...)
But anyway! Say you make a module for a network service and you want
it to be able to manage its own firewall rule. You know of a defined
type for firewall rules, and you're using it, but you want your module
to be portable and you know of good reasons why someone wouldn't be
using your iptables module.
So, you can conditionally declare the rule if the defined type is
available to the autoloader, and otherwise you don't attempt to manage
the firewall and expect that the user has read the documentation and
will make a hole for the service themselves.
if defined(firewall::iptables::rule) {
firewall::iptables::rule {'mysql_server':
...etc. etc.
}
}
See? It's just a way to peek around at what the user has installed.
Which... maybe implies that it should be renamed to installed().
Dunno.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: augeas error: Could not evaluate: unknown error - Failed to initialize Augeas
[ CC'ed to augeas-devel, more on-topic for ruby-augeas build errors ] On 18/01/12 04:45, LawrieC wrote: Thanks for the tip Aaron. I have stuck with the platform RPMs as indicated earlier in the thread. I could not find a ruby-augeas SLED platform RPM. I'm not familiar with the SUSE community, but I do see a number of ruby-augeas RPMs and SRPMs on the build service. Picking one at random: https://build.opensuse.org/package/show?package=ruby-augeasproject=home%3Ajustin_kinney The spec doesn't seem to have a %check section though, so you might find it just masks the problem below until later. Now it attempts to build a new RPM for the SLED11SP1 platform but fails at the rake testing phase with 13 errors, output follows + rake test (in /root/rpmbuild/BUILD/ruby- augeas-0.4.1) Loaded suite /usr/lib64/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/ rake_test_loader Started EEE.EE Finished in 0.018282 seconds. 1) Error: test_basics(TestAugeas): SystemCallError: unknown error - Failed to initialize Augeas That looks pretty bad! Does Augeas function properly on your system to begin with? I'd suggest running augtool and seeing if you get the same error. (From the quote below, you may need to install another package for the Augeas command line tool). If you get the error, try creating an empty directory and run augtool -r /path/to/dir to rule out problems with files on your system. On 11/01/12 23:28, Lawrie Care wrote: On the client I have the following augeas and ruby vendor based packages installed augeas-devel-0.8.1-7.8.2 libaugeas0-0.8.1-7.8.2 This is interesting, does the libaugeas0 package contain any lens files? I can't find a spec for it to see how the SUSE package is split up, but the EL/Fedora package would put them in the augeas-libs package: $ rpm -ql augeas-libs | grep -c \.aug\$ 219 The lenses should generally match the Augeas library version so check they're in sync if supplied by another package. -- Dominic Cleal Red Hat Consulting m: +44 (0)7817 878113 -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
