Issue #8236 has been updated by Luke Kanies.

File resource_harness_spec.patch added
File resource_harness_spec2.patch added
File resource_type_refactor_report.patch added

I've taken a crack at turning this prototype into real code, and it's a 
miserable failure.  Well, actually, three cracks.

In my opinion, it's impossible to make any reasonable changes to the 
ResourceHarness class without fixing the 1296 combinatorial tests - it's a huge 
chunk of code that builds and relies on state through the whole thing.  Here 
are some of the major problems:

* It uses 'file' as an example, which doesn't use providers, which means it 
*has* to be changed to make this refactor
* It actually creates and/or modifies a file in every test run, which means 
it's dog-slow (e.g., 15s on my macbook air)
* There are something like 6-10 separate tests being done in the code, but they 
can't be separated because there's too much state maintenance, and because then 
you'd have 6-10x the number of tests which would be even slower (something like 
150s instead of 15s - I tried)

I've attached a patch that makes it *better* (but not good) by drawing some of 
the state variables out into methods.  I've also attached a patch that splits 
into multiple tests and only fails about 1/6 of the tests.
----------------------------------------
Refactor #8236: Transaction resource harness should interact directly with 
provider
https://projects.puppetlabs.com/issues/8236

Author: Luke Kanies
Status: Code Insufficient
Priority: Normal
Assignee: 
Category: RAL
Target version: 
Affected Puppet version: 
Keywords: transaction provider
Branch: luke/prototype/master/8236-transaction_interface_with_providers


Currently, the transaction system (as implemented in the ResourceHarness) 
interacts with Puppet::Type instances, which then interact with provider.

It would make much more sense for the transaction system to just interact 
directly with providers - the Puppet::Type instances (and really, the 
Properties) would be simpler because the sync and retrieve methods could be 
removed and all knowledge of the provider other than where it is could be 
removed.

This would make the whole system much cleaner, and would allow the three 
subsystems - provider, transaction, and resources - to change much more 
independently of each other.


-- 
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.

Reply via email to