Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
use lvm >= instead of locking it. #62
Cookbooks are built with a purpose, even with breaking changes the end result of the cookbook should still be the same. They may have changed how they get to the end result. If the changes do happen to break this cookbooks functionality then it makes sense to pin it to the last working version till this cookbook can be updated to fix the issue. You especially shouldn't have to do releases to support the latest lvm cookbook when they simply increment the minor version number due to a new feature release that doesn't affect any existing functionality.
Here's examples of dependancies from several cookbooks owned by chef themselves where they are only using >=:
I know this is kind of a long post and I'm not totally sure how the sound of it comes off. Please do not take it as me being combative or aggressive. I'm just laying out my thoughts and what I've seen that seems to be best practice from most community cookbooks in hopes to change your mind on the >= being too loose. I've had this debate on a couple of other popular cookbooks and after they have made the change they haven't had any issues with their dependancies updates. This is a great cookbook and with most of our infrastructure in AWS we rely heavily on this cookbook in one of our base cookbooks so when we do run into issues with this cookbook and the restrictive lvm dependency setting quite a few of our linux chef-clients start failing to converge until it is fixed and pushed out to the community supermarket.
added a commit
Jan 11, 2017
Here's the output block from the chef-client run while knifing a new server on AWS.
172.21.16.119 Recipe: lvm::default