Wiki should mention mcollective default config assumes gnatsd running on 'puppet' node

[choria-legacy]

Wiki should mention mcollective default config assumes gnatsd running on 'puppet' node

[ripienaar]

It's covered just above and below https://github.com/ripienaar/mcollective-choria/wiki#dns-srv-records - I do not parse puppet.conf - probably could though.

Most typically you're going to go simple 1 node so default behaviour as puppet or have to configure a multi node cluster where SRV records are better alternatively manual config as at the bottom of the wiki.

I'll keep this one around to see about parsing puppet.conf agent section

[MikaelSmith]

Ah, I only skimmed that section and don't scroll to the bottom. A link to the specific section for manual config would be nice.

[MikaelSmith]

I'm fine with manual config otherwise, there's no reason to tie gnatsd to your puppet master.

[ripienaar]

This came up on the users list so I thought I'd have a closer look:

The problem is the performance of doing this:

require "benchmark"

Benchmark.bm(10) do |bm|
  bm.report(:require) { require "puppet" }

  bm.report(:config) do
    unless Puppet.settings.app_defaults_initialized?
      Puppet.settings.preferred_run_mode = :agent

      Puppet.settings.initialize_global_settings([])
      Puppet.settings.initialize_app_defaults(Puppet::Settings.app_defaults_for_run_mode(Puppet.run_mode))
    end
  end

  bm.report(:get) { Puppet.settings[:ssldir] }
end

                 user     system      total        real
require      0.930000   0.070000   1.000000 (  1.017435)
config       0.010000   0.000000   0.010000 (  0.005174)
get          0.000000   0.000000   0.000000 (  0.000036)

So just doing require puppet takes a second, its a noticeable and very annoying slow down on the CLI.

So I'd do this:

• make it configurable with choria.ssldir that understands ~ path expansion
• talk to puppet when run as root only - ie. the daemon

I think this strikes a good balance - the daemon loads up puppet anyway for the puppet agent so no wasted effort/time there really

I realise this ticket is about puppet and not about SSL but the same problem exist, I'm definitely not introducing a 1 second slow down to find the puppet master. For the servername though I could just parse the config myself I suppose, such a hack though so I'll rather support a more robust setup - SRV records to maintain the Just Works - which is compatible with Puppet - or manual config.

[ripienaar]

Closing this one, while I wont solve the puppet thing just yet for reasons stated above there is now code to handle puppet settings and its used for ssl dir location when not root