You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When managing network devices, customers want to enrich the collected facts with locally relevant information. Since the device facts don't go through facter (and require custom access to the transport anyways) there is currently no good way to inject custom facts.
Describe the Solution You Would Like
With Resource API Transports, we now have a place to inject facts programmatically:
# @transport.facts + custom_facts # look into custom facts work by TP
@transport.facts(context)
end
Modifying this function allows us to add more functionality into the fact-processing code path at will.
Since we can make no general assumptions about transport APIs, the main fact API is a mutate_facts(context, facts) -> Hash method that allows arbitrary changes to facts data. A simpler and safer option would be additional_facts(context) -> Hash which can only add facts.
For the significant class of SSH/CLI based Transports, we also want to implement a data-based way to add facts. In this case the transport would need to declare a command_based feature flag and provide a execute_command(command) -> output function. A command-based fact then would be a YAML file similar to this:
# some_fact.yaml
---
name: value_fetch
command: "show version"
pattern: "some weird regexp fetching values from the output"
which would create a new fact value_fetch which contains the matched values from show version using the pattern regular expression. Might also use named capture groups for building a Hash.
Any custom facts need to be able to be deployed through a different module than the one implementing the Transport.
Additional Context
This has been regulariy requested by networking customers.
There is some internal prior work: see FM-7071, FM-8086, FM-7931, #105 and some more.
The text was updated successfully, but these errors were encountered:
Use Case
When managing network devices, customers want to enrich the collected facts with locally relevant information. Since the device facts don't go through facter (and require custom access to the transport anyways) there is currently no good way to inject custom facts.
Describe the Solution You Would Like
With Resource API Transports, we now have a place to inject facts programmatically:
puppet-resource_api/lib/puppet/resource_api/transport/wrapper.rb
Lines 31 to 35 in b8d8817
Modifying this function allows us to add more functionality into the fact-processing code path at will.
Since we can make no general assumptions about transport APIs, the main fact API is a
mutate_facts(context, facts) -> Hash
method that allows arbitrary changes to facts data. A simpler and safer option would beadditional_facts(context) -> Hash
which can only add facts.For the significant class of SSH/CLI based Transports, we also want to implement a data-based way to add facts. In this case the transport would need to declare a
command_based
feature flag and provide aexecute_command(command) -> output
function. A command-based fact then would be a YAML file similar to this:which would create a new fact
value_fetch
which contains the matched values fromshow version
using thepattern
regular expression. Might also use named capture groups for building a Hash.Any custom facts need to be able to be deployed through a different module than the one implementing the Transport.
Additional Context
This has been regulariy requested by networking customers.
There is some internal prior work: see FM-7071, FM-8086, FM-7931, #105 and some more.
The text was updated successfully, but these errors were encountered: