Parameterized classes vs defined-types

[Digant C Kasundra]

Out of curiosity, how are people using parameterized classes in a way that is distinct from defined-types?

--
Digant C Kasundra <dig...@stanford.edu>
Infrastructure Systems Software Developer, ITS:IDG, Stanford University

[jcbollinger]

On Aug 23, 1:00 pm, Digant C Kasundra <dig...@stanford.edu> wrote:
> Out of curiosity, how are people using parameterized classes in a way that is distinct from defined-types?

<snark>I am _using_ defined types, that's how.</snark>

Although I disfavor parameterized classes and do not use them, the
pattern of my usage of defined types could not be implemented via
parameterized classes. In particular, I typically do not define a
type unless I plan to instantiate it multiple times for the same
node. You cannot do that with parameterized classes.

If you have an OO background then the words "class" and "type" may
have connotations and implied similarity for you that just don't apply
in Puppet. Puppet classes are not "types" in the type theory sense.
Defined types are closer to that, but it may help to use a fuller name
when you think about them: defined *resource* types. Classes,
parameterized or not, are not resource types; rather, they are
resource _collections_.


John

[Henrik Lindberg]

On 8/24/11 3:46 PM, jcbollinger wrote:
> If you have an OO background then the words "class" and "type" may
> have connotations and implied similarity for you that just don't apply
> in Puppet. Puppet classes are not "types" in the type theory sense.
> Defined types are closer to that, but it may help to use a fuller name
> when you think about them: defined *resource* types. Classes,
> parameterized or not, are not resource types; rather, they are
> resource _collections_.

I find it helps me to think of classes as *host*-class = a type of host
classification (i.e. like measurements Weight and Height) - it is
nonsensical to classify it multiple times e.g size = big, size = small,
at best it would be redundant (size = big, size = big) to classify a
host with the same puppet class multiple times (but I think that special
case is also flagged as an error - which it should because the structure
is clearly wrong).

Please correct me if I am wrong - I am also learning puppet.

- henrik

[Digant C Kasundra]

I agree with you. I think that's why I'm curious. We also overrides on defined types, which is why we prefer them as well. I think while it may be possible to do what we are currently doing with parameterized classes, it would at least involve a lot of restructuring how we think of things in our manifests.

[Lesley Kimmel]

I've [somewhat] recently started developing Puppet modules for use with Foreman and have gone through a couple iterations. At first I was developing a large, broadly-scoped module for a specific purpose. I soon found that in order to provide any amount of customizable behavior I would have to provide so many parameters that it was unwieldy.

Therefore, I moved into using much more purpose-specific modules (e.g. sshd, aide, chrony, etc). These modules provide a lot of flexibility but then you lose the centralized view of the things the configuration items for a specific application or workflow require.

I recently came across some modules on the Forge that got me considering using modules with defined types exposing their functionality. I think this seems to be the ultimate way to do things because it allows the same flexibility as the purpose-specific module setup while essentially requiring you to have another module for your application or workflow which utilizes the defined types from all of your defined type augmented modules.

However, I would very much prefer an all or none solution. That is I don't want to have defined type modules for pieces of a workflow but have to directly configure parameters on other modules for other pieces of my workflow. Unfortunately, the module availability on the Forge seems to be about 50/50 at best (that is maybe half the modules are built with defined types). Also, the use of defined types, at least when dealing with config files, essentially means using either Augeas or Concat. For complex configuration files this can often be quite difficult (which I think is why many people default to templates).

So, in order to use the defined type route it would seem that one needs to invest a lot of time in developing custom modules. It seems easier and not much worse to just settle for purpose-scecific parameterized modules. This has the side effect of giving a better centralized view of all the configurations applicable to a given process or library.

I'm very interested in hearing about other peoples' experiences and recommendations.

[jcbollinger]

On Wednesday, May 3, 2017 at 4:35:02 PM UTC-5, Lesley Kimmel wrote:

I've [somewhat] recently started developing Puppet modules for use with Foreman[...]

I recently came across some modules on the Forge that got me considering using modules with defined types exposing their functionality. I think this seems to be the ultimate way to do things because it allows the same flexibility as the purpose-specific module setup while essentially requiring you to have another module for your application or workflow which utilizes the defined types from all of your defined type augmented modules.

I'm not sure I entirely follow you here, but since you specifically brought up Foreman, you should be aware that defined types are resource types, and Foreman cannot declare Puppet resources directly (the Puppet ENC interface has no provision for it).  Thus, if you had in mind to set the parameters of instances of your defined types via Foreman then your plan is a non-starter.

Inasmuch as you describe creating a class that uses the defined types, I suspect your plan is different, but then I don't see what advantage you perceive in defined types.  You can just as easily create a class that declares other classes.  In fact, this is one of the key concepts in the Roles & Profiles pattern, which is aimed pretty squarely at the problem you describe, at least as I understand it.

You should also be aware that Puppet's best mechanism for feeding parameters to classes is automated data binding via Hiera.  You'll find lots of information on that via Google.  The main drawback from your perspective would probably be that you cannot manage Puppet's external data via Foreman, at least not as far as I am aware.

John