Bug in Berkshelf, or Solve? Seems to be solve... #27
Comments
|
When it's printing the "debug" (ahem) message over and over, and I hit ^C, I see this stack trace: |
|
@jtimberman This does sound like it might be a solve bug, but I'll need to see the graph coming in to Solve to figure it out. I don't think that anybody has ever run Solve against a constraint graph with 200+ demands. That'll definitely slow it down (although the behavior you are describing seems weird) we have some debugging tools in Solve that we don't really expose anywhere.
serializer = Solve::Solver::Serializer.new
solver = Solve::Solver.new(graph, demands) # https://github.com/RiotGames/solve/blob/master/lib/solve.rb#L37
problem = serializer.serialize(solver)
puts problem
class StupidUI
def say(message)
puts message
end
endSolve.it!(graph, demands, { :ui => StupidUI.new }) |
|
@jtimberman any luck with getting the debug output that @andrewGarson requested? |
|
Haven't had a chance to do that yet :-/. Maybe tomorrow. |
|
I can confirm this behavior in our cookbook setup and am certain that solve is the issue here. The current resolver implementation has a worst case runtime behavior of |
|
I'm seeing similar issues with only 17 cookbooks. I updated to 3.0.0.beta4 to try and resolve a dependency version issue, but "berks install" never completes: I let that run for 2.5 days, I would have expected it to complete if it was just a O(n!) issue. Ruby did have one core at 100% for the duration of the run. Here is the 'berks install' output of 2.0.10 for comparison: I'm not familiar enough with Berkshelf to provide the debugging information andrewGarson requested above at this time. Please also let me know if this should be reported against berkshelf/berkshelf#959. Thanks. |
|
I am also running into this infinite loop issue with version 3.0.0.beta4. I was able to run the debugging commands above (specifically the second one with a File output UI) and got these (truncated to 500K) results. The output kept looping over and over around the "Could not find an acceptable value for virtualenvwrapper" and subsequent re-attempt at "Resetting possible values for virtualenvwrapper" event. The same thing appears to be happening with 'openssl' as well, though as far as I know the 'virutalenvwrapper' and 'openssl' cookbooks are not dependent on each other in any way. Here is the main Berksfile that the troubled Inside the 'fpn_app' cookbook, there is another Berksfile which looks like this: The metadata.rb file for that cookbook is thus: It doesn't seem to work with the original virutalenvwrapper repository commented out in the application cookbook's Berksfile or with my bugfix fork. I have tried fixing the version on that dependency but no luck. I'm sure I've got something wrong here as I'm just learning chef/berkshelf, so perhaps somebody knows a workaround until this bug can be fixed? |
|
@keitwb could you send me the entire output by any chance? How long did you let it run before you killed it? Depending on the size of the graph not finding a solution could take a very very long time (weeks). |
|
Full output is here on Dropbox (just shy of 1 million lines). It probably ran for several minutes, I don't think any more than 10 minutes or so. I can't tell for sure but it looks like the output just started repeating the same thing over and over against after the first couple thousand lines of output. |
|
So I'm also getting the same problem here. I've got a bunch of git repos in my Berksfile. Taking a look at the output from @keitwb it's resetting the possible values for the cookbooks over and over, so it never resolves them. Is there anything I can do to help diagnose this bug? |
|
@damacus the bug has already been well identified. The only work left now is to re-write the graph solver in Solve or a cross compatible set of FFI/C bindings for Gecode. |
|
Is there a final tracking issue for this? Subscribing. |
|
@nicholasserra we are still working on it/ |
|
Looks like I have the same bug. Berkshelf 3.0.beta7 starts to eat 100% of CPU and gets into an infinite loop My environmentConfiguration filesBerksfilemetadata.rbIt has a few cookbook to resolve from our internal Chef server Backtrace
So it fails on Pressing Ctrl+C gives the following output: |
|
@iroller yup. Definitely looks like the bug. We need to fix solve and that's not an easy task. There are also talks of moving to gecode. |
Having this dependency may cause an infinite loop in Berkshelf dependency resolution mentioned here berkshelf/solve#27 This is not the main cause and there is still a bug in berkshelf/cause, but I see no reason of keeping it here.
|
Fixed mine by removing an extra dependency from metadata (sous-chefs/users#47). Tried to make a reproducible test case but no luck, only fails when it has a bunch of other internal dependencies, sorry. |
|
this. |
|
@ampledata yes? |
|
Hah, sorry, this is what I'm currently battling myself. I'm seeing the same behavior outlined above, e.g. infinite loop on dep resolution or and/or unresolvable deps on fixture cookbooks. A work-around I've just tried (and seems to hold) is to specify all deps in my main infrastructure Berksfile. This leads to a lot of duplication, but it works. To Reproduce:Create cookbooks: A & B & Infrastructure Code Berksfile:A Cookbook:
B Cookbook:
Infrastructure Code:
Run:
|
|
@ampledata okay - you were just adding that this affects you as well? |
|
So i understand the workaround but is there any way to know which of the dependancies in the tree is causing the problem? |
|
@mansona manually - yes. Automated - working on it. |
|
any pointers for me? the last output for me before it goes nuts is so that makes me think that the problem is apt... and i'm a bit lost as to what i should do next... |
|
@mansona can u post your entire dependency tree? do you have any cookbooks that are importing a non community version of apt? |
|
is there a good way to do that? get the dependancy tree i mean... or is it just manually going through all metadata.rb files in cookbooks and keeping note of the versions? |
|
We have recently merged #33, which switches to gecode for dependency resolution. While we have not released a new version, this merge closes this issue. |
|
so it's in master but if i do a bundle install it wont bring down this fixed version right? sorry i'm not a ruby guy 😉 where can i "follow" to be notified of a release? |
|
@mansona if you "watch" this project on GitHub, you'll get a notification when we cut a new tag (which will correspond to a new release). You can also subscribe to the RSS feed for the gem: https://rubygems.org/gems/solve. |
|
awesome! thanks guys! just checked ruby gems there now and it looks like you released a version of berkshelf and solve 19 hours ago https://cloudup.com/cBylaGAtBVi i'm assuming these should have the fix? |
|
@mansona yes, the latest beta release (9) of Berkshelf should solve this completely |
|
Hmm... well i'm still having some problems but it's unrelated to this issue (I think) I asked the question on Stack Overflow because I thought it sounded more like an issue with my setup, although any help would be much appreciated http://stackoverflow.com/questions/22930511/symbol-not-found-when-using-ruby-gem-berkshelf |
|
@mansona the issue you're seeing is because you're using Gecode 4 and not Gecode 3. You can uninstall Gecode 4 and install 3 or wait a few days and there'll be a much easier way for us to get you Gecode. |
|
Yea i guess if you're in the middle of moving a few things around then I should just wait. I managed to install an older version of gecode using help from this SO question but now i'm stuck when i'm trying to use test kitchen because it needs Should we create a new bug that keep track of these dependancy problems or will i just wait for confirmation here? |
|
@mansona you should actually open a ticket with dep-selector-libgecode for that issue. That doesn't look good. |
|
👍 Glad this is resolved, the change to gecode is delightful. |
|
@mansona good to hear. What dependency issue was chef-dk not able to solve? |
|
@reset chef-boneyard/chef-dk#15 open issue to make it plain sailing for anyone else ;) i'm personally all set now |
I'm not sure how to report this bug. It appears to be coming from solve, even though I encounter it with Berkshelf (v3.0.0.beta2). Here's the scenario.
I am working with a large number of cookbooks in an existing
chef-repo. Most of them are private, and for number of reasons are not in separate repositories nor released on the community site. I want to use the:pathdirective for each cookbook for my Berksfile:We have over 200 cookbooks in the directory. I shortcut this with the following in my Berksfile:
When I run
berks install, it gets tobuilding universeand then hits an infinite loop. As near as I can tell, through judicious use ofputsin the solve library, it hits this code path:And variable.value is nil for every cookbook. I put the following line above the if statement:
I see this output:
#<Solve::Solver::VariableRow:0x007f824c97b000 @artifact="opscode-base", @value=nil, @sources=[:root]>I'm not sure where else to debug this, or how to get more appropriate information. It appears that this is a solve bug, not a berkshelf bug, so I am reporting it here. However, perhaps this is a berkshelf bug, since it should know about its world because I have all these cookbooks locally (and said so, in the Berksfile).
The text was updated successfully, but these errors were encountered: