Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Break ability of berkshelf to resolve circular cookbook dependencies #1845

Open
lamont-granquist opened this issue Jul 30, 2020 · 1 comment

Comments

@lamont-granquist
Copy link
Contributor

The next major release of Berkshelf should break the ability of berkshelf to resolve circular dependencies when using the gecode solver. Molinillo will never support circular dependencies, nor should it. This creates a blocker to people who have circular dependencies to stay on Berkshelf, using only gecode, which is a system that we more or less no longer actively support, and blocks migrations to PolicyFiles, and some community cookbooks which have circular deps work on Berks but fail on PolicyFiles.

Circular dependencies also cause performance issues, particularly with the way that circular deps don't just create single circular deps but with N versions of cookbook A that depend on M versions of cookbook B on the server there will be NxM circular deps that the solver needs to deal with. As you add more cookbook and their versions into the mix the cartesian product of all the cookbook versions quickly explodes. Our gecode implementation is optimized for checking the lastest of all versions and in the absence of constraints this is fast. However, when you start mixing in cookbooks that have e.g. 1.x and 2.x versions and some cookbooks are
pinning with semver style pins instead of floating on latest the problem will scale badly. This problem gets even worse when it comes to the error renderer in our gecode implementation that is written in ruby.

The solution is that circular deps need to end. Cookbooks with circular deps either need to be merged into one cookbook (because there's actually only one concern) or else they need a third fascade cookbook created which deps on both of them and extracts the cross-cookbook bits from at least one of the cookbooks up a level (or some other appropriate design pattern).

This is one example of a person being pushed away from PolicyFiles and selecting the wrong answer (Berkshelf) because of circular dependencies:

https://stackoverflow.com/questions/62439333/is-it-possible-to-use-both-berksfile-and-policyfile-at-the-same-time-in-a-chef-c?noredirect=1#comment111606366_62439333

That is basically what we do not want new people ever doing.

@lamont-granquist
Copy link
Contributor Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant