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
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/418a1860-94ba-4055-9844-1b3d557064ea%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
