Puppet:Could not find default node or by name with node test2
Solution 1
I'd recommend moving away from manifest node definitions to Hiera. You'll need to tweak things a bit to move away from having that defined type called directly from your node, but it looks like that isn't being used multiple times in a catalog anyway, so conversion to a class should work fine.
So with a hiera.yaml
like this..
---
:backends:
- yaml
:hierarchy:
- '%{::clientcert}'
- 'os-%{::osfamily}'
- common
:yaml:
:datadir: /etc/puppet/hieradata
And a site.pp
with just:
hiera_include(classes)
..your nodes will be read from YAML files in /etc/puppet/hieradata
. For example's sake we'll say that you want tmp::params
on every node reporting to Puppet, but maybe you want tmp::gtp
just on certain nodes. And you want to centrally define the version
parameter, but leave the other parameters to be set per-node. So we'll put tmp::params
and the version
parameter /etc/puppet/hieradata/common.yaml
:
classes:
- tmp::params
tmp::gtp::version: 6.0.0.0
Then you'll have a file for each node.
/etc/puppet/hieradata/test1.yaml
:
classes:
- tmp::gtp
tmp::gtp::name : node1
tmp::gtp::ip : 168.1.193.97
tmp::gtp::port : 1255
/etc/puppet/hieradata/test2.yaml
:
classes:
- tmp::gtp
tmp::gtp::name : node2
tmp::gtp::ip : 168.1.193.98
tmp::gtp::port : 1255
And yes, it'll pick up changes to the Hiera files without a service restart. Seem like about what you need?
Edit: to use Hiera to set up multiple instances of a defined type, you'll want to do something like this:
/etc/puppet/hieradata/test1.yaml
:
classes:
- gtpsetup
gtp_instances:
- node1_instance1
- node1_instance2
gtp_instanceconfig:
node1_instance1:
ip : 168.1.193.97
port : 1255
version : 5.3.2.1
node1_instance2:
ip : 168.1.193.97
port : 1268
version : 6.0.0.0
/etc/puppet/modules/gtpsetup/manifests/init.pp
:
class gtpsetup {
gtp_instances = hiera('gtp_instances')
gtp_instanceconfig = hiera('gtp_instanceconfig')
define gtp_instance {
# this is using your existing defined type, but you can just move the stuff it's doing to here.
tmp::gtp { $title:
name => $title,
version => gtp_instanceconfig[$title]['version'],
ip => gtp_instanceconfig[$title]['ip'],
port => gtp_instanceconfig[$title]['port'],
}
}
gtp_instance { $gtp_instances: }
}
Solution 2
Shane gave an excellent answer with a better way to approach your problem, but I want to address, "So I am thinking Puppet will not dynamically import a new pp file after the puppet master has been started."
That's kind of true. When Puppet starts, it reads through all of its configuration files and then starts watching them for changes. When the content of one of those files is updated, Puppet will reread the file. Puppet also has a set of standard locations for files that it will consult when it needs to, so if you add a new class foo::bar
to a node in a file it's monitoring, it'll look for a file named foo/manifests/bar.pp
(or foo/manifests/bar.rb
) in its $modulepath
, even if it didn't need that file when it started up.
Importantly, import
directives are only evaluated when the file they're in is parsed. When the puppet master started, it read its site.pp
file, saw the import
statement, and found only nodes/test1.pp
, so the only files it monitored for changes were site.pp
and nodes/test1.pp
. It never saw nodes/test2.pp
.
One workaround for this would be simply to touch site.pp
after adding a new file to the nodes
directory. That will cause the puppet master to reread site.pp
, which will cause it to reprocess the import
statement and it will then see the new file.
In the long run, though, you're better off following Shane's recommendations and separating out your data from your code. If you can structure your definitions to not need the import
statement, you'll be better off; it does still have its uses, but in a lot of ways import
is a relic of older Puppet practices that are no longer relevant.
Related videos on Youtube
txworking
Updated on September 18, 2022Comments
-
txworking almost 2 years
I installed Puppet 3.1.1 on an Ubuntu Server.
My manifests folder looked like this:
├── nodes │ └── test1.pp └── site.pp
The content of site.pp was:
# site.pp import "nodes/*.pp"
Node test1 worked OK.
Then I created a new file named
test2.pp
. The content was the same as test1.pp except for the node name, and I added it into the nodes folder.So the manifests folder became this:
├── nodes │ ├── test1.pp │ └── test2.pp └── site.pp
I then ran
puppet agent --test
on node test2.The agent could exchange SSL keys with the puppet master, but I got an error message:
Could not find default node or by name with test2
If I don't create a new
test2.pp
file, and just add the content into thetest1.pp
file, no error appears.So I am thinking Puppet will not dynamically import a new pp file after the puppet master has been started.
Is is possible to define nodes in individual pp files and dynamically import them?
Glad for any suggestions.
The content of the two pp files:
node 'test1' { include tmp::params tmp::gtp { 'node1': name => 'node1', version => '6.0.0.0', ip => '168.1.193.97', port => '1255', } } node 'test2' { include tmp::params tmp::gtp { 'node2': name => 'node2', version => '6.0.0.0', ip => '168.1.193.98', port => '1255', } }
-
pkhamre about 11 yearsCan you post the content of the two node files?
-
-
txworking about 11 yearsCan hiera works with defined types? I found there were no docs talking about hiera and defined types. Where can i find the detail docs? thx
-
ravi yarlagadda about 11 years@txworking It can't directly do defined types in the same way that it can do classes. Instead of directly using defined types in your nodes, use classes - and you can have those classes realize any needed defined types based on that data in hiera. For your example above, does that mean you need to have more than one
tmp::gtp
per node? -
txworking about 11 yearsYes.
tmp::gtp
is a defined type, and i need to have more than onetmp::gtp
per node. What you mean is that i should define one class which contains manytmp::gtp
? -
ravi yarlagadda about 11 years@txworking Added notes to my answer on how to do that.