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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
