external facter for datacenter from ipaddress - new to puppet

[Difladermaus]

facter --debug returns

Fact file /etc/puppetlabs/facter/facts.d/datacenter.rb was parsed but returned an empty data set

Any help appreciate

# cat /etc/puppetlabs/facter/facts.d/datacenter.rb

Facter.add("datacenter") do

  setcode do

    datacenter = "unknown"

    # Get current ip address from Facter's own database

    ipaddr = Facter.value(:ipaddress)

    ######################################## HOUSTON data center

    if ipaddr.match("^10.220.")

        datacenter = "HOUSTON"

    ######################################## AUSTIN data center

    elsif ipaddr.match("^10.221.")

        datacenter = "AUSTIN"

    end

    datacenter

  end

end

[Felix Frank]

Hi,

this is a misunderstanding. What you implemented is a native custom fact. You cannot deploy it along with your external facts.

Instead of putting is in some_module/facts.d/, move it to some_module/lib/facter/ instead. It will be synced as a custom fact and should then work.

With external facts, you would need to make your Ruby script print

datacenter=HOUSTON

or

datacenter=AUSTIN

on stdout.

HTH,
Felix

[Ashish Jaiswal]

Hi,

This is what you are looking for, I guess.

@datacenter.rb

require 'facter'
Facter.add(:datacenter) do
        setcode do
                datacenters = { '10.220' => 'HOUSTON', '10.221' => 'AUSTIN' }

                ip = Facter.value(:ipaddress)
                network = datacenters.keys.find { |val| ip.include? val }
                datacenter = datacenters[network]

                datacenter
        end
end

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/545E898C.5070606%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

[jcbollinger]

Here's a question: why do you need or want this as a fact?  The values you are computing are completely derivative of existing facts, so there is little or no advantage to computing them on the client.  I would recommend you compute them on the master instead.  You can make them ordinary top-scope variables, or -- my preference -- make them class variables.

As a top-scope variable:

environments/production/00globals.pp
----

$datacenter = $ipaddress ? {
  /^10\.220\. => 'HOUSTON',
  /^10\.221\. => 'AUSTIN'
}

... (anywhere) ...

notice("${::datacenter} data center")

As a class variable:

modules/site/manifests/init.pp
----

class site {
  $datacenter = $ipaddress ? {
    /^10\.220\. => 'HOUSTON',
    /^10\.221\. => 'AUSTIN'
  }
}

... (elsewhere) ...

  include 'site'
  notice("${::site::datacenter} data center")

John

[jcbollinger]

On Wednesday, November 12, 2014 7:59:34 AM UTC-6, jcbollinger wrote:

$datacenter = $ipaddress ? {
  /^10\.220\. => 'HOUSTON',
  /^10\.221\. => 'AUSTIN'
}

Oops, make that ...

$datacenter = $ipaddress ? {
  /^10\.220\./ => 'HOUSTON',
  /^10\.221\./ => 'AUSTIN'
}

... of course.


John

[Neil]

Hello

I think the advantages of fact based implementation are you can use it in hiera hieracy, query it in puppeydb etc

Neil

P.s. I'd always have a default for a selector like datacenter is

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/fc8a580a-4da6-494e-978a-6f0888f70f0b%40googlegroups.com.

[jcbollinger]

On Wednesday, November 12, 2014 12:20:53 PM UTC-6, Neil wrote:

Hello

I think the advantages of fact based implementation are you can use it in hiera hieracy, query it in puppeydb etc

 

Facts do not provide an advantage over ordinary top-scope variables with respect to interpolation in Hiera.  They do get recorded in puppetdb, but in a case like this, so too do all the underlying facts from which they are derived.  The PuppetDB query API supports a regex match operator which could be used against the 'ipaddress' fact in this particular case, so at best the custom fact gets you a small convenience in your queries (which, however, are probably machine-generated anyway, so any such convenience is mostly wasted).  I'm not sure what the "etc." could be.


John