class invocation instead of 'include'

[Antidot SAS]

Hi everyone,

I am asking a quick question is there any concept difference between:

--

include myclass

--

and

--

class { 'myclass'}

--

I confess that the border between those 2 concepts are very similar for me...

Regards,

Jeremy MAURO

[Stephen Gran]

Hi,

They should do the same thing - include a class with default values if
it is parameterized.

There is one difference that is most likely a bug. try this manifest:

./test.pp
class { 'wobble': }
class { 'wibble': }

./modules/wobble/manifests/init.pp
class wobble {
class { 'wibble': }
}

./modules/wibble/manifests/init.pp
class wibble {
notice "hello, I'm wibble"
}

notice: Scope(Class[Wibble]): hello, I'm wibble
Duplicate declaration: Class[Wibble] is already declared

The compiler doesn't treat these as two 'include' statements, for some
reason.

Cheers,

> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users
> +unsub...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.

--
Stephen Gran
Senior Systems Integrator - guardian.co.uk

Please consider the environment before printing this email.
------------------------------------------------------------------
Visit guardian.co.uk - newspaper of the year

www.guardian.co.uk www.observer.co.uk www.guardiannews.com

On your mobile, visit m.guardian.co.uk or download the Guardian
iPhone app www.guardian.co.uk/iphone

To save up to 30% when you subscribe to the Guardian and the Observer
visit www.guardian.co.uk/subscriber
---------------------------------------------------------------------
This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.

Guardian News & Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.

Guardian News & Media Limited

A member of Guardian Media Group plc
Registered Office
PO Box 68164
Kings Place
90 York Way
London
N1P 2AP

Registered in England Number 908396

[Antidot SAS]

Thx for the quick answer.

To unsubscribe from this group, send email to puppet-users...@googlegroups.com.

[Felix Frank]

Hi,

On 06/26/2012 10:56 AM, Stephen Gran wrote:
> There is one difference that is most likely a bug. try this manifest:
>
> ./test.pp
> class { 'wobble': }
> class { 'wibble': }

I disagree on this being a bug.

This syntax is for parameterized classes. Such classes cannot be
declared more than once, because the declaration binds parameter values
that cannot be sanely changed at a later point of compilation.

So multiple usage of this syntax is not supported.

I'd suggest avoiding it if it's not needed pass actual class parameters.

Cheers,
Felix

[Stephen Gran]

Hi,

I disagree that instantiating a class twice with identical (especially
default) parameters should result in an error. A class is a singleton,
unlike a define, so should not be indexed solely on it's name. It
should be an error to try to redefine the parameters that you
instantiate a class with, of course.

However, I see that this is probably not a trivial change, and I don't
think it's that big a deal, in practice. It does mean jumping through
some hoops when you have something like multiple application classes
using a single parameterized configuration class, but it can be lived
with.

Cheers,

[jcbollinger]

On Tuesday, June 26, 2012 5:14:32 AM UTC-5, Stephen Gran wrote:

I disagree that instantiating a class twice with identical (especially
default) parameters should result in an error.  A class is a singleton,
unlike a define, so should not be indexed solely on it's name.  It
should be an error to try to redefine the parameters that you
instantiate a class with, of course.

I sympathize and agree in principle with the view that it should be possible to re-declare the same parameterized class provided the parameters are all the same.  Nevertheless, that has never been possible with Puppet 2.x's parameterized class declaration syntax.  At the time that syntax and its rules were designed, the prevailing view at Puppetlabs was apparently that the resulting constraints were acceptable.  It's one of the reasons I find parameterized classes unacceptable, but I can't call it a bug per se.

I have been told that this will be better in Puppet 3, but I have not checked whether that's so.

John

[Russell Harrison]

I think I'm good with only allowing declaring a class once with parameters it makes since that puppet can't make a decision on which set of parameters to use what with not being able to read your mind and all. :-)

I would like to be able to include a class in multiple places even if I have declared the class with parameters somewhere else in the catalogue. As it works now I can do this as long as the first place the compile sees the class is the declaration with parameters.  If you include a class before the compiler gets to the parameterized declaration you get the error complaining about declaring a class more than once. I sort of view an include as saying "I just need some stuff from that other class so I can reference it here and I don't really care what parameters are passed to it". Declaring a class with parameters is for the cases where I do need to be specific.

Russell

[Nick Fagerlund]

On Tuesday, June 26, 2012 6:13:21 AM UTC-7, jcbollinger wrote:

I sympathize and agree in principle with the view that it should be possible to re-declare the same parameterized class provided the parameters are all the same.  Nevertheless, that has never been possible with Puppet 2.x's parameterized class declaration syntax.  At the time that syntax and its rules were designed, the prevailing view at Puppetlabs was apparently that the resulting constraints were acceptable.  It's one of the reasons I find parameterized classes unacceptable, but I can't call it a bug per se.

I have been told that this will be better in Puppet 3, but I have not checked whether that's so.

It's better! It turns out the solution to class parameter conflicts is to get the parameter values from somewhere outside the manifests. That way, the decisions about what the values should be are already finished by the time the catalog is being compiled, and you can just use "include" on parameterized classes as many times as you want.

Our implementation is to get class parameters from Hiera. If a class has parameters, using include on it it will automatically trigger a standard Hiera lookup of those parameters. It'll be roughly equivalent to doing:

class {'myclass':
  param1 => hiera('myclass::param1'),
  param2 => hiera('myclass::param2'),
}

You can still use the class {'my_class':} style if you want to (with all the same limitations as today), but since "include" will work now and Hiera isn't very complicated, we figure most people can forget about it.

Anyway, as you can see, that changes the mental model a bit -- the hiera yaml files become sort of a cascading configuration file for all of your Puppet classes, and class parameters are like settings.

[Stephen Gran]

Hi,

That's perfect, thank you. That restores the singleton nature of
classes to parameterized classes, which is IMHO much nicer than what we
have at the moment. I look forward to using this :)