Idiomatic Puppet way to get global context in a instances method from a custom provider

[bert hajee]

L.S,

What is the idiomatic Puppet way to get global context in a instances method for a custom provider?

I’m building a custom type and provider for some Oracle items. Oracle can have multiple databases running on a system. So I need a way to tell the instances method to which database to connect. 

I’ve got a couple of idea’s myself, but don’t know which is best and if there are better ways:

1. Not using the instances method. This means I can use a regular parameter to specify to which database to connect. But I lose the ability to list my resources with puppet resource tablespace.
2. a custom type providing some defaults e.g.
   ora_settings{'default': 
      database => 'mydb'}
   And store this information and use it in the regular resources. This fits well with Puppet, but requires an extra custom type.
3. Just use some environment variables. This doesn’t fit well within a Puppet workflow
4. Use an external fact. This seems like misuse of a Fact, But it is easy to access this information in a custom provider 

Any thoughts are appreciated? 

Bert

 

 

 

 

 

[Trevor Vaughan]

You might want to take a look at using Composite Namevars.

A good example exists in the java_ks type https://github.com/puppetlabs/puppetlabs-java_ks.

Trevor

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/dd048be9-2a72-4857-a7b5-13aaa96cc2dd%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[bert hajee]

Trevor,

Thanks for the suggestion. That certainly looks like a good match  for the example I've given. An other example we are working on is WLS. For WLS we need access to:

• user
  
• domain
• domains_path
• connect_url
• admin_server

Although some of these elements would fit perfectly in a composite namevar, I feel some others don't. Besides, it would make a very long name. Any thoughts on how to handle this?

Thanx in advance,

Bert

Op maandag 17 februari 2014 23:30:22 UTC+1 schreef Trevor Vaughan:

[John Bollinger]

On Monday, February 17, 2014 3:53:42 PM UTC-6, bert hajee wrote:

L.S,

What is the idiomatic Puppet way to get global context in a instances method for a custom provider?

To the best of my knowledge, there is no appropriate global context for providers to access within Puppet, especially if the objective is for other objects to provide data for providers (as opposed to providers creating and using their own data, perhaps across instances).
 

I’m building a custom type and provider for some Oracle items. Oracle can have multiple databases running on a system. So I need a way to tell the instances method to which database to connect. 

Not exactly.  You might need that (and various other data) for prefetching to work, but I think prefetching is optional.

 

I’ve got a couple of idea’s myself, but don’t know which is best and if there are better ways:

1. Not using the instances method. This means I can use a regular parameter to specify to which database to connect. But I lose the ability to list my resources with puppet resource tablespace.

I think that's your best available option within Puppet if you must restrict activity to a single database.
 

1. a custom type providing some defaults e.g.
   ora_settings{'default': 
      database => 'mydb'}
   And store this information and use it in the regular resources. This fits well with Puppet, but requires an extra custom type.

Awful.  It fits well with Puppet only in the sense that Puppet custom types may be flexible enough to be misused in this way.  And even then I am not certain it would work reliably.
 

1. Just use some environment variables. This doesn’t fit well within a Puppet workflow

You say that as if it would be safe and easy, but the environment in which the agent runs is greatly influenced by how it is launched.  Depending on environment variables for essential data would at best be brittle.
 

1. Use an external fact. This seems like misuse of a Fact, But it is easy to access this information in a custom provider 

It's unclear to me how a fact would help you here unless you were feeding it as a parameter to instances of your type, which is then just one variation on your first option.
 

It seems to me that you are choosing an odd and difficult boundary for the scope of your types.  It will bite you, too, if ever you have a need to manage objects in more than one database on the same target node -- that would be impossible if you make the provider specific to a particular database, even on a parameterized, per-run basis.

Would there be a problem, though, with simply making your provider service objects from all databases on the target node?  Then you can do prefetching as normal, but you do need to go to the composite namevar for resource types that otherwise afford an opportunity for name collisions.


John

[Stefan Schulte]

On 17.02.2014 22:53, bert hajee wrote:
> L.S,
>
> What is the idiomatic Puppet way to get global context in a instances
> method for a custom provider?
>
> I’m building a custom type and provider for some Oracle items. Oracle
> can have multiple databases running on a system. So I need a way to tell
> the instances method to which database to connect.
>
> I’ve got a couple of idea’s myself, but don’t know which is best and if
> there are better ways:
>

> 1. Not using the instances method. This means I can use a regular

> parameter to specify to which database to connect. But I lose the
> ability to list my resources with puppet resource tablespace.

> 2. a custom type providing some defaults e.g.

> ora_settings{'default':
> database => 'mydb'}
> And store this information and use it in the regular resources. This
> fits well with Puppet, but requires an extra custom type.

> 3. Just use some environment variables. This doesn’t fit well within a
> Puppet workflow
> 4. Use an external fact. This seems like misuse of a Fact, But it is

> easy to access this information in a custom provider
>
> Any thoughts are appreciated?
>
> Bert

The instances method could parse /etc/oratab (or /var/opt/oracle/oratab
on Solaris) to get a list of database instances first and from there get
all tablespaces. To have unique resource names if two databases have
tablespaces with the same name, you can define your resource title to be
"<databasename>/<tablespacename>"

-Stefan