*> **Agree with John that you want to completely avoid using the 
parameterized style declaration of classes. Better to use 
'include'  statements and set all of your params in Hiera. *

That's an interesting discussion, 
but that's not the point of this post.

the point of this post, as I understand it from my colleague,
is that there is a bug in puppet.

on the very least, if that is not a bug, 
puppet should complain with a clear error message of the type "Error: class 
'c1' mixes include-like and resource-like declarations",
instead of the incomprehensible error message: "Error: Duplicate 
declaration: Class[C1] is already declared; cannot redeclare at 
/vagrant/files/aa.pp:4".


About this note:

http://docs.puppetlabs.com/puppet/latest/reference/lang_classes.html#declaring-classes
*Include-Like vs. Resource-Like*
*Puppet has two main ways to declare classes: include-like and 
resource-like.*
*Note: These two behaviors should not be mixed for a given class. Puppet’s 
behavior when declaring or assigning a class with both styles is undefined, 
and will sometimes work and sometimes cause compilation failures.*


I think that the *result* of class { java: } and include java are 
semantically equivalent.
I cannot think of any conceptual reason why these two behaviours could not 
be mixed for a given class.
Do you have any conceptual reason of why that can be a problem?

I can only think that this is a technical problem in the puppet 
implementation, that could be fixed.
what prevents puppet to allow mixing these two behaviours for a given class?
(a part from a refactoring of the code...)


Regards,
David


On Thursday, April 3, 2014 4:10:50 PM UTC+2, Garrett Honeycutt wrote:
>
> On 4/2/14, 3:23 PM, jcbollinger wrote: 
> > 
> > 
> > On Wednesday, April 2, 2014 4:57:39 AM UTC-5, David Portabella wrote: 
> > 
> >     Oh My God! 
> > 
> >     you mean that "it's not a bug, it is a feature" ? 
> > 
> > 
> > 
> > It is not a feature in the sense of a desired outcome, but it /is/ the 
> > intended behavior.  Specifically, if there is any parameterized-style 
> > declaration of a given class, then that must be the first declaration of 
> > that class that is evaluated during catalog compilation.  This is 
> > analogous to the prohibition on duplicate resource declarations (and 
> > note that as a corollary it prohibits multiple parameterized-style 
> > declarations of the same class).  Declarations via "include", "require", 
> > or "contain" may be evaluated subsequent to a parameterized-style 
> > declaration, however, because in that context they do not influence the 
> > class's parameter values. 
> > 
> > I characterize it as a design flaw in Puppet's parameterized-style class 
> > declaration syntax, and based on this issue I have been urging people to 
> > avoid parameterized classes ever since they were first introduced.  The 
> > situation is somewhat eased in modern (3.x) Puppet, however, where you 
> > can leverage hiera to use parameterized classes without the 
> > parameterized syntax.  These days I advise people only to avoid 
> > parameterized-style declaration syntax (for classes), not necessarily to 
> > avoid parameterized classes altogether. 
> > 
> > 
> > John 
>
> Agree with John that you want to completely avoid using the 
> parameterized style declaration of classes. Better to use 'include' 
> statements and set all of your params in Hiera. 
>
> Here's a link[1] to a talk I gave two years ago about this topic. 
>
> [1] - http://www.slideshare.net/gh/20130407-load-puppevtv3andhiera/17 
>
> Best regards, 
> -g 
>
> -- 
> Garrett Honeycutt 
> @learnpuppet 
> Puppet Training with LearnPuppet.com 
> Mobile: +1.206.414.8658 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" 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-users/1638974f-5014-4a47-85a4-b46ca5fec78e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to