Uploaded image for project: 'Puppet Development Kit'
  1. Puppet Development Kit
  2. PDK-610

create a `remote_resource` feature flag



    • Improvement
    • Status: Resolved
    • Normal
    • Resolution: Fixed
    • None
    • None
    • None
    • None
    • Needs Assessment


      To support puppet device, the Resource API needs to have a remote_resource feature flag, that translates to apply_to_device (e.g. https://github.com/puppetlabs/puppetlabs-netapp/blob/3db881bb2b166b2de377a98071b79ccb9b931bfd/lib/puppet/type/netapp_user.rb#L4), and provides the connection info from the device.conf to the Provider.

      Research Notes:


      https://github.com/puppetlabs/puppet/blob/38fdf16d1a287a236568854b29fed467a4e79289/lib/puppet/util/network_device.rb#L7 is the main way to get device code into the puppet process. The passed device object comes from https://github.com/puppetlabs/puppet/blob/38fdf16d1a287a236568854b29fed467a4e79289/lib/puppet/util/network_device/config.rb#L56 ff which parses the information from device.conf.

      • device.name is the fqdn from the header ( in square brackets, [name])
      • device.provider is the value of the type directive, obviously
      • device.url is the value of the url directive
      • device.options[:debug] defaults to false, and gets set to true if debug is specified

      The next line in network_device.rb then loads the current Device from the newly required file, and creates an instance passing in the url, and the options.

      The Base network device contains code to autoload the transport based on the url.scheme. For some reason nobody is using that specific code, although e.g. F5 have copied the pattern.


      The NetworkDevice facts indirector calls Device.facts to retrieve the facts from the device.

      The expected return value for Device.facts is a hash with fact names as keys to their respective values.


      The only requirement on the type is to have apply_to_device declared in the newtype block.


      The base provider has two custom functions for deviceability:

      • lookup(device, name) is called by the default prefetch() implementation to retrieve information about a single resource
      • device(url) creates a matching Device for this provider. This is used by the default prefetch() implementation to have a device, when there is none already loaded. Presumably, this happens during puppet resource runs.

      The default prefetch implementation also assumes ensurable. There is no default instances implementation, requiring additional effort to make providers work with puppet resource. (also requires a way to pass the device URL to the provider, see facter_url environment variable??)

      The main interaction code paths are supposed to happen through lookup, and flush.


        Issue Links



              david.schmitt David Schmitt
              david.schmitt David Schmitt
              0 Vote for this issue
              1 Start watching this issue



                Zendesk Support