0
votes

I'm writing a custom provider and I'm only going to use it in the context of the module it's attached to. The module will already define things for the resource which I need to act on (e.g. username, password, IP Address). What I'm trying to do is access a variable in scope in the puppet manifest from the custom provider.

Is this possible?

init.pp:

class mymodule(
   $username  = 'admin',
   --  snip --
}

provider.rb:

class Puppet::Provider::MyProvider < Puppet::Provider
   def self.configure
      #can I get to $mymodule::username here?

Some context:

I'm writing a set of types that will configure a server via an API. I want to have a type like:

mymodule_mail_settings { 'current':
    server => 'mail.server.com'
    mailuser => 'mail'
}

What I'm trying to avoid is having to pass the username/password/ip to access the server's API passed into all of these different types.

1
This isn't the way to do this. You want to associate a provider with a type and then you can use the attributes assigned to its parameters as variables in your provider. - Matt Schuchard
the issue is I have about 20 types that are all applicable to this resource. They need the username and password to query the resource, so I was trying to see if I could avoid copy pasting the username, password and ip address into every type, particularly if they will all be called in a context where it's available - Spence
Twenty types that all require a username and password sounds kind of suspicious, but you should be able to do some ruby tricks in the types source code to make the username and password reusable from a base type. - Matt Schuchard
puppet doco was pretty clear that you can't have types derive from a base type. FYI it's a rest interface with a large number of grouped settings. So it's the same credentials to the server but each group of settings will be separate. Just before I used brute force and added them manually to every setting I was just trying to check if it was possible to get to the in scope parameters. - Spence
Oh right, I was thinking base providers and base properties. - Matt Schuchard

1 Answers

0
votes

The variables are only meaningful in the context of evaluating the manifest code and creating a catalog. They don't become part of the catalog. This is why your type/provider code cannot work with them directly.

To avoid passing redundant info to lots of resources that share it, you can use some "clever" tricks. In a patch I wrote some time ago, I added this kind of meta-information to Puppet's resources type. You cannot do this in a module, but you can add your own meta-type to carry such hints.