[chef] Re: Re: Re: Depending on yum '< 3'

[Sean OMeara < >]

Hi Mike.

Indeed, yum is a fundamental building block. That is why it's important to be as solid as possible. The rewrite is part of COOKs focus on well engineered primitives.

We also need some easy-to-point-to "example cookbooks" we can point to and say "write your cookbook like that". In general, people tend to copy patterns they see, especially newcomers.

I've added aliases for :create :add :remove, and :delete, as well as baseurl/url and gpgkey/keyurl. That should help smooth the transition.

If you can help me test this, it would be amazing. 

Thanks!

-s

On Sat, Dec 7, 2013 at 9:48 AM, Mike < " target="_blank"> > wrote:

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"

    url "http://yum.datadoghq.com/rpm"

    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:

Ref: https://github.com/opscode/chef/blob/master/lib/chef/resource/git.rb#L40-L43

https://github.com/opscode/chef/blob/10-stable/chef/lib/chef/resource/git.rb#L40-L43

Here's an example of aliasing in a provider, where `action_create` is now also `action_run` for the ruby_block resource:

https://github.com/opscode/chef/blob/10-stable/chef/lib/chef/provider/ruby_block.rb#L31

https://github.com/opscode/chef/blob/master/lib/chef/provider/ruby_block.rb#L38

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.

On Sat, Dec 7, 2013 at 8:27 AM, Mike < " target="_blank"> > wrote:

Looks like the branch is here: https://github.com/opscode-cookbooks/yum/tree/tableflip

On Sat, Dec 7, 2013 at 8:07 AM, Wolfe, Eric G < " target="_blank"> > wrote:

Got a branch we can review before the release?

Sean OMeara < " target="_blank"> > wrote:



Dear Chef People:

In one week, I will be releasing a new yum cookbook to the community site that will Break All The Things. If you depend on yum, please lock to '< 3' in your metadata.rb to avoid trouble.

Thanks.
-s
—

Sent from Mailbox<https://www.dropbox.com/mailbox> for iPhone