Sean,
From an initial test, the most naive one I've got, is this:
Berksfile:
cookbook 'yum', github: 'opscode-cookbooks/yum', branch: 'tableflip' # Test out yum 3.x branch
Cookbook:
yum_repository "datadog" do
name "datadog"
description "datadog"
action :add
end
Fails due to the 'url' resource param being missing, apparently this has been renamed to 'baseurl', and the action :add is gone, is now :create.
- Is there a way to create aliases for LWRP parameters, so that we could possibly have an `alias :baseurl :url`, `alias :action_add :action_create` and such, so we could maintain some more backwards compatibility?
Parameter aliasing is used in some base resources:
Here's an example of aliasing in a provider, where `action_create` is now also `action_run` for the ruby_block resource:
I don't know if LWRPs will provide the same amount of functionality, someone more deep inside LWRPs should probably answer that.
At least for one more Major version, with deprecation warnings, if at all possible.
- It appears gpgcheck default switched from false to true - any reason to not keep that false, and have the conditional swap based on providing a gpgkey param? This was the previous behavior, as if I don't pass a gpgkey explicitly, I'd get the default of no gpgcheck.
In general this looks pretty awesome, includes a bunch of new tests, code quality, what have you.
My biggest question is:
- Considering that the driving factor for most cookbook changes is handled within the context of a Ticket, which is then reviewed, discussed, etc - is there one associated with this change, that discusses the motivation, the need, etc?
The reason I'm delving deep into this one is because it's a fundamental building block for anyone using/deploying software, and has a lot of potential for unexpected Bad Stuff, and getting my cookbook updated to constrain on a prior version of this cookbook, and then getting that change out to every user of my cookbook might be a little time-constrained
Thanks for playing,
-Mike
PS: I'd note that the current branch's repo still uses version string 2.4.3 - Another use case for Semantic Versioning identifiers to allow this to be 3.0.0.dev or such, but that's already a whole other bag of marbles.