Puppet users - Dec 2012 - Is there any ways to fetching custom fact after some resources setuped?

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?

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?
  end
end

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

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/5Fg1Xu6ghSUJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/BDF404DMIHsJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.