Re: Is there any ways to fetching custom fact after some resources setuped?

[jcbollinger]

On Thursday, December 6, 2012 9:13:58 PM UTC-6, cynipe wrote:

I'm currently trying to create icinga module and the icinga-web and icinga-idoutils-libdbi-mysql from rpmforge
store the initial sql file in version numbered directory(/usr/share/doc/icinga-web-1.7.2/~~~).

So, I try to determine the version number from the yum info like as below, but that repository installed after my yum module gets work done.
Is there any ways to fetching custom fact after some resources setuped or any smart way to do this?

All facts are evaluated before the master compiles a catalog.  The whole catalog is compiled before it is returned for the agent to apply.  The only way, therefore, to get a value of a custom (or built-in) fact that reflects changes applied by Puppet is to perform a second Puppet run.

As for your code,
 

icinga_version.rb
----
def get_redhat_icinga_version
  version = Facter::Util::Resolution.exec('yum info icinga |grep "^Version"')
  if match = /^Version\s*:\s*(\d+\.\d+\.\d+)$/.match(version)
    match[1]
  else
    nil # should be fail?

No, it should not be fail.  Nor nil, really.  It should be an empty string or some special value (e.g. 'unknown'), depending on what serves your need best.
 

  end
end

I really don't like facts relying on functions in that way, because scoping and control flow becomes really confusing.  Probably it would work, but your function is not doing so much that it really warrants being pulled out, especially with the fact itself doing as little as it does.  Furthermore,

Facter.add("icinga_version") do

If the fact only applies to certain cases (that Facter can recognize) then it is far better to 'confine' it to those cases than to return dummy values (or worse, fail!) in the other cases (see http://docs.puppetlabs.com/guides/custom_facts.html):

  confine :osfamily => 'RedHat'

 

  setcode do
    case Facter.value('osfamily')
      when 'RedHat'
        get_redhat_icinga_version()
      else
        nil # should be fail?

With the 'confine' as above, the whole case statement is redundant, leaving only the function call (which would be better replaced by the function's body).
 

    end
  end
end
----

Overall, you have a few options.  Because the issue is basically a one-time thing, it might be satisfactory to just allow Puppet two runs to finish configuring the target node.  Alternatively, you could write an Exec'd script to manage a fixed-name symlink to the needed icinga directory(-ies), and in your module refer to icinga files in terms of that link.  Or you could even use the value of the icinga_version fact to fall back to the latter behavior when the real version cannot be determined (i.e. in your bootstrap case), but to manage resources directly when the version can be determined.  No doubt you could conceive other alternatives if you wanted to do.


John

[Jakov Sosic]

On 12/07/2012 03:52 PM, jcbollinger wrote:
> No doubt you could conceive other alternatives if you wanted to do.

I would suggest skipping the whole facter+version+two_puppet_runs mess
and just ensure => $version. Later use variable $version in the
manifests to point your resources to correct location of SQL file. Not
to mention that yum is sometimes painfully slow, so having 'yum info' in
your facts won't be of much help to agent performance.



--
Jakov Sosic
www.srce.unizg.hr