Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Facts does not work with preview/output with PuppetDB 4 #2

Closed
TheFlyingCorpse opened this issue Jun 26, 2016 · 1 comment
Closed

Facts does not work with preview/output with PuppetDB 4 #2

TheFlyingCorpse opened this issue Jun 26, 2016 · 1 comment

Comments

@TheFlyingCorpse
Copy link

When adding the PuppetDB output, everything seems OK, except that preview does not present any facts in any other colums than the "massive" facts one.

Trying to apply modifiers to the single facts does not yield any different results either.

The module correctly guesses classes, nodes, resources and the name of the facts but it does not return the data from them.
Currently using PuppetDB 4.1.2

@Thomas-Gelf
Copy link
Collaborator

Honestly I used the "Nodes" query type only for stress-testing Icinga Director as it allowed me to sync with massive and very frequent changes :D In my "normal workflow" I export some dummy objects for all my systems and collect them with the Director. They look as follows:

@@my_monitoring::icinga_host { $::fqdn:
  display_name => $::hostname,
  address      => $::ipaddress,
  vars         => {
    some        => 'facts',
    environment => $::environment,
  }
}

This allows me to have explicit control over those object in Puppet. Data is always nested, so at top level you mostly have certname, title and so on - the rest is part of "parameters". When defining sync rules you mostly have to manually define them as ${parameters.vars.whatever}, as there is no way to collect distinct names from PuppetDB, at lease not with legacy versions.

As you mentioned property modifiers, could you please open a feature request for them? They currently do not allow one to access nested structures. I started to have hooked modifiers dealing with nested structures in custom modules, that works fine. But it should IMO be possible to say "Please uppercase parameters.vars.osfamily".

Regardless of this, I'm not 100% sure I really understood your comment - so if I was wrong with my assumptions please let me know ;-)

Cheers,
Thomas

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants