I couldn't think of or recall how, but I have a number of "in your place I
would" sort of thoughts. These could be just rhubarbing along.
On Wed, Jan 28, 2015 at 12:46:17PM -0800, Brett Swift wrote:
> I'm trying to get a useful tool for our operations guys, to give them some
> transparency on compiled values for a node.
Beyond transparency, I trust they have a way to build any host in a
non-production environment?
> The theory is they could put their hieradata code in on a feature branch,
> and I could give them a report of all the values that would go into that
> node, and also show values that the modules themselves compile off of
> facts etc.
> There's a script I created - derived from the documentation on the
> puppetlabs website, and the puppet cookbooks site:
> file { "/tmp/params.yaml":
> content => inline_template("<%= scope.to_hash { |k,v| !(
> k.is_a?(String) && v.is_a?(String) ) }.to_yaml %>"),
> }
I'm not sure how you might do it for everything at once, but for individual
items exposing them as facts via defines will give you a good deal of leverage
by using how all facts and resources are sent up to puppetdb.
define factify::mft (
$varvalue,
$varcomment,
$varhost = $::fqdn,
$var_any_descriptive_thing_really = $::somefact,
) {
$data = {
$name => {
'comment' => $varcomment,
'host' => $varhost,
'anything' => $var_any_descriptive_thing_really,
}
}
# here you could template a facter external fact if you like those?
file { "/etc/facter/facts.d/${name}.yaml":
content => inline_template("<%= @data.to_yaml %>"),
}
}
And then for every parameter you wanted exposed:
factify::mft { 'module::class::varname':
varvalue => $myvar,
varcomment => "descriptive string",
# any other thing, really
}
That would give you a structured external fact if puppet supports those
(haven't tried it) and you configure your agents with stringify_facts to false.
The resource itself would appear in the node report stored in puppetdb, so you
could parse all the resources of the define's type out of puppetdb to put them
into a web application. If the fact thing works, Puppet Explorer already
displays facts from puppetdb, use that to show the updated fact to anybody who
wanted to read them.
https://docs.puppetlabs.com/facter/latest/fact_overview.html#writing-structured-facts
> This gives me:
> ~~~~
> cmmp: "43499"
> cm_infmgr: "51499"
> dm: "42499"
> dm_sid: "1531"
> dm_ifw_sync: "44499"
> dm_vertex: "45499"
> dm_eai: "60499"
> dm_email: "47499"
> dm_eigen: "57499"
> ~~~
> .. however it only works if I put that script in the module after those
> params are calculated
> If I run this in my 'control repo' - in site.pp, it only resolves facts.
> What I'm looking for is a way of exporting the same .yaml file, or
> anything in machine parsable format, that has all variables in the catalog
> (even locally derived variables from modules). (yea, kinda overkill, but
> powerful). Derived vars are important as some of our 'in-house' modules
> take facts and input variables and derive things like ports for the
> firewall to open, so they're important for the operations guy to see in
> hypothetical scenarios.
It sounds like you'll need to gather variables from those variables' scope.
> ie: the above would appear as:
> ~~~~~
> my_module::cmmp: "4124"
> my_module::cm: "1234"
> my_module::port2: "8080"
> ~~~~~
> If this is possible, it enables me to write a little web-app for our
> production guys.
> They could insert:
>
> 1. a node name
> 2. environment for the control repo and hieradata (ie feature branch in
> 'what if' scenarios)
>
> I could then report a list of all the params that will be used in the
> catalog. This way they'd know how the hieradata hierarchy would get
> compiled and be able to validate it.
This is where I think you might be better off letting them build the host in a
pre-production manner, that way ops can see how things were built. That's
likely my personal preference at work, for seeing how something was built
rather than trusting analytics code to make the correct assumptions on how
something might be built.
> Ie: I'm about to build host "x" - will the value of "my_module::cm be
> the correct port, or do I need more data in hiera?"
> .... tell me how, and I may have time to publish a little mini web app
> that you can use :)
> ps. We're using Puppet Enterprise, but I will know all values because we
> don't use the console groups - everything is in hieradata, and
> classification is via site.pp --> roles --> profiles.
>
> --
> 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 [1]puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
>
> [2]https://groups.google.com/d/msgid/puppet-users/e5994490-f4d7-4209-a5fa-3771b465ae01%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users+unsubscr...@googlegroups.com
> 2.
> https://groups.google.com/d/msgid/puppet-users/e5994490-f4d7-4209-a5fa-3771b465ae01%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/20150129115249.GA6170%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
