Issue #8433 has been updated by Justin Honold.
There is no current reason to use import, but there was a previous reason to use it. A top hit for 'scaling puppet' and 'git puppet' is http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control . I think I was given the link on the #puppet IRC channel less than a year ago as a suggestion for both scaling and (switching to) modular design. That is how a lot of our manifests were made, for a while: "import *" in init.pp, while still using a module structure. People that only read Pulling Strings with Puppet might also get the same idea. I'm all for progress, and justified deprecation. Even though I have a simple workaround for this on my own legacy manifests (the new ones are "fully" modular a la the current docs and Pro Puppet), the insider perspectives stated on this situation seriously concern me with regard to our own potential full-enterprise adoption. Syntax/API breakage, as opposed to warn-and-proceed, is something that I don't think should be taken at all lightly, and it's not clear to me from the contents of this ticket why phased deprecation isn't on the table. Right now you're dealing with those that were running old versions, did make old manifests, decided to upgrade, located this bug, and decided to participate. How many more do you think might be running old versions, have old manifests, and haven't upgraded because they're still using what their distro handed them? When THEY show up, it could be in droves, and I don't think the errors are sufficiently self-descriptive. I can speak only for myself, but I wasn't pleased when I found out that the syntax was unceremoniously broken, and potentially for "you should do it the right way" reasons, while "the right way" is rapidly evolving. Somewhat-related anecdote: we run hundreds of Ubuntu LTS servers, and got hammered by a 'feature' of dpkg. As it turns out, ext4 and btrfs systems performed slower than, say, ext3 with package operations. They modified it so that it issued a 'sync' call before doing an installation, which sped things up. Great, right? Well, sync is a whole-system sync, and there are folks out there, like us, with ultra-traffic NFS servers which can take up to an entire day to finish a sync process during live operation. The solution we're employing is backporting dpkg from a future version, which adds a scary-sounding "force-unsafe-io" option. Now we seriously question sticking with a platform that enacts changes which hard-break previously-standard behavior, and don't care enough to backport it themselves to the allegedly stable release. ---------------------------------------- Bug #8433: Seemingly random failures after 2.7.1 https://projects.puppetlabs.com/issues/8433 Author: Gustavo Soares Status: Needs More Information Priority: High Assignee: Nigel Kersten Category: modules Target version: Affected Puppet version: 2.7.1 Keywords: Branch: I've noticed a weird behaviour after trying puppet (gem) 2.7.1. I am planning an (huge) upgrade (from 0.25.x to 2.7.1) in all my puppet's boxes... I've installed puppet's 2.7.1 gem and got a lot of "Could not find class" problem... and everything worked just fine with 0.25.x. So, I decided to uninstall the gem for version 2.7.1 and install puppet version 2.6.9. Everything worked just fine... no weird "Could not find class" problem... Here are some more info about my environment: * I do not use parameterized classes and all my classes are "included" (I was still using 0.25.x...) * In my $confdir/manifests/classes/roles I have a very generic class for all puppet hosts declared as follow: <pre> class role_puppet_common { $role = "puppet_common" include common include puppet::common include puppet::user } </pre> in $confdir/manifests/site.pp I have the following line... <pre> [...] import "classes/roles/*" [...] </pre> the weird "Could not find class" problem occurs for class puppet::common my directory structure is as follow: <pre> ... $confdir/modules/puppet/ $confdir/modules/puppet/manifests $confdir/modules/puppet/manifests/init.pp $confdir/modules/puppet/manifests/classes/ $confdir/modules/puppet/manifests/classes/common.pp ... </pre> in $confdir/modules/puppet/manifests/init.pp I have: <pre> import "puppet/classes/*" </pre> and in $confdir/modules/puppet/manifests/classes/common.pp <pre> class puppet::common { ... } </pre> * my modulepath declared in puppet.conf is as follow: <pre> modulepath = /mnt/puppet/conf/modules:/mnt/puppet/othermodules </pre> where /mnt/puppet/conf is set to $confdir. That's it! As I said before, when I downgraded to version 2.6.9 everything worked fine. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
