Automatic Host creation fails if Host attributes are taken from other Host (PuppetDB involved)

[Holundermann]

Expected Behavior

Automatic creation of hosts is working multiple times without error

Current Behavior

A strange error occurs when trying to automatically generate and update hosts. The first time everything works fine. The second time, when executing two specific rules which should import hosts it fails.

Host A Sync rule check

Host B Sync rule check

Executing Host B rule results in the successful generation of Host B:

Afterwards when I try to execute the job for Host A the output changes in compare to the previous (refer to first picture):

The director don´t want to create a Host object but wants to modify a object, when executing the job, it still creates the host correctly:

So far so good, but when I try to rerun the job it wants to create again a Host:

which results in an error:

so, now i delete Host A object from the director, and, surprise, not only Host A is deleted but also Host B.

After a successful creation of Host A I receive the following error message when executing the Host A job again:

The Object Name is definitely different. Host A is generated by data delivered by Host B. I use the Puppet DB module and take custom facts to fill parameters in the host.

This or similar issues occur on multiple jobs which generate hosts out of the facts from another host.

Possible Solution

Fix the way the host is identified in the database that it is unique!

Steps to Reproduce (for bugs)

• Puppet DB addon
• create Job for creation of Host A
  Filter rule Host A:
  certname=host_b
  Proberties of Host A:
  
• create Job for creation of Host B
  Filter rule Host B:
  certname=host_b
  Proberties of Host B:
  
• Execute Host B Job
• Execute Host A Job
• Execute Host A Job again
• delete Host A (Host B should be deleted as well)

Your Environment

• Director version (System - About):
  master
• Icinga Web 2 version and modules (System - About):
  2.5.1
• Icinga 2 version (icinga2 --version):
  r2.8.2-1
• Operating System and version:
  Debian 9
• Webserver, PHP versions:
  apache 2.4
  PHP 7
  Database:
  Postgres 9.6

[Thomas-Gelf]

The problem is the filter, it doesn't work the way you might expect. It's suitable only for some very special use cases as it makes Director "blind" for everything but matching objects. This might be re-defined one day, but that's how it works right now.

You need to filter at your Import Source, something that's pretty easy with SQL or LDAP but currently not possible with the PuppetDB module. You can use the new Black- or Whitelist Property Modifier as a workaround for this. It's not very elegant, but should work flawlessly. Only drawback: preview pagination might be messed up when filtering a lot of rows, but that's the only related issue I'm currently aware of.

[Holundermann]

Can you give me an example on how to use the black or white list property modifier that i am able to create hosts from the facts of a host which is not related to the host (producing the facts)?

[Thomas-Gelf]

I'm not sure whether I can follow you. Could you please show me an example of how you're doing this right now?

[Holundermann]

OK. I will try to give you an overview on what I want to do. We have a lot of very similar Infrastructure distributed all over the country. The infrastructure will be configured local with a webfrontend to descripe in detail which hardware is present. The idea was now, to write a puppet module which reads the resulting configuration from a config file and replays the configuration as facts to the Puppetmaster. The Puppetmaster has puppet db as addon which I want to use now for an automatic generation of the Icinga2 configuration.

Therefore I want to be able to create hosts out of the facts generated on the main computer of a 'side'.

For the in detail description of how I wanted to solve this issue please refer to the inital post. I hope its clear now, otherwise just ask if something is still unclear or not well enough described, thanks a lot for the help so far.

[Thomas-Gelf]

Ok, let me start with a few suggestions:

• first of all, do not import ALL the facts. I'm not talking about "Sync", they shouldn't even "reach" your Import Source. Volatile facts like free memory or uptime would otherwise trigger changes all the times
• create a custom defined resource type in Puppet, very simple. custom::monitored_host { "hostname": ... }, no content, no action, just params
• with the PuppetDB module import resources of such types, not hosts

This will already make things easier for you and gives you more power when it goes to model your monitored objects in your Puppet modules.

I guess this approach could also help you to solve your requirement "...hosts from the facts of a host which is not related to the host...", as there will no longer be a 1:1 relation between Hosts in Puppet and monitored Hosts. In case you think that's not possible please provide a concrete example showing two very simple hosts, I'm sure we can find a good solution.

Cheers,
Thomas

[Holundermann]

That seems to work. I defined a puppet type and instanciate it with the parameters from the facts created by the same module. I assign all the necessary parameters to create the hosts in icinga director to these instances. Then i defined an import source which imports these resources from the Puppet DB

I had to change the 'key column name' to title to make it unique for the hosts I want to import. Afterwards I created the syncrules for the Zone, Endpoints, Zone Host, Main computer Hosts, ... The only thing that did not work was to assign a different object name (=other than the title of the puppet import ressource) to an Host object.

Puppet Code for host resource creation:

define test::host (
    String $address          = 'None',
    String $hostname         = $title,
    String $version          = 'None',
    String $os               = 'None',
    String $zone             = 'None',
    String $parent_zone      = 'None',
    String $command_endpoint = 'None',
) {

}

class test::monitoring_hosts inherits test {
  if $role == 'main' {
    # declare host objects for 'virtual' hosts
    if $::facts['blah'] == 'blub' {
      $test_host = {
        'hostname'         => "${::facts['monitoring']['test_host']}-Host",
        'version'          => $::facts['monitoring']['version'],
        'zone'             => $::facts['monitoring']['zone'],
        'command_endpoint' => $::trusted['certname'],
      }

      $test_zone_host = {
        'hostname' => $::facts['monitoring']['zone'],
        'version'  => $::facts['monitoring']['version'],
      }

      test::host { $test_host['hostname']:
        version          => $test_host['version'],
        zone             => $test_host['zone'],
        command_endpoint =>  $test_host['command_endpoint']
      }

      test::host { $test_zone_host['hostname']:
        address => $test_zone_host['address'],
        version => $test_zone_host['version'],
      }
    }
  }
  test::host { $::trusted['certname']:
    address     => $::facts['ipaddress'],
    version     => $::facts['monitoring']['version'],
    os          => "${::facts['os']['name']} ${::facts['os']['release']['full']}",
    zone        => $::facts['monitoring']['zone'],
    parent_zone => $::facts['monitoring']['parent_zone'],
  }
}

[Holundermann]

With the help from Thomas I was able to solve my task as wanted - I think I can therefore close this issue - even though the Puppet DB Module produced unexpected errors and worked different than I expected.

Thanks

[Thomas-Gelf]

@Holundermann: the Puppet DB module is one of the oldest Import Sources for the Director. We learned a lot in the meantime, and sooner or later we'll publish a new version. In case you have related feedback, suggestions or feature requests please do not hesitate to open related issues in it's issue tracker.