Ask Your Question
0

Use Razor Metadata as custom puppet facts for classification.

asked 2018-02-05 10:28:46 -0500

ffalor gravatar image

I want to know if I can use the metadata on a node provisioned by razor as a custom puppet fact for console classification.

I'm doing a zero touch build, and when I use the API to provision a razor node it will put ticket information as metadata on the server. I want to use that metadata as custom facts to automatically apply the correct classes to my new node.

First thought that came to mind was to use ruby to get the Metadata with a API call, but just wanted to make sure there is no easier way.

Thanks.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2018-02-12 11:18:13 -0500

reesek gravatar image

updated 2018-02-12 17:05:46 -0500

Yes -- you can do this. The easiest way is to throw what you want into the post_install.erb. For example, I create 3 external facts.

One is the nodeid. Since razor nodes does not output the hostname of the razor deployed node, it can be difficult to map nodeid to hostname via the razor cmd, so I drop nodeid as a fact that can then be queried on via mco or easily discovered from the node itself or the console. I also drop a boolean razor_deployed fact so I an easily differentiate systems in the ecosystem that had been deployed pre-razor, figuring this would come in handy to identify systems that are more bloated and potentially out-of-band from our fully automated razor provisioning. Lastly, I drop the data center environment to which the node belongs. This allows us to decouple our data center environments from our Puppet environments. With that, our hieradata hierarchies rely on wwtenv instead of %{environment} such that when dynamic environments (git branches) are created in the puppet-control, the data center environment follows the dynamic environment and hieradata can still be looked up without having to create one by the dynamic env name.

Anyhow, below is an example on us using the node.metadata['hostname'] to derive our wwtenv fact, and node.name to grab the nodeid.

# Create external facts
#
WWTENV=$(echo <%= node.metadata['hostname'] %> | cut -c1-3)

touch /opt/puppetlabs/facter/facts.d/razor_provisioned_facts.txt
echo 'razor_deployed=true' >> /opt/puppetlabs/facter/facts.d/razor_provisioned_facts.txt
echo 'nodeid='<%= node.name %> >> /opt/puppetlabs/facter/facts.d/razor_provisioned_facts.txt
echo "wwtenv=${WWTENV}" >> /opt/puppetlabs/facter/facts.d/wwtenv.txt

Hope this helps.

oh -- and if deploying Windows servers, the same can be done in SetupComplete.cmd.erb:

echo razor_deployed=true >> C:\ProgramData\PuppetLabs\facter\facts.d\razor_provisioned_facts.txt
echo nodeid=<%= node.name %> >> C:\ProgramData\PuppetLabs\facter\facts.d\razor_provisioned_facts.txt

set hostname=<%= node.metadata['hostname'] %>
set wwtenv=%hostname:~0,3%
echo wwtenv=%wwtenv% >> C:\ProgramData\PuppetLabs\facter\facts.d\wwtenv.txt

Answer to question in comment below: Correct. They are simply stored in a .txt file & are technically structured data facts, refer https://puppet.com/docs/facter/3.9/cu....

If removed, you are correct that the facts would disappear on subsequent puppet runs. Three things in this regard:

1.) I operate on the premise that people should not be logging into servers, manually changing things. That's Puppet's job. If someone manually manipulates one of these files, they hopefully know what they're doing. Aside from some issue with the file system that's beyond the control of human manipulation, nothing should really touch these outside of the automation that initialized them.

2.) Brownfield deployments may need to be taken into consideration. For that, I have the following that drops the wwtenv fact on systems.

class wwt::facts::wwtenv (
  # default values are in wwt/data
  String $fact_location,
  Boolean $replace_file,
) {

  file { "${fact_location}/wwtenv.txt":
    ensure             => file,
    content            => "wwtenv = ${::environment}",
    replace            => $replace_file,
    source_permissions => ignore,
  }

}

I'm using data-in-modules to provide ... (more)

edit flag offensive delete link more

Comments

1

You are awesome, thanks for adding windows our environment is like 95% windows. Quick question these facts are just stored in a text file? If this text file is removed or something then these facts will disappear right? Just making sure I have all risks determined before I implement a solution

ffalor gravatar imageffalor ( 2018-02-12 12:19:24 -0500 )edit

My response was longer than what's allotted in this comment box, so see below the original response for my reply.

reesek gravatar imagereesek ( 2018-02-12 16:55:00 -0500 )edit

reesek, thank you very much for your answers. I wish we could just assume that, but we have huge env 20k+ and majority of the servers are for our clients so they do what they please. We are just trying to keep minimum security compliance. I am implementing your suggestion thank you!

ffalor gravatar imageffalor ( 2018-02-15 08:10:58 -0500 )edit
1

Ended up making a custom function that will do a razor API call to get the information for the node and remake the file if it gets deleted. Thanks for the help!

ffalor gravatar imageffalor ( 2018-02-15 23:32:20 -0500 )edit

good stuff! Glad to be of help.

reesek gravatar imagereesek ( 2018-02-16 13:04:46 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-02-05 10:28:46 -0500

Seen: 52 times

Last updated: Feb 12