Multiple nodes.pp files

[Hugo Deprez]

Dear community,

I would like to know if it is possible to use different files for the nodes.pp

Can we use in nodes.pp the following syntax :

include nodes2.pp

nodes2.pp could contain host definition eactly as nodes.pp but for a
particular platform.

This would allow more readable configuration file.

I didn't find anything on the internet.

Thank you.

hugo

[Arnau Bria]

On Wed, 16 Nov 2011 15:32:41 +0100
Hugo Deprez wrote:

> Dear community,
Hi Hugo,

> I would like to know if it is possible to use different files for the
> nodes.pp
>
> Can we use in nodes.pp the following syntax :
>
> include nodes2.pp

we have several node files but use import.

[...]
> Thank you.
>
> hugo
HTH,
Arnau

[Dan White]

----- Arnau Bria <arna...@pic.es> wrote:
> On Wed, 16 Nov 2011 15:32:41 +0100
> Hugo Deprez wrote:
>
> > Dear community,
> Hi Hugo,
>
> > I would like to know if it is possible to use different files for the
> > nodes.pp
> >
> > Can we use in nodes.pp the following syntax :
> >
> > include nodes2.pp
>
> we have several node files but use import.

So, to be certain I understand properly, you have :

manifests/node.pp
manifests/node1.pp
manifests/node2.pp
...

and manifests/node.pp contains:

import "node1"
import "node2"
...

Is that it ?

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

[Ramin K]

I think it's fairly common to put something like this in your site.pp
if you like separate node files which I prefer.

import "nodes/*.pp"

You can also use regex in your node files to further simplify though
if you're doing a lot of logic here you should probably start thinking
about an ENC.

fe.pp
node /^fe\d+(.*)/ inherits basenode {

case $::fqdn {
/(.*)stage|demo(.*)/: {
include hostgroup::frontend::stage
}
default: {
include hostgroup::frontend::prod
}
}
}

Ramin

[Jo Rhett]

On Nov 16, 2011, at 11:08 AM, Ramin K wrote:

You can also use regex in your node files to further simplify though
if you're doing a lot of logic here you should probably start thinking
about an ENC.

fe.pp
node /^fe\d+(.*)/ inherits basenode {

 case $::fqdn {
   /(.*)stage|demo(.*)/: {
     include hostgroup::frontend::stage
   }
   default: {
     include hostgroup::frontend::prod
   }
 }
}

Ramin, curious as to how this differs from the shorter …?

node /^fe\d+(.*)(stage|demo)(.*)/ inherits basenode {

     include hostgroup::frontend::stage

}
node /^fe\d+(.*)/ inherits basenode {

     include hostgroup::frontend::prod
}

I love regexs too, but that seems to be excessive syntax.

(and FYI, you forgot parens around the | …)

-- 

Jo Rhett

Net Consonance : consonant endings by net philanthropy, open source and other randomness

[Ramin K]

Tech documentation is littered with examples that illustrate exactly
one thing and call it day. 99% of the power of any system comes from
learning to combine multiple functions. I chose that example because
it illustrates regex, using regex in a node as well as case
statements, adding classes based on case statements, setting a default
in a case statement, and should have the OP considering that Puppet
can do more then 1:1 mapping. Getting past the 1:1 mapping idea seems
to take most traditional sysadmins or non CS types longer. Simply,
demonstrating possibilities was more important than least keystrokes.
Also my example avoids first match problems. Yours does as well
assuming it was clear that the first statement *had* to be first. That
is probably the number #2 mistake of documentation, illustrating a
concept without exploring the assumptions of the example.

Ramin

[Hugo Deprez]

Thank you Ramin, I used
import "nodes/*.pp" this is exactly what I wanted.

I am quite confuse about the difference between "import" and
"include" (used for a module).

is there a real difference ?

Regards,

Hugo

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>
>

[Luke Bigum]

Yes, big difference.

The 'import' function will literally add the contents of a manifest file
into where your import statement is, it's like a 'include "woof.h"' in
C/C++ or "source /etc/sysconfig/woof" in Bash. It should really never be
used anywhere outside of site.pp to add classes and functions but rather
with Puppet's class autoloading functionality.

When you "import" something Puppet will search your modules for a class
of the given name, see here for examples of how the class name or custom
define (they autoload the same way):
http://docs.puppetlabs.com/guides/modules.html#module-autoloading

Some more differences: if you were to be silly and import a manifest
file with a class definition in it, say "import
modules/woof/manifests/init.pp", that doesn't declare the class on a
node (it doesn't "turn it on"). You can "include" a class multiple
times, this is nice for handling loose overlapping dependencies between
modules. If you "import" a file multiple times it will be added to the
catalog compilation multiple times and most likely give you a lot of
errors about things having multiple declarations.

So:

import "path/to/a/file.pp"
include some_class::that_i_defined::correctly

HTH,

-Luke

>>> Ramin, curious as to how this differs from the shorter �?

>>>
>>> node /^fe\d+(.*)(stage|demo)(.*)/ inherits basenode {
>>> include hostgroup::frontend::stage}
>>>
>>> node /^fe\d+(.*)/ inherits basenode {
>>> include hostgroup::frontend::prod
>>>
>>> }
>>>
>>> I love regexs too, but that seems to be excessive syntax.

>>> (and FYI, you forgot parens around the | �)

>>>
>>> --
>>> Jo Rhett
>>> Net Consonance : consonant endings by net philanthropy, open source and other randomness
>> --
>> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
>> To post to this group, send email to puppet...@googlegroups.com.
>> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>>
>>

--
Luke Bigum
Information Systems
+44 (0) 20 3192 2520
Luke....@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN

The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company.

[Alexander Fortin]

On 11/21/11 11:13 AM, Luke Bigum wrote:
> Yes, big difference.
>
> The 'import' function will literally add the contents of a manifest file
> into where your import statement is, it's like a 'include "woof.h"' in
> C/C++ or "source /etc/sysconfig/woof" in Bash. It should really never be
> used anywhere outside of site.pp to add classes and functions but rather
> with Puppet's class autoloading functionality.

[CUT]

I think it's related. I'm using 2.7.3 with "puppet apply" only and I've
noticed that if you declare a variable in the importing manifest (say,
init.pp), it will not be callable from the imported manifest. So:

init.pp:
$myvariable = "blabla"
myresource { $myvariable : ensure => present }

import "secondmanifest.pp"

#########################

secondmanifest.pp:
mysersource { "/etc/$myvariable": ensure => present }

doesn't work.

--
Alexander Fortin
http://about.me/alexanderfortin/

[Evan Hisey]

On Thu, Nov 17, 2011 at 2:04 PM, Ramin K <ramin....@gmail.com> wrote:
> Tech documentation is littered with examples that illustrate exactly
> one thing and call it day. 99% of the power of any system comes from
> learning to combine multiple functions. I chose that example because
> it illustrates regex, using regex in a node as well as case
> statements, adding classes based on case statements, setting a default
> in a case statement, and should have the OP considering that Puppet
> can do more then 1:1 mapping. Getting past the 1:1 mapping idea seems
> to take most traditional sysadmins or non CS types longer. Simply,
> demonstrating possibilities was more important than least keystrokes.
> Also my example avoids first match problems. Yours does as well
> assuming it was clear that the first statement *had* to be first. That
> is probably the number #2 mistake of documentation, illustrating a
> concept without exploring the assumptions of the example.
>
> Ramin
>

Don't know about the OP, but it made me feel like an idiot. Been using
Puppet for years and never even considered using regex in my node
files. It would make life so much simpler for some things.

Evan

[jcbollinger]

On Nov 21, 8:05 am, Alexander Fortin <alexander.for...@gmail.com>
wrote:

What if you spell it like so:

mysersource { "/etc/$::myvariable": ensure => present }

?

I would expect either way to work in Puppet 2.6, but 2.7 is more
strict about name scoping.

And that does highlight an important point about the 'import'
function: it is *not* thoroughly analogous to the C preprocessor's
"#include" directive. It's a better analog than the 'include'
function is, but it doesn't operate at the source code level. I
better analog is Python's 'import' statement (and Puppet's module
structure is also reminiscent of Python's -- hmm).

John

[Alexander Fortin]

On 11/21/11 9:28 PM, jcbollinger wrote:
> What if you spell it like so:
>
> mysersource { "/etc/$::myvariable": ensure => present }
>
> ?

This is the actual code now:

file { "/etc/samba/smb.conf":
ensure => "present",
content => file("/home/$::realuser/puppet/files/smb.conf"),
require => Package["samba"],
notify => Service[$sambaservices],
}

but I get the same output from apply:

Could not find any files from /home//puppet/files/smb.conf at
/home/alex/puppet/manifests/samba.pp:7 on node blah

[Aaron Grewell]

Curly braces perhaps?
content => file("/home/${realuser}/puppet/files/smb.conf"),

[Alexander Fortin]

On 11/22/11 7:37 PM, Aaron Grewell wrote:
> Curly braces perhaps?
> content => file("/home/${realuser}/puppet/files/smb.conf"),

Tried both with ${realuser} and with ${::realuser}, no luck.

[Iain Sutton]

Aside: do you perhaps mean

source => file("/home/$::realuser/puppet/files/smb.conf"),

instead of

content => file("/home/$::realuser/puppet/files/smb.conf"),

?

Do you have any lines like:
notice("the value of realuser is ${realuser}  and ::realuser is ${::realuser} ")

in your manifest to confirm what the variables might actually contain?

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.

To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.

[Alexander Fortin]

On 11/24/11 5:58 AM, Iain Sutton wrote:
> Aside: do you perhaps mean
>
> source => file("/home/$::realuser/puppet/files/smb.conf"),
>
> instead of
>
> content => file("/home/$::realuser/puppet/files/smb.conf"),
>
> ?

No, I'm using content =>, and it works if I use actual strings instead
of variables.

> Do you have any lines like:
> notice("the value of realuser is ${realuser} and ::realuser is
> ${::realuser} ")
>
> in your manifest to confirm what the variables might actually contain?

I've added your line as suggested but as soon as I import the manifest
file that uses those variables, it doesn't compile:

Could not find any files from /home//puppet/files/smb.conf at
/home/alex/puppet/manifests/samba.pp:7 on node blah

--
Alexander Fortin
http://about.me/alexanderfortin/