node-specific resources outside of a general-purpose module

[Jonathon Anderson]

I think there's something simple I'm missing about module best practices and application to nodes.

Let's assume I've been a good module developer: I have a general-purpose module with no site- or node-specific knowledge, and it defines a number of classes (generalized with parameters, extlookup, hiera, whatever) and a few defined types.

I can apply these classes--even parameterized classes--with an ENC, but, so far as I understand, I can't apply defined types directly to a node.  I need a class that contains those defined types that I would then apply to the node.

So what is that class?  What sort of name should it have?  By its very nature, it is either node- or site-specific, right?  Thus far, I've used modules at `/etc/puppet/services` using an `s_` prefix, kind of like what's described at http://projects.puppetlabs.com/projects/1/wiki/Puppet_Best_Practice2, but I get the feeling that that is not actually what is intended.

So what *is* intended?

~jonathon

[Jeff McCune]

On Sun, Apr 8, 2012 at 2:50 AM, Jonathon Anderson <ander...@gmail.com> wrote:

So what is that class?  What sort of name should it have?  By its very nature, it is either node- or site-specific, right?  Thus far, I've used modules at `/etc/puppet/services` using an `s_` prefix, kind of like what's described at http://projects.puppetlabs.com/projects/1/wiki/Puppet_Best_Practice2, but I get the feeling that that is not actually what is intended.

So what *is* intended?

The way I approach this is to manage a module named site and put the resource declarations inside of a class within this module.

The approach is pretty well documented in the pe_accounts section [1] of the PE manual.  The pe_accounts module exposes defined resource types so I think the concepts apply to the scenario you've described.

[1] http://docs.puppetlabs.com/pe/2.5/accounts_user_type.html

Hope this helps,

-Jeff McCune

[jcbollinger]

On Apr 8, 1:50 am, Jonathon Anderson <anderbub...@gmail.com> wrote:
> I think there's something simple I'm missing about module best practices
> and application to nodes.
>
> Let's assume I've been a good module developer: I have a general-purpose
> module with no site- or node-specific knowledge, and it defines a number of
> classes (generalized with parameters, extlookup, hiera, whatever) and a few
> defined types.
>
> I can apply these classes--even parameterized classes--with an ENC, but, so
> far as I understand, I can't apply defined types directly to a node.  I
> need a class that contains those defined types that I would then apply to
> the node.
>
> So what is that class?  What sort of name should it have?  By its very
> nature, it is either node- or site-specific, right?  Thus far, I've used
> modules at `/etc/puppet/services` using an `s_` prefix, kind of like what's
> described

> athttp://projects.puppetlabs.com/projects/1/wiki/Puppet_Best_Practice2,

> but I get the feeling that that is not actually what is intended.
>
> So what *is* intended?

By whom?

I'm not following why defined types present a special problem here.
Your ENC can't directly declare resources of built-in types, either.
All resource declarations need to be in classes when you use an ENC.
I don't mean to be rude, but if your type definitions leave you
wondering where or how instances should be declared, then perhaps you
haven't been as good a module developer as you thought.


John

[Nan Liu]

On Sat, Apr 7, 2012 at 11:50 PM, Jonathon Anderson
<ander...@gmail.com> wrote:
> I think there's something simple I'm missing about module best practices and
> application to nodes.
>
> Let's assume I've been a good module developer: I have a general-purpose
> module with no site- or node-specific knowledge, and it defines a number of
> classes (generalized with parameters, extlookup, hiera, whatever) and a few
> defined types.
>
> I can apply these classes--even parameterized classes--with an ENC, but, so
> far as I understand, I can't apply defined types directly to a node.  I need
> a class that contains those defined types that I would then apply to the
> node.

You can use create_resources to make this a bit more flexible and
dynamic with the ability to specify resources in your ENC:

https://github.com/puppetlabs/puppetlabs-create_resources

Thanks,

Nan

[Jonathon Anderson]

On Monday, April 9, 2012 5:35:09 PM UTC+3, jcbollinger wrote:

I'm not following why defined types present a special problem here.

They aren't a special problem: they simply haven't *solved* the problem.  If as generalized as I can get is defining some types, where do I put the declaration of these types so that they get applied to my nodes?

It's entirely possible that this is just a namespacing question: I've seen references to a `site` module where such site-specific classes should go, and, as I've said, we're already using modules with a `s_` prefix for this purpose; but I'm looking for what the normal thing is.  If modules are not supposed to be site-specific, where do I put my site-specific config?

[Jonathon Anderson]

On Monday, April 9, 2012 6:12:48 PM UTC+3, Nan Liu wrote:

You can use create_resources to make this a bit more flexible and
dynamic with the ability to specify resources in your ENC:

Either that doesn't actually apply to my question, or using it as a solution horrifies me.

[jcbollinger]

On Apr 16, 3:13 am, Jonathon Anderson <anderbub...@gmail.com> wrote:
> On Monday, April 9, 2012 5:35:09 PM UTC+3, jcbollinger wrote:
>
> > I'm not following why defined types present a special problem here.
>
> They aren't a special problem: they simply haven't *solved* the problem.
>  If as generalized as I can get is defining some types, where do I put the
> declaration of these types so that they get applied to my nodes?

You put them into classes that are declared on your nodes -- but that
can't be the answer you're looking for. If Jeff's response does not
adequately address your question then perhaps an example would help.
What kind of defined type instances are you struggling to find a home
for?

> It's entirely possible that this is just a namespacing question: I've seen
> references to a `site` module where such site-specific classes should go,
> and, as I've said, we're already using modules with a `s_` prefix for this
> purpose; but I'm looking for what the normal thing is.  If modules are not
> supposed to be site-specific, where do I put my site-specific config?

As a matter of best practices, modules should not contain site-
specific *data*. Instead, they should obtain such data from an
external source, one or more of node facts, external data via a
service such as hiera, or class parameters. Also as a matter of best
practices, all classes should be in modules. These principles do not
conflict.

If you have classes that are site-specific in the sense that nobody
else would want to do the things they do (as opposed to containing
site-specific data), then I don't see any problem with putting them in
one or more modules. If you want, you can add a directory to your
module path for such modules, but I don't see any special need to do
so.


John