headers
Brice Figureau | 1 May 2009 12:57
Favicon
Gravatar

Re: puppet with JRuby?


On 30/04/09 23:16, Nigel Kersten wrote:
> So I seem to have followed Brice down a path here as I got to exactly
> the same point he did:
> 
> http://jira.codehaus.org/browse/JRUBY-3349
> 
> Just wondering if anyone has gotten any further with this?

I'm surprised by how JRuby devs never got interested by this bug.
Last time I checked, nobody has even read the report.
--

-- 
Brice Figureau
http://www.masterzen.fr/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppet-dev <at> googlegroups.com
To unsubscribe from this group, send email to puppet-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 12 comments |
headers
Brice Figureau | 1 May 2009 13:00
Favicon
Gravatar

Re: Lots of tests are failing


On 30/04/09 23:10, Luke Kanies wrote:
> On Apr 30, 2009, at 10:43 AM, Brice Figureau wrote:
> 
>> On Thu, 2009-04-30 at 10:19 +0200, Stéphan Gorget wrote:
>>> I installed ruby 1.8.6 with the same gems and still have a lot of  
>>> errors
>>> (around 54).
>> Yes, I managed to reproduce the failing tests, and also I've fixed  
>> some
>> of them (I'll send the patch later this week).
>>
>> As Luke said earlier, it comes from
>> inter-dependencies/ordering/interaction of tests.
>> Basically all the test/language/snippets tests are failing because
>> they're trying to use active_record which is initialized by the
>> collection tests in test/language/parser.
>>
>> I could fix those by "proctecting" the various new indirector
>> active_record save/find call with some "return unless
>> Puppet[:storeconfigs]", but I don't think it is the proper way to fix
>> those (in fact it seems that what puppet wants to do is to use caching
>> on active_record which somewhat seems to be the default).
>>
>> I'm going to try harder to isolate the cause, but IMHO it seems that  
>> the
>> asynchronous_storeconfig patchs produced those regressions.
> 
> There's probably a test that sets storeconfigs = true, which then sets  
> up everything to use ActiveRecord, and the test should unset these but
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brice Figureau | 1 May 2009 13:33
Favicon
Gravatar

[PATCH 1/4] Fix some master failing tests


Signed-off-by: Brice Figureau <brice-puppet <at> daysofwonder.com>
---
 test/language/scope.rb       |    2 +-
 test/rails/railsparameter.rb |    2 +-
 test/ral/type/file.rb        |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/test/language/scope.rb b/test/language/scope.rb
index eeaf179..77af950 100755
--- a/test/language/scope.rb
+++ b/test/language/scope.rb
 <at>  <at>  -404,7 +404,7  <at>  <at>  class TestScope < Test::Unit::TestCase
         end
     end

-    if defined? ActiveRecord
+    if defined? ::ActiveRecord
     # Verify that we can both store and collect an object in the same
     # run, whether it's in the same scope as a collection or a different
     # scope.
diff --git a/test/rails/railsparameter.rb b/test/rails/railsparameter.rb
index 7c99ac3..aaa88e5 100755
--- a/test/rails/railsparameter.rb
+++ b/test/rails/railsparameter.rb
 <at>  <at>  -8,7 +8,7  <at>  <at>  require 'puppettest'
 require 'puppettest/railstesting'

 # Don't do any tests w/out this class
-if defined? ActiveRecord::Base
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brice Figureau | 1 May 2009 13:33
Favicon
Gravatar

[PATCH 0/4] Fix #2216 - fix all master failing tests


Since the last stream of patches coming in master, some tests are now failing.
This bunch of patches fixes them (except the daemontools ones which are taken
care by Bryan Allen).

Note: all the snippets tests were failing because scope.rb and parser.rb tests
were activating storeconfigs, which since the last refactoring changes some
internal terminii to their active_record counterpart.
Since setting storeconfigs=false doesn't reset them to sane defaults, I hacked the
tests themselves to do it. 
Maybe the correct fix could be:
 * to change storeconfigs default's hook to reset those terminii to correct values
when set to false.

 * make sure tests set storeconfigs=false afterward.

 * make sure storeconfig is true and rails exists in the various active_record
terminii. 

Code available in tickets/master/2216 in my github repository:
http://github.com/masterzen/puppet/tree/tickets/master/2216

Please review and comment,
Thanks,

Brice Figureau (4):
  Fix some master failing tests
  Confine stomp tests to Stomp enabled systems
  Fix failing test: file.close! and file.path ordering fix
  Fix snippets tests failing because of activated storeconfigs
(Continue reading)

Permalink | Reply | 3 comments |
headers
Brice Figureau | 1 May 2009 13:33
Favicon
Gravatar

[PATCH 3/4] Fix failing test: file.close! and file.path ordering fix


On ruby 1.8.7 file.close! nils the internal file path.
So the following pattern:
file = temp
file.close!
file = file.path
doesn't work.

Signed-off-by: Brice Figureau <brice-puppet <at> daysofwonder.com>
---
 spec/integration/util/file_locking.rb |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/spec/integration/util/file_locking.rb b/spec/integration/util/file_locking.rb
index 680b3d1..e584f9e 100755
--- a/spec/integration/util/file_locking.rb
+++ b/spec/integration/util/file_locking.rb
 <at>  <at>  -7,8 +7,9  <at>  <at>  require 'puppet/util/file_locking'
 describe Puppet::Util::FileLocking do
     it "should be able to keep file corruption from happening when there are multiple writers" do
         file = Tempfile.new("puppetspec")
+        filepath = file.path
         file.close!()
-        file = file.path
+        file = filepath
         data = {:a => :b, :c => "A string", :d => "another string", :e => %w{an array of strings}}
         File.open(file, "w") { |f| f.puts YAML.dump(data) }

--

-- 
1.6.0.2
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brice Figureau | 1 May 2009 13:33
Favicon
Gravatar

[PATCH 2/4] Confine stomp tests to Stomp enabled systems


Signed-off-by: Brice Figureau <brice-puppet <at> daysofwonder.com>
---
 spec/unit/util/queue/stomp.rb |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/spec/unit/util/queue/stomp.rb b/spec/unit/util/queue/stomp.rb
index c4d8b76..b0b86e4 100755
--- a/spec/unit/util/queue/stomp.rb
+++ b/spec/unit/util/queue/stomp.rb
 <at>  <at>  -4,6 +4,8  <at>  <at>  require File.dirname(__FILE__) + '/../../../spec_helper'
 require 'puppet/util/queue'

 describe Puppet::Util::Queue do
+    confine "Missing Stomp" => Puppet.features.stomp?
+
     it 'should load :stomp client appropriately' do
         Puppet.settings.stubs(:value).returns 'faux_queue_source'
         Puppet::Util::Queue.queue_type_to_class(:stomp).name.should == 'Puppet::Util::Queue::Stomp'
 <at>  <at>  -11,6 +13,8  <at>  <at>  describe Puppet::Util::Queue do
 end

 describe 'Puppet::Util::Queue::Stomp' do
+    confine "Missing Stomp" => Puppet.features.stomp?
+
     before :all do
         class Stomp::Client
             include Mocha::Standalone
--

-- 
1.6.0.2
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brice Figureau | 1 May 2009 13:33
Favicon
Gravatar

[PATCH 4/4] Fix snippets tests failing because of activated storeconfigs


All the snippets tests were failing because some parser and scope
tests activated storeconfigs without reseting the state.
Activating storeconfigs is not undoable at the moment by just
setting storeconfig=false as some terminus are changed.

Signed-off-by: Brice Figureau <brice-puppet <at> daysofwonder.com>
---
 test/language/parser.rb |   18 ++++++++++++++++++
 test/language/scope.rb  |    7 +++++++
 2 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/test/language/parser.rb b/test/language/parser.rb
index 30baea4..7794c42 100755
--- a/test/language/parser.rb
+++ b/test/language/parser.rb
 <at>  <at>  -444,6 +444,9  <at>  <at>  file { "/tmp/yayness":
     def test_virtualresources
         tests = [:virtual]
         if Puppet.features.rails?
+            catalog_cache_class = Puppet::Resource::Catalog.indirection.cache_class
+            facts_cache_class = Puppet::Node::Facts.indirection.cache_class
+            node_cache_class = Puppet::Node.indirection.cache_class
             Puppet[:storeconfigs] = true
             tests << :exported
         end
 <at>  <at>  -496,11 +499,20  <at>  <at>  file { "/tmp/yayness":
                 check.call(res, "multiresource")
             end
         end
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christian Hofstaedtler | 1 May 2009 14:48
Picon
Gravatar

Re: [PATCH 1/3] Puppet as a Rack application


Hi Brice,

* Brice Figureau <brice-puppet <at> daysofwonder.com> [090428 22:38]:
> A few minor comments inline.
>
> Is it against latest master?
> I'm asking the question because since #1875 has been merged I think some  
> of your rack/rest test might not pass because of the call to  
> check_authorization. I'll check later.
>
> On 28/04/09 15:41, Christian Hofstaedtler wrote:
>> From: Christian Hofstaedtler <hofstaedtler <at> inqnet.at>
>>
>> This lays the ground: a wrapper for the REST handler, and an application
>> confirming to the Rack standard. Also includes a base class for Rack
>> handlers, as RackREST will not stay the only one, and there needs to be
>> a central place where client authentication data can be checked.
>>
>> Signed-off-by: Christian Hofstaedtler <hofstaedtler <at> inqnet.at>
>> ---
>>  lib/puppet/feature/base.rb                  |    3 +
>>  lib/puppet/network/http/rack.rb             |   62 +++++++++
>>  lib/puppet/network/http/rack/httphandler.rb |   35 +++++
>>  lib/puppet/network/http/rack/rest.rb        |   75 +++++++++++
>>  spec/unit/network/http/rack.rb              |  102 ++++++++++++++
>>  spec/unit/network/http/rack/rest.rb         |  193 +++++++++++++++++++++++++++
>>  6 files changed, 470 insertions(+), 0 deletions(-)
>>  create mode 100644 lib/puppet/network/http/rack.rb
>>  create mode 100644 lib/puppet/network/http/rack/httphandler.rb
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luke Kanies | 1 May 2009 14:59
Gravatar

Re: puppet with JRuby?


On May 1, 2009, at 12:57 PM, Brice Figureau wrote:

>
> On 30/04/09 23:16, Nigel Kersten wrote:
>> So I seem to have followed Brice down a path here as I got to exactly
>> the same point he did:
>>
>> http://jira.codehaus.org/browse/JRUBY-3349
>>
>> Just wondering if anyone has gotten any further with this?
>
> I'm surprised by how JRuby devs never got interested by this bug.
> Last time I checked, nobody has even read the report.

I concur.  I've pinged Charles Nutter on Twitter, but I can't imagine  
it will do much.

Did you try any of the workarounds?

--

-- 
My favorite was a professor at a University I Used To Be Associated
With who claimed that our requirement of a non-alphabetic character in
our passwords was an abridgement of his freedom of speech.
     -- Jacob Haller
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Luke Kanies | 1 May 2009 15:03
Gravatar

Re: [PATCH 0/4] Fix #2216 - fix all master failing tests


On May 1, 2009, at 1:33 PM, Brice Figureau wrote:

>
> Since the last stream of patches coming in master, some tests are  
> now failing.
> This bunch of patches fixes them (except the daemontools ones which  
> are taken
> care by Bryan Allen).
>
> Note: all the snippets tests were failing because scope.rb and  
> parser.rb tests
> were activating storeconfigs, which since the last refactoring  
> changes some
> internal terminii to their active_record counterpart.
> Since setting storeconfigs=false doesn't reset them to sane  
> defaults, I hacked the
> tests themselves to do it.
> Maybe the correct fix could be:
> * to change storeconfigs default's hook to reset those terminii to  
> correct values
> when set to false.

This would require modifying the Settings class - we can currently  
force a setting's hook to get triggered when the setting is set, but  
we can't force it to get triggered when the Settings instance is  
cleared.  Most likely, the Settings class should trigger any hooks  
marked 'call_on_define' when the Settings instance is cleared, as this  
is effectively defining the value.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane