On Thursday, June 23, 2016 at 4:17:39 AM UTC-5, Andreas Dvorak wrote:
>
> Hi,
>
> now I have change it a little, but it still does not work.
>
> class check_mk::agent::serverlist {
> @@server_list { "$::hostname":
> filename => '/tmp/checkmkhosts',
> }
>
> define server_list ( $filename ) {
> ensure_resource ( 'file', $filename, {} )
> }
>
> }
>
>
Do not nest classes or defines inside classes. The fact that Puppet
accepts nesting at all is essentially a legacy feature. Put each class
definition and each defined type definition in its own file.
Furthermore, do not use the defined() or ensure_resource() functions, at
least not until you've a lot more experience. Approaches based on these
functions at minimum have evaluation-order dependencies, which can bite
you. They provide a means to paper over your problem instead of actually
fixing it.
> class check_mk::server::serverlist {
> Server_list <<| |>>
> }
>
> Error 400 on SERVER: Resource type server_list doesn't exist
>
>
The name of the defined type nested in your previous class is
check_mk::agent::serverlist::server_list, so a reference to it would be
spelled
Check_mk::Agent::Serverlist::Server_list. But changing that will not solve
your problem, because the file you end up managing will be empty.
The first thing you need to appreciate is that exported (and virtual)
resources have no magic. In particular, above all else they are resources,
with substantially all the characteristics and constraints of resources.
In particular, they must have unique names and titles; for exported
resources, that applies both in the context from which they are exported
and in the ones into which they are imported. It does not generally make
sense to export a resource unless that resource is uniquely characteristic
of the node whose catalog exports it.
The canonical example for exported resources is probably managing /etc/hosts
by exporting and collecting Host resources. Note in particular that
resources exchanged for that purpose represent individual entries in the
hosts file, no one of them represents the *whole* hosts file. That case
depends on the Host type knowing how to identify and manage individual host
entries.
I see at least three approaches that could work for you:
1. Write a custom type and provider, along lines parallel to the Host
type. This is far and away the cleanest to use, but it's a fair amount of
work, and probably not a good place for an inexperienced Puppeteer to start.
2. Get the Concat module from the forge, and use that. Your nodes can
export Concat::Fragment resources representing the parts (lines) of the
file, and Concat provides for assembling them into a single file on the
node that collects those fragments. This would be my recommendation.
3. Even simpler, however, would be to install the puppetlabs-stdlib
module and use its File_line resource as the one you export and collect.
Note well the common characteristic of all of those approaches: they
provide for modelling the separate parts of the target file separately, so
that each node that exports a part exports only that part for which it is
responsible.
John
--
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/adbd969d-89b0-4d14-b880-0762efdbf47a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
