Issue #2511 has been updated by Markus Roberts.
Status changed from Accepted to Needs design decision
I've played around with these options a little, with the following results:
> * Instead of an :overwrite => true/false option to the genclass --> genthing
> path, have some sort of find_or_create option that returns the existing
> Class/Module if it's already loaded (but doesn't run the block).
This is very easy to implement but would be a possibly significant behavior
change, in that modified types would be ignored.
<pre>
def genthing(name, type, options, block)
options = symbolize_options(options)
name = symbolize(name.to_s.downcase)
+ const = genconst_string(name, options)
+ return const_get(const) if const_defined? const
</pre>
> * Some sort of patchup/unification process to make the reloading less
> traumatic (e.g. more like the way ruby behaves) via getting rid of the
> remove_const on conflict.
This is also fairly easy to implement but also results in a behavior change:
rather than objecting to duplicate parameters as it does now it would subsume
("reopen") them.
<pre>
def genthing(name, type, options, block)
options = symbolize_options(options)
name = symbolize(name.to_s.downcase)
+ const = genconst_string(name, options)
+ if const_defined? const
+ evalmethod = :class_eval
+ klass = const_get(const)
+ elsif type == Module
- if type == Module
</pre>
> * Adding something smarter (but hopefully short of full AI) to the load
> process so that it doesn't try to load things twice (though note that my test
> rig does it all with Kernel.require).
If it weren't for the library path issues, something as simple as this would do
it.
<pre>
module Kernel
unless respond_to? :require_mqr
alias require_mqr require
def require(f)
require_mqr File.expand_path(f)
end
end
end
</pre>
* Trying to track down the code path that Sam Rowe hit that caused it to
multiply load in the running app, fixing that, and hoping to heck that it was a
unique flower, once plucked n'er to bloom again.
No joy so far. And even if I do find it the "hoping like heck" doesn't appeal.
--Markus
----------------------------------------
Bug #2511: Sporadic and spurious "invalid parameter" errors
http://projects.reductivelabs.com/issues/2511
Author: Markus Roberts
Status: Needs design decision
Priority: High
Assigned to: Markus Roberts
Category: unknown
Target version: 0.25.0
Complexity: Unknown
Affected version: 0.25.0rc1
Keywords:
Under certain orderings large numbers (>100) of tests will fail with messages
similar to this:
<pre>
44)
Puppet::Error in 'Puppet::Resource::Catalog when compiling when creating a
relationship graph should not write graph files if the catalog is not a host
cata
log'
Invalid parameter source(:source)
./lib/puppet/util/errors.rb:51:in `fail'
./lib/puppet/type.rb:418:in `[]'
./spec/../lib/puppet/type/file.rb:278:in `validate'
./lib/puppet/type.rb:1908:in `initialize'
./spec/../lib/puppet/type/file.rb:400:in `initialize'
./spec/unit/resource/catalog.rb:713:in `new'
./spec/unit/resource/catalog.rb:713:
./spec/monkey_patches/add_confine_and_runnable_to_rspec_dsl.rb:22:in `run'
./spec/monkey_patches/add_confine_and_runnable_to_rspec_dsl.rb:17:in `each'
./spec/monkey_patches/add_confine_and_runnable_to_rspec_dsl.rb:17:in `run'
</pre>
The common factor in each case being the "Invalid parameter" messages and the
first five lines of the stack trace.
That this is order dependent has been confirmed by making the problem appear on
a fresh, unmodified copy of 0.25.0rc1 by simply touching spec files to force
test execution error and then making the problem go away by touching one of the
spec files again to force a different ordering.
--
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://reductivelabs.com/redmine/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
-~----------~----~----~----~------~----~------~--~---
