FAQ
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.

Search Discussions

  • Jcbollinger at Dec 7, 2012 at 2:52 pm

    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.
  • Jakov Sosic at Dec 12, 2012 at 1:28 am

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedDec 7, '12 at 3:29a
activeDec 12, '12 at 1:28a
posts3
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase