This suggests you might have included Foo both from Foreman and also
elsewhere in a manifest.
The change in 1.1 that probably triggered it was enabling parameterised
classes in the ENC output, so the YAML output changed very slightly from
an array to a hash. You can disable this in More->Settings and set
Parametrized_Classes_in_ENC to false. This means though that you can't
use the new smart class parameters functionality.
Maybe grep through your manifests and see if there's anywhere the class
might be included in there too, as Puppet appears to be treating it as a
duplicate declaration.
···
On 03/04/13 01:09, David wrote:
> Hello,
>
> After upgrading from 1.0 to 1.1 using the el6 rpm, all my catalogs fail with
>
> err: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Duplicate declaration: Class[Foo] is already declared on node bar
>
> where bar is a host and Foo any of my classes.
>
> I didn't notice anything particular in the YAML dump (no duplicate entry
> here), except that I have "environment: *id001" while I think it was
>
> "environment: *id001 production" before (the environment is set to production in foreman hosts)
>
> Removing most puppet classes (but 10) from an host make it compile about 1 out of 2 times, using "puppet master --verbose --debug --compile bar"
> Removing all puppet classes from an host make it always compile ;)
>
> Any hints?
–
Dominic Cleal
Red Hat Engineering
That's peculiar, I don't why it would cause a problem. You can still
use classes included by Foreman and classes included inside manifests,
provided you're not including the same one twice. It doesn't sound like
you're doing that with xinetd, so I'm not sure what's going on, unless
xinetd is included on the host itself rather than the hostgroup?
It's ok to use the "include" syntax twice, but with the resource style
class includes (which the parameterised ENC is effectively), then it's
not valid and causes that error. Mixing them to include the same class
I think is undefined, but doesn't cause an error on Puppet 3 IIRC.
Often people do include some classes from the ENC and some from Puppet,
e.g. using high level role classes in the ENC and those then include a
number of more specific classes.
···
On 03/04/13 09:44, David wrote:
> On Wednesday, April 3, 2013 9:33:53 AM UTC+2, Dominic Cleal wrote:
>
> On 03/04/13 01:09, David wrote:
> > Hello,
> >
> > After upgrading from 1.0 to 1.1 using the el6 rpm, all my catalogs
> fail with
> >
> > err: Could not retrieve catalog from remote server: Error 400 on
> SERVER:
> > Duplicate declaration: Class[Foo] is already declared on node bar
> >
> > where bar is a host and Foo any of my classes.
> >
> > I didn't notice anything particular in the YAML dump (no duplicate
> entry
> > here), except that I have "environment: *id001" while I think it was
> >
> > "environment: *id001 production" before (the environment is set to
> production in foreman hosts)
> >
> > Removing most puppet classes (but 10) from an host make it compile
> about 1 out of 2 times, using "puppet master --verbose --debug
> --compile bar"
> > Removing all puppet classes from an host make it always compile ;)
> >
> > Any hints?
>
> This suggests you might have included Foo both from Foreman and also
> elsewhere in a manifest.
>
> The change in 1.1 that probably triggered it was enabling parameterised
> classes in the ENC output, so the YAML output changed very slightly
> from
> an array to a hash. You can disable this in More->Settings and set
> Parametrized_Classes_in_ENC to false. This means though that you can't
> use the new smart class parameters functionality.
>
> Maybe grep through your manifests and see if there's anywhere the class
> might be included in there too, as Puppet appears to be treating it
> as a
> duplicate declaration.
>
> --
> Dominic Cleal
> Red Hat Engineering
>
>
> Many thanks Dominic, setting Parametrized_Classes_in_ENC to false saved
> my day.
>
> Indeed we have some strange stuff in our config, like
>
> class rsync::server {
> include xinetd
> ...
> }
>
> And only rsync::server is included in the foreman hostgroup, while
> xinetd is still listed as available class.
> So I guess the best practice is to explicitely include in foreman all
> required classes and remove all includes from our manifests?
–
Dominic Cleal
Red Hat Engineering
