Hiera values in provider

[Matthias K]

Hi, is it possible to access hiera values within a custom provider?

[Ben Ford]

Not directly. Hiera provides data to the server for use when compiling the catalog. Providers run on the agent after the catalog has been compiled.

If you need to get to Hiera data, write your type/provider such that it accepts a parameter, then look that up from Hiera and pass it in when you declare a resource.

On Mon, Aug 1, 2022 at 12:06 PM Matthias K <matthi...@gmail.com> wrote:

Hi, is it possible to access hiera values within a custom provider?

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/7b664134-0ed6-44d8-8054-b48f8de4e578n%40googlegroups.com.

[Matthias K]

Thank you. I was expecting something like that :-/ Your described process is in general what we are doing with all of our custom providers.

Unfortunately, in this case, we have something "special". The provider does not manage anything which can be accessed locally from the system.

The provider subscribes and unsubscribes yum repo channels through a remote xmlrpc interface. To do this we need a username and password, this is part of the defined resource and comes from hiera. This is fine for creating the resources since we have all parameters available in the "create" method.

But to get the list of applied resources  we are using a method within the "instances" method, that pulls the list of actually subscribed channels. This methods need the authentication information as well, but in this phase of the provider we do not have access to the parameters of the defined resources, right?

Here's the code within the instances method. The "getSubscribedChannels" method would need username and password from hiera / provided through the type. Right now it is hardcoded within the "getSubscribedChannels" method itself.

  def self.instances
    resources = []
    begin
      @subscribed_channels = getSubscribedChannels(client)
    rescue Puppet::ExecutionFailure => e
      Puppet.debug "Error while fetching subscribed channels -> #{e.inspect}"
      return {}
    end
    @subscribed_channels.each do |channel|
        resources.push(new(
          :name => channel,
          :ensure => :present,
         ))
    end
    resources
  end

Is there an alternative way to do this?

[Dirk Heinrichs]

Am Montag, dem 01.08.2022 um 12:47 -0700 schrieb Matthias K:

> The provider subscribes and unsubscribes yum repo channels through a
> remote xmlrpc interface. To do this we need a username and password,
> this is part of the defined resource and comes from hiera. This is
> fine for creating the resources since we have all parameters
> available in the "create" method.

Your provider can read arbitrary files on the agent it is running on.
This is what other providers also do, see the nexus3_rest module on
Puppet Forge for an example. It needs credentials to be able to manage
resources on a Nexus3 repository server, which it expects to be stored
somewhere in /etc/puppet.

So essentially, in the class that uses your provider, create such a
credential/configuration file before using any resources your provider
provides.

HTH...

Dirk
--
Dirk Heinrichs
Senior Systems Engineer, Delivery Pipeline
OpenText ™ Discovery | Recommind
Phone: +49 2226 15966 18
Email: dhei...@opentext.com
Website: www.recommind.de
Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
Vertretungsberechtigte Geschäftsführer Gordon Davies, Madhu
Ranganathan, Christian Waida, Registergericht Amtsgericht Bonn,
Registernummer HRB 10646
This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material in
this e-mail is strictly forbidden
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-
Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail sind nicht gestattet.

[Matthias K]

Thank you for the example.

Right now I'm going a different route to avoid having to store the password locally in plaintext and switched to an approach where I parse and filter the output of "dnf repolist" which is "good enough" for our current usecase, but I will look into the nexus provider anyway to gain some more insights how they approach the whole provider implementation when interacting with a remote api.

Best regards,

Matthias