Jira (PUP-8564) resource api transports - add support for custom remote facts

David Schmitt (JIRA)

unread,

Jun 26, 2019, 8:12:03 AM6/26/19

to puppe...@googlegroups.com

David Schmitt updated an issue

Puppet /

PUP-8564

resource api transports - add support for custom remote facts

Change By:	David Schmitt
Summary:	puppet device resource api transports - add support for custom remote facts

Add Comment

This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)

David Schmitt (JIRA)

unread,

Jun 26, 2019, 8:24:04 AM6/26/19

to puppe...@googlegroups.com

David Schmitt commented on

PUP-8564

Re: resource api transports - add support for custom remote facts

Moved the work for adding default implementations for default networking facts for IOS to MODULES-9459. Remodelling this ticket for the work to add custom facts capabilities to Resource API.

Add Comment

David Schmitt (JIRA)

unread,

Jun 26, 2019, 8:28:03 AM6/26/19

to puppe...@googlegroups.com

David Schmitt updated an issue

Puppet /

PUP-8564

resource api transports - add support for custom remote facts

Change By:	David Schmitt

Since none of the remote content goes through facter - and the local execution model of facter also doesn't lend itself to extension, `puppet device` directly delegates facts collection to the {{Device}} class. In the course of this, the possibility for customers to inject custom facts has been lost.

With the advent of Resource API Transports, we now have a architectural fault line where we can re-insert that capability.

-Specifically customers want to be able to get the IP address of their IOS devices as a fact.- moved - to MODULES-9459 -

Add Comment

David Schmitt (JIRA)

unread,

Jun 26, 2019, 8:28:03 AM6/26/19

to puppe...@googlegroups.com

David Schmitt updated an issue

Puppet /

PUP-8564

resource api transports - add support for custom remote facts

Change By:	David Schmitt

Currently Since none of the remote content goes through facter - and the local execution model of facter also doesn't lend itself to extension, `puppet device` directly delegates the collection of facts collection to the module being used {{Device}} class .

This prevents In the course of this, the possibility for customers to inject custom facts from being used has been lost .

Investigate if it is possible to integrate custom facts into `puppet device` With the advent of Resource API Transports, we now have a architectural fault line where we can re-insert that capability.

- Specifically customers want to be able to get the IP address of their IOS devices as a fact. - moved -to MODULES-9459-

Add Comment

David Schmitt (JIRA)

unread,

Jul 3, 2019, 8:32:03 AM7/3/19

to puppe...@googlegroups.com

David Schmitt updated an issue

Puppet /

PUP-8564

resource api transports - add support for custom remote facts

Change By:	David Schmitt

Since none of the remote content goes through facter - and the local execution model of facter also doesn't lend itself to extension, `puppet device` directly delegates facts collection to the {{Device}} class. In the course of this, the possibility for customers to inject custom facts has been lost.

With the advent of Resource API Transports, we now have a architectural fault line where we can re-insert that capability.

-Specifically customers want to be able to get the IP address of their IOS devices as a fact.- moved to MODULES-9459

----

* custom remote facts go to {{lib/puppet/remote_facts/TRANSPORT/NAME.rb}}, and can be deployed through any module
* custom remote facts never get loaded on the server
* puppet device and friends load all custom remote facts for the current transport
* custom remote facts directly interact with the transport and can modify the facts hash at will (add/delete/modify)
* custom remote facts need to ensure they do not interfere with each other

{code:ruby}
# lib/puppet/remote_facts/cisco_ios/ifspeeds.rb

require 'puppet/resource_api/transport'
require 'puppet_x/customer/site/cisco_ios_utility'

Puppet::ResourceApi::Transport.register_fact(:cisco_ios) do |context, facts|
facts[:ifspeeds] = PuppetX::Customer::Site::CiscoIosUtility.parse_ifspeeds(context.transport.run_command('show interfaces'))
end
{code}

Add Comment

David Schmitt (JIRA)

unread,

Jul 3, 2019, 8:44:02 AM7/3/19

to puppe...@googlegroups.com

The example adds a custom fact for {{cisco_ios}} devices that parses out some information from the {{show interfaces}} command using a helper method from {{puppet_x/customer/site/cisco_ios_utility}}.

Note how the transport name and fact implementation is passed into {{Puppet::ResourceApi::Transport.register_fact}} to be stored and used when required.

Similar to https://github.com/puppetlabs/puppet-resource_api/blob/55e464bcd591345ed5e12166f5416b44bafd10d8/lib/puppet/resource_api/transport.rb#L43-L50 when collecting facts for a remote target, the Resource API needs to load all remote_facts files for that transport and remember the discovered fact blocks. Once that is done, the transport wrapper (https://github.com/puppetlabs/puppet-resource_api/blob/55e464bcd591345ed5e12166f5416b44bafd10d8/lib/puppet/resource_api/transport/wrapper.rb#L31-L35) can retrieve the actual facts from the device, and apply all the collected custom remote facts to the facts hash before returning the result:

{code:ruby}
  def facts
    context = Puppet::ResourceApi::PuppetContext.new(@schema)
    facts = @transport.facts(context)
    Puppet::ResourceApi::Transport.custom_facts(@schema.name).each do |custom_fact_block|
      custom_fact_block.call(context, facts)
    end
    facts
  end
{code}