[Puppet Users] On code organization and the deprecation of include
Hello I have a fairly large repository (~100 modules, ~50 classes, ~200 nodes). It is currently organized like this: modules/ apache2/ manifests/ files/ templates/ iptables/ manifests/ files/ templates/ postfix/ manifests/ files/ templates/ ... manifests/ classes/ webserver.pp webserver/ apache2.pp iptables.pp mta/ postfix.pp iptables.pp ... nodes/ webserver.pp webserver/ web1.pp web2.pp ... mta.pp mta/ mta1.pp mta2.pp ... Subclasses in the modules directory are found via the autoloader, and as long as I follow the file naming conventions, that works fine. For classes and nodes, I have to use import. For example, in classes/webserver.pp I have import webserver/*.pp so that I can access classes webserver::apache2, webserver::iptables and so on. The same is done for nodes. I usually have a generic node where I set variables that are common for that class of nodes, and then the nodes themselves which inherit the generic node and set their own variables. To make that work, I use import in the same way as described above. I understand that with the deprecation of include, this will not work anymore. I can work around this for my classes by adding a new directory to the modulepath and then converting the directory structure to the manifests/files/templates structure with an init.pp file. However, what can I do about the nodes? The new feature of setting the manifest to a directory does not support subdirectories. Will I be forced to have all my nodes in the same directory and then rely on file names for organization? This is far from optimal in my opinion. What other alternatives do I have? If at all possible, I'd like to avoid using ENCs and keep using puppet files for node definitions. Thanks in advance, Andre -- 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/7eabce0e-edf6-488a-8182-41ba41e09f0e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] On code organization and the deprecation of include
On Wednesday, May 21, 2014 1:14:31 PM UTC-3, Garrett Honeycutt wrote: I believe you mean the deprecation of 'import'. Woops, indeed. The easiest way to fix this is to cat all of your files together into one site.pp file. Now that's even worse than having all node files in a single directory. Your usage of a base node that other nodes inherit is an anti-pattern though and will cause you grief as you grow. Why is it an anti-pattern? Isn't variable inheritance supported? Why can't I organize my nodes in sub-directories? It's something simple that greatly enhances code organization. Best, Andre -- 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/3be8fcd1-0626-4947-bf2b-d9d63475f470%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] On code organization and the deprecation of include
On Wednesday, May 21, 2014 1:59:09 PM UTC-3, Doug_F wrote: I organize my setup so that hiera looks for my nodes under hieradata/nodes/certname.yaml I see no reason not to allow further nesting if needed. It may be the only solution for me, but I'd rather not use YAML files as the risk of someone doing an edit and messing up with the indentation is high. That being said it may be a good time to look into an ENC (External Node Classifier) like Foreman. I haven't done this yet as I work on a team and have to take baby steps so everyone keeps up. This would remove the nodes from version control, which I'd rather not do either... Thanks, Andre -- 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/a0e9c129-5867-4931-95e1-653a5d8c8835%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Hash iteration order in a template not consistent
On Friday, February 21, 2014 10:15:01 AM UTC-3, Andre Nathan wrote: On Thursday, February 20, 2014 12:06:15 PM UTC-3, jcbollinger wrote: File a ticket if you wish, but personally, I'm inclined to say that *any*reliance on iteration order of a hash is dodgy. If iteration order matters then you need to take proactive measures to ensure that you reliably get the (an) order that works for you. Well, it's not a case of order being important. I don't care about the order, but it should always be the same. Otherwise, when you build a configuration file from a template, that file gets changed every time Puppet runs, because the directives are reordered. I createt ticket PUP-1755 on the tracker. Cheers, Andre -- 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/21e0759a-811f-411b-91f5-aa5766bec9a2%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Hash iteration order in a template not consistent
On Thursday, February 20, 2014 12:06:15 PM UTC-3, jcbollinger wrote: File a ticket if you wish, but personally, I'm inclined to say that *any*reliance on iteration order of a hash is dodgy. If iteration order matters then you need to take proactive measures to ensure that you reliably get the (an) order that works for you. Well, it's not a case of order being important. I don't care about the order, but it should always be the same. Otherwise, when you build a configuration file from a template, that file gets changed every time Puppet runs, because the directives are reordered. Thanks, Andre -- 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/11e3d5d2-9e98-472a-9ae5-cfb8b7d7a9d7%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Hash iteration order in a template not consistent
Hello
Sorry to ressurect this old thread, but I've just found this issue
upgrading from Puppet 2.7.x to Puppet 3. It's true that ruby 1.8 hash order
cannot be relied on, but it should always be the same, right? I mean, one
doesn't know which order the hash contents will be iterated on, but
whatever order ruby chooses should never change.
We had this working with no issues in 2.7.x and ruby 1.8, but now on Puppet
3 we're getting random reorderings. I suspect there's a problem in Puppet
in this case.
Best,
Andre
On Wednesday, March 28, 2012 9:39:45 AM UTC-3, R.I. Pienaar wrote:
- Original Message -
From: Martijn Grendelman mar...@iphion.nl javascript:
snip
http://serverfault.com/questions/368784/puppet-and-templates-how-to-loop-sequently-and-not-randomly
which suggests to do something like
% aliases.sort_by {|key, value| key}.each_pair do |key, val| -%
% end -%
Will it work? Is that a proper solution?
ruby hashes are not stored in predictable order so this will happen, the
proposed
solution should work.
But as always the best is just to test it and see how it goes, it wont
bite :)
--
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/068cf600-4f30-41d9-8249-30e6cec096fd%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Includes and parametrized class redefinition
Hello
I have some code that works like the simplified clase shown below. The idea
is to have a define foo that includes a class foo::pre which contains
resources that need to be executed before the define is called. The define
can be called multiple times but the initialization has to be done only
once, which is why it's implemented as a class:
class foo::pre {
notice(foo::pre)
}
define foo() {
include 'foo::pre'
notice(foo)
}
class x {
notice(x)
foo { 'x foo':
}
}
class y {
notice(y)
foo { 'y foo':
}
}
include x
include y
The issue is that now I need to parametrize foo::pre so that its behavior
depends on a variable that exists in foo:
class foo::pre($blah) {
notice(foo::pre)
}
define foo() {
class { 'foo::pre':
blah = 1,
}
notice(foo)
}
class x {
notice(x)
foo { 'x foo':
}
}
class y {
notice(y)
foo { 'y foo':
}
}
include x
include y
With this code I get Duplicate definition: Class[Foo::Pre] is already
defined. This seems weird to me because I thought the class { 'myclass':
} syntax was semantically equivalent to include myclass. Puppet,
however, complains that it's being defined twice, even though there's no
definition happening there, just inclusion.
So, is there a way to redesign this to match the original behavior? I know
the current trend is to keep this kind of thing in hiera but this is
already a fairly large code base that can't be changed quickly...
Thanks in advance,
Andre
--
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/-/dll5ilVD_60J.
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: Includes and parametrized class redefinition
Hello John On Friday, April 27, 2012 9:58:09 AM UTC-3, jcbollinger wrote: I know it's not what you want to hear, but Hiera is your best bet. I don't think the code base size is relevant, because I don't think the time and effort to implement an Hiera-based class data source is likely to differ much from what parameterizing all the same classes would require. Or to put it a different way, solving your problem via class parameterization would require *at least* as much shakeup of your code base as would implementing an hiera-based solution. Well, the thing is that we're in the middle of a transition process that is moving from everything is a global variable in the node to parametrized classes, and while they are not perfect, I found that our new code is much saner and easier to debug when using them. So the question is, are parametrized classes now considered deprecated? I remember reading somewhere that improvements were being made for Puppet 2.8... While I can see the advantages of Hiera, it seems to me that it's another instance of the global variable problem if it's used to load values inside some class, and I'd rather not lose the benefit of being able to check a class signature to see immediately what variables it needs, and having the code fail if any is not provided. Thanks, Andre -- 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/-/eA93Ge_3z2kJ. 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] Help with parametrized class include
Hello
I have some puppet code that does the equivalent of the following. The
idea is to have a define foo with some actions that must be executed
before it runs (foo::pre). Since the resources in foo::pre can
only be defined once, it's implemented as a class, and included from
the define:
class foo::pre {
notice(foo::pre)
}
define foo() {
include 'foo::pre'
notice(foo)
}
class x {
notice(x)
foo { 'x foo':
}
}
class y {
notice(y)
foo { 'y foo':
}
}
include x
include y
My problem starts when I need to parametrize class foo::pre:
class foo::pre($blah) {
notice(foo::pre)
}
define foo() {
class { 'foo::pre':
blah = 1,
}
notice(foo)
}
class x {
notice(x)
foo { 'x foo':
}
}
class y {
notice(y)
foo { 'y foo':
}
}
include x
include y
When I try to apply this code, I get the error Duplicate definition:
Class[Foo::Pre] is already defined.
I always thought that the class { 'someclass': } syntax was
equivalent to include someclass, but it seems that in the former,
Puppet treats it as a class definition and not just an include (even
though that's not where the class is defined).
Is there any way around this, or another way to achieve this with
parametrized classes?
Thanks in advance,
Andre
--
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] Chaining behavior
Hello
I'm experimenting with the new resource chaining syntax. Here's the
code:
class first { notice(first) }
class second { notice(second) }
class third { notice(third) }
include third
include second
include first
Class[first] - Class[second] - Class[third]
Shouldn't the last line guarantee that the classes are executed in
that specific order?
Thanks in advance,
Andre
--
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.
