Correction to give possibility to export service to puppetdb

[Reamer]

Hi,

maybe I doesn't understand this module, but I was not able to export a icinga::object::service resource to my puppetdb. In icinga2 you must create a service object on agent and on master right?

I have something like this in my own puppet manifest

....
  ::icinga2::object::service { $object_servicename:
    target => "/etc/icinga2/conf.d/${object_servicename}.conf",
    import => $templates,
    display_name => $display_name,
    host_name => $host_name,
    groups => $groups,
    vars => $vars,
    enable_flapping => $enable_flapping,
    check_command => $check_command,
  }
  if $export {
    @@::icinga2::object::service { "${::fqdn}_${object_servicename}":
      service_name => $object_servicename,
      import => $templates,
      display_name => $display_name,
      host_name => $host_name,
      groups => $groups,
      vars => $vars,
      enable_flapping => $enable_flapping,
      check_command => $check_command,
 # ....
      target => "/etc/icinga2/repository.d/hosts/${::fqdn}/${object_servicename}.conf",
      zone => $zone,
      command_endpoint => $zone,
    }
  }

On Icinga Master server

  Icinga2::Object::Host <<| |>>
  Icinga2::Object::Service <<| |>>
  Icinga2::Object::Zone <<| |>>
  Icinga2::Object::Endpoint <<| |>>
  File <<| tag == 'icinga_host_folder' |>>

After my first commit I had problem with concat::fragment resource key name, I changed a to title, because I think is more unique when you collect your Resources.

Maybe I do something totally wrong, then let me know how I must configure icinga2 with Puppet.

Best Regards
Reamer

[bobapple]

Hey Reamer,

I'm not sure I understand everything you did, I'm not sure how renaming the service names can help you. What you probably what you want to do is following:

• On the client: Export services into puppetdb, you should use custom roles/profiles for this
• On the master: Import all services to generate icinga2 config files

When the config files on the master are generated and the Icinga2 client is connected properly to the master, Icinga2 will propagate the config to the client. The client will reload automatically when it receives new config.

Am I getting this right? Does this help you?

[Reamer]

Hi @bobapple ,
some additional questions.
How will Icinga2 propagate the config to the client? Trough API (configuration - accept_commands = true and accept_config = true) or though zone.d?
Is TicketSalt important, when I am using my puppet ca?

Best Regards
Philipp

[bobapple]

To propagate config to the clients you have basically to do the following:

• Each client is also a zone, therefore you need for each zone/client a directory in zones.d on your icinga master
• Icinga2 will propagate new configs automatically to your zones/clients, you just need to create the config files in the correct directory, for example: /etc/icinga2/zones.d/srv-web1.local.com
• The client however, will only accept the configuration if it has the option accept_config set to true

Another option is to send just commands to the client, this is where you would need to set the option accept_commands to true. But this is another scenario.

If you are using the Puppet CA, you don't have to bother about a TicketSalt in Icinga2. This is only needed if you want to use the CA generated by Icinga.

Hope I could help you!

[bobapple]

One more thing I forgot to mention.
If you are considering to export your services to PuppetDB, have a look to the Director (https://github.com/Icinga/icingaweb2-module-director).
It has an import mechanism for PuppetDB and its much faster than collecting all the resources by Puppet itself.

[zachfi]

FWIW, I'm using exported resources for the host to ensure data about the host is able to make it to the server. Then I'm executing checks over ssh. Granted, on the old version of this module. Speed of collection is much less an issue today than it used to be, unless you mean propagation of change. Applies server side mean that you can update services and which nodes those services are checked on without requiring the host to check in at all.

[kwisatz]

@Reamer I'm using exported resources (mostly with zones and endpoints though, but also some services and checkcommands) with the current master (and 0.6.0 before) without any problems. I'm supposed to publish my setup as another example but haven't got around to it yet. I hope to be able to do this over the winter holidays though.

[Reamer]

Hi,
thank you all for the great feedback.
@bobapple: Thanks for the clarification with TicketSalt and zones.d.
I'll rethink my settings. In the last year I had build the repository.d folder structure with puppet, but that's now deprecated Feature #13255

At the moment I think Icinga2-Director doesn't fit to my environment, because I can't imagine that it get all needed informations from all specific services on my hosts. I see an other problem with director. What happens with a deleted host? Must I do it delete manually or does it the director automatic?

@kwisatz
I would glad to see more example with syncing services, host, zones, endpoints 😁

@bobapple How big is the performance impact. At the moment I doesn't locate any problem.

Greetings Reamer

[bobapple]

From my experience it highly depends on the amount of Icinga objects you want to create with exported resources and on the performance of your PuppetDB. In my case its about 500 hosts and 5.500 services which lead to Puppet runs taking about 10 - 12 minutes on the Icinga master, which is to much in my opinion. Just try it out, switching import mechanisms shouldn't be so hard once you have everything set up

Can we close the PR then?

[Reamer]

Yes, we can close the PR.

[Reamer]

I've done some redesign of my icinga2 setup. At the moment I use zones.d with icinga api config sync. IcingaDirector looks nice, but I don't want this component in my current setup.

Let me explain, why I need this changes to work with exported resources.

In my profile I have this puppet code to export a service.

    @@::icinga2::object::service { "${::fqdn}_${object_servicename}": 
      service_name => $object_servicename,
      import => $templates,
      display_name => $display_name,
      host_name => $host_name,
      groups => $groups,
      vars => $vars,
      enable_flapping => $enable_flapping,
      check_command => $check_command,
 # ....
      target => "/etc/icinga2/zones.d/${::fqdn}/services.conf",
      zone => $zone,
      #command_endpoint => $zone,
    }

The FQDN in the object name is needed, because all exported resources need an unique name. Without the additional parameter "service_name", I am not able to give service objects a nice name, like "swap","procs", etc.

In commit 7266dfc we have nearly the same situation. Because I collect a lot of services with the same name, I need a unique identifier. My solution: I use the unique name from my unique service object.

If anything is not clear, let me know.

[bobapple]

Alright, I get your point. But why use $title to identify the object instead of $object_name, which is already set to $title?

[Reamer]

Hi @bobapple,
with the commit (2451bd9) object_name is set to service_name (proc, swap ... - to have nice names).
After this change we have a lot of concat::fragments objects with this name:
"icinga2::object::service::swap"
Therefore I want use the $title of the call in service.pp

icinga2::object { "icinga2::object::Service::${title}":
...
}

$title can be ${::fqdn}_swap or ${::fqdn}_proc. After this all concat::fragments should be as unique as the exported service resources.

I hope everything is clear, if not let me know.

Best Regards
Reamer

[bobapple]

We discussed this also with @lbetz in person. He will review and merge your commits. Thanks for your contribution 👍

[lbetz]

see also https://dev.icinga.com/issues/13767
coming up in bugfix release 0.7.1, fixed in branch bug/add-attribute-service_name-to-service-13767