I think the way I posted the contents of the modules may have been
misleading, as I do actually have each class in it's own file so
kvm::host class has it's own host.pp file.  So far I've actually
noticed this problem only on my modules that make use of the
autoloading, so each class in it's own *.pp file.  Not all my modules
suffer from this, but that's one common thing among the ones that do
fail.  I'm in the process of moving my other modules to that layout as
they currently have all classes in init.pp, but interestingly enough
none of those modules have had random failures.

- Trey


On Jul 13, 1:29 am, Peter Meier <peter.me...@immerda.ch> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > Is using an empty class in init.pp problematic ?  All of these modules
> > worked just fine before going from 2.6.8 to 2.7.1.
>
> I have no idea, whether this is the problem. But why do you do:
>
> > # manifests/init.pp
> > import "classes/*.pp"
>
> > class kvm {
> > }
>
> > # manifests/classes/host.pp
> > class kvm::host {
>
> ?
>
> Why not just have one file manifests/host.pp that contains the kvm::host
> class? Everything else is not really necessary.
>
> Puppet has quite a powerfull autoloading feature of classes and I think
> it can be seen as a general best practice to have one class in a file in
> its corresponding path on the filesystem.
>
> With your current way you would need a global import kvm, so that the
> init.pp class is actually parsed, so that the files in classes/ are
> imported.
> If this is not the case and the kvm::host class is not in a file that
> can be found by the autoloader it won't find the class.
>
> This becomes even trickier as other hosts can now interfere which
> classes are available while compiling the next hosts classes, as an
> import statement might only have been executed if Host A is compiled and
> only this would then make these "imported" classes that Host B requires
> available.
>
> Actually, I remember that the autoloader should also look into init.pp
> for the kvm::host class. But it's possible that something like that
> might have changed in 2.7. But I don't know it.
>
> Due to these two reasones (magic availability of classes, possible
> changes in how classes become available in 2.7) I would generally
> recommend to *not* use import statements and instead use puppet's
> autoloading feature. They're rather hard to debug.
>
> ~pete
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk4dOygACgkQbwltcAfKi39akACcCwslVzxzrTy3/H0r7kGyi4dB
> M4gAn1LHtc/LGk7OtbVfDolhm5cXwm/p
> =lWHm
> -----END PGP SIGNATURE-----

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

Reply via email to