Depending on yum '< 3'

Chef Infra (archive)
1

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 for iPhone

2

Got a branch we can review before the release?

Sean OMeara someara@opscode.com 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 Mailboxhttps://www.dropbox.com/mailbox for iPhone

3

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 eric.wolfe@marshall.eduwrote:

Got a branch we can review before the release?

Sean OMeara someara@opscode.com 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 Mailboxhttps://www.dropbox.com/mailbox for iPhone

4

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

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.

On Sat, Dec 7, 2013 at 8:27 AM, Mike miketheman@gmail.com 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 eric.wolfe@marshall.eduwrote:

Got a branch we can review before the release?

Sean OMeara someara@opscode.com 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 Mailboxhttps://www.dropbox.com/mailbox for iPhone

5

This is like totally my opinion, and you're probably going to do what
you want...

But I don't see any way to configure the main /etc/yum.conf in the
proposed change. This was provided by the yum::yum recipe previously,
and does not relate to the myriad of yum_repository recipes that had
been gathered over time making use of the cookbook library. If it were
me, I would expect the yum cookbook to configure yum, not just the
repositories. Just my two cents.

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email:eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 12/07/2013 12:26 AM, Sean OMeara 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

6

On 12/7/2013 12:26 AM, Sean OMeara 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.

We're all Professional DevOps Engineers(tm). NONE of us would fetch
and deploy versions of any cookbook without testing it extensively
first, so this breakage warning is unnecessary.

Ahem.

PS: Fixes broken "Add" functionality of replace_or_add by jblaine · Pull Request #13 · sous-chefs/line · GitHub :slight_smile:

xoxo
Jeff

7

Don’t be so fatalistic!
I started this thread for a reason. =)
Good point about global configuration… I’ll add a recipe that lets you configure all the things.
-s
On December 7, 2013 at 10:27:16 AM, Eric G. Wolfe (eric.wolfe@marshall.edu) wrote:

This is like totally my opinion, and you’re probably going to do what you want…

8

You can probably revert that one use case with the yum::yum recipe, and
a few of the attributes from attributes/default. Two templates are
probably not necessary, for each RHEL major version, and that part could
be refactored for the 3.0 relase. I can probably assist if you need a
guinea pig.

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems

Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: eric.wolfe@marshall.edu

You will be recognized and honored as a community leader.

On 12/07/2013 04:41 PM, Sean OMeara wrote:

Don't be so fatalistic!
I started this thread for a reason. =)
Good point about global configuration… I'll add a recipe that lets you
configure all the things.
-s

On December 7, 2013 at 10:27:16 AM, Eric G. Wolfe
(eric.wolfe@marshall.edu mailto://eric.wolfe@marshall.edu) wrote:

This is like totally my opinion, and you're probably going to do what
you want...

9

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 miketheman@gmail.com 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 miketheman@gmail.com 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 eric.wolfe@marshall.eduwrote:

Got a branch we can review before the release?

Sean OMeara someara@opscode.com 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 Mailboxhttps://www.dropbox.com/mailbox for iPhone

10

I get this error when I try to use any of the cookbooks updated to include:

depends 'yum', '<3'

   [2013-12-12T08:40:37+00:00] ERROR: '3' does not match 'x.y.z' or 'x.y'

If I change this lines to:

depends 'yum', '<3.0'

cookbook works without issues

I'm using Chef 11.8.2-1.ubuntu.12.04, installed from Omnibus.

Nobody have same issue?

2013/12/9 Sean OMeara someara@opscode.com:

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 miketheman@gmail.com 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 miketheman@gmail.com 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 eric.wolfe@marshall.edu
wrote:

Got a branch we can review before the release?

Sean OMeara someara@opscode.com 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 Mailboxhttps://www.dropbox.com/mailbox for iPhone

11

Sorry about that hitch.... I updated everything to include '< 3.0' to
satisfy the x.y format

On Thu, Dec 12, 2013 at 3:45 AM, Jorge Bianquetti jbianquetti@gmail.comwrote:

I get this error when I try to use any of the cookbooks updated to include:

depends 'yum', '<3'

   [2013-12-12T08:40:37+00:00] ERROR: '3' does not match 'x.y.z' or

'x.y'

If I change this lines to:

depends 'yum', '<3.0'

cookbook works without issues

I'm using Chef 11.8.2-1.ubuntu.12.04, installed from Omnibus.

Nobody have same issue?

2013/12/9 Sean OMeara someara@opscode.com:

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 miketheman@gmail.com 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 miketheman@gmail.com 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 <eric.wolfe@marshall.edu

wrote:

Got a branch we can review before the release?

Sean OMeara someara@opscode.com 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 Mailboxhttps://www.dropbox.com/mailbox for iPhone

12

knife cookbook site show still shows affected versions.

Thanks!

2013/12/12 Sean OMeara someara@opscode.com:

Sorry about that hitch.... I updated everything to include '< 3.0' to
satisfy the x.y format

On Thu, Dec 12, 2013 at 3:45 AM, Jorge Bianquetti jbianquetti@gmail.com
wrote:

I get this error when I try to use any of the cookbooks updated to
include:

depends 'yum', '<3'

   [2013-12-12T08:40:37+00:00] ERROR: '3' does not match 'x.y.z' or

'x.y'

If I change this lines to:

depends 'yum', '<3.0'

cookbook works without issues

I'm using Chef 11.8.2-1.ubuntu.12.04, installed from Omnibus.

Nobody have same issue?

2013/12/9 Sean OMeara someara@opscode.com:

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 miketheman@gmail.com 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 miketheman@gmail.com 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
eric.wolfe@marshall.edu
wrote:

Got a branch we can review before the release?

Sean OMeara someara@opscode.com 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 Mailboxhttps://www.dropbox.com/mailbox for iPhone

13

for which cookbook(s)?
-s

On Thu, Dec 12, 2013 at 11:53 AM, Jorge Bianquetti jbianquetti@gmail.comwrote:

knife cookbook site show still shows affected versions.

Thanks!

2013/12/12 Sean OMeara someara@opscode.com:

Sorry about that hitch.... I updated everything to include '< 3.0' to
satisfy the x.y format

On Thu, Dec 12, 2013 at 3:45 AM, Jorge Bianquetti <jbianquetti@gmail.com

wrote:

I get this error when I try to use any of the cookbooks updated to
include:

depends 'yum', '<3'

   [2013-12-12T08:40:37+00:00] ERROR: '3' does not match 'x.y.z' or

'x.y'

If I change this lines to:

depends 'yum', '<3.0'

cookbook works without issues

I'm using Chef 11.8.2-1.ubuntu.12.04, installed from Omnibus.

Nobody have same issue?

2013/12/9 Sean OMeara someara@opscode.com:

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 miketheman@gmail.com 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 miketheman@gmail.com 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
eric.wolfe@marshall.edu
wrote:

Got a branch we can review before the release?

Sean OMeara someara@opscode.com 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 Mailboxhttps://www.dropbox.com/mailbox for iPhone

14

AFAIK, git.

On github: 2.8.5

On community :

$ knife cookbook site show git
average_rating: 5.0
category: Utilities
created_at: 2009-10-28T19:13:29Z
description: Installs git and/or sets up a Git server daemon
external_url: GitHub - sous-chefs/git: Development repository for the git cookbook
latest_version: http://cookbooks.opscode.com/api/v1/cookbooks/git/versions/2_8_4
maintainer: opscode
name: git
updated_at: 2013-12-12T02:14:46Z

2013/12/12 Sean OMeara someara@opscode.com:

for which cookbook(s)?
-s

On Thu, Dec 12, 2013 at 11:53 AM, Jorge Bianquetti jbianquetti@gmail.com
wrote:

knife cookbook site show still shows affected versions.

Thanks!

2013/12/12 Sean OMeara someara@opscode.com:

Sorry about that hitch.... I updated everything to include '< 3.0' to
satisfy the x.y format

On Thu, Dec 12, 2013 at 3:45 AM, Jorge Bianquetti
jbianquetti@gmail.com
wrote:

I get this error when I try to use any of the cookbooks updated to
include:

depends 'yum', '<3'

   [2013-12-12T08:40:37+00:00] ERROR: '3' does not match 'x.y.z' or

'x.y'

If I change this lines to:

depends 'yum', '<3.0'

cookbook works without issues

I'm using Chef 11.8.2-1.ubuntu.12.04, installed from Omnibus.

Nobody have same issue?

2013/12/9 Sean OMeara someara@opscode.com:

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 miketheman@gmail.com 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 miketheman@gmail.com 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
eric.wolfe@marshall.edu
wrote:

Got a branch we can review before the release?

Sean OMeara someara@opscode.com 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 Mailboxhttps://www.dropbox.com/mailbox for iPhone

15

Looks good to me: gist:944ea80667ad5ccaa005 · GitHub

On Thu, Dec 12, 2013 at 12:42 PM, Jorge Bianquetti jbianquetti@gmail.comwrote:

AFAIK, git.

On github: 2.8.5

On community :

$ knife cookbook site show git
average_rating: 5.0
category: Utilities
created_at: 2009-10-28T19:13:29Z
description: Installs git and/or sets up a Git server daemon
external_url: GitHub - sous-chefs/git: Development repository for the git cookbook
latest_version:
http://cookbooks.opscode.com/api/v1/cookbooks/git/versions/2_8_4
maintainer: opscode
name: git
updated_at: 2013-12-12T02:14:46Z

2013/12/12 Sean OMeara someara@opscode.com:

for which cookbook(s)?
-s

On Thu, Dec 12, 2013 at 11:53 AM, Jorge Bianquetti <
jbianquetti@gmail.com>
wrote:

knife cookbook site show still shows affected versions.

Thanks!

2013/12/12 Sean OMeara someara@opscode.com:

Sorry about that hitch.... I updated everything to include '< 3.0' to
satisfy the x.y format

On Thu, Dec 12, 2013 at 3:45 AM, Jorge Bianquetti
jbianquetti@gmail.com
wrote:

I get this error when I try to use any of the cookbooks updated to
include:

depends 'yum', '<3'

   [2013-12-12T08:40:37+00:00] ERROR: '3' does not match 'x.y.z'

or

'x.y'

If I change this lines to:

depends 'yum', '<3.0'

cookbook works without issues

I'm using Chef 11.8.2-1.ubuntu.12.04, installed from Omnibus.

Nobody have same issue?

2013/12/9 Sean OMeara someara@opscode.com:

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 miketheman@gmail.com 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 miketheman@gmail.com
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
eric.wolfe@marshall.edu
wrote:

Got a branch we can review before the release?

Sean OMeara someara@opscode.com 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 Mailboxhttps://www.dropbox.com/mailbox for iPhone

16

Ups! Sorry I mean nginx

On github: 2.0.9

On community:
$ knife cookbook site show nginx
average_rating: 3.96552
category: Web Servers
created_at: 2009-10-25T23:52:41Z
description: Installs and configures nginx
external_url: GitHub - sous-chefs/nginx: Development repository for the nginx cookbook
latest_version:
http://cookbooks.opscode.com/api/v1/cookbooks/nginx/versions/2_0_8
maintainer: opscode
name: nginx
updated_at: 2013-12-12T02:16:01Z
versions:

2013/12/12 Sean OMeara someara@opscode.com:

Looks good to me: gist:944ea80667ad5ccaa005 · GitHub

On Thu, Dec 12, 2013 at 12:42 PM, Jorge Bianquetti jbianquetti@gmail.com
wrote:

AFAIK, git.

On github: 2.8.5

On community :

$ knife cookbook site show git
average_rating: 5.0
category: Utilities
created_at: 2009-10-28T19:13:29Z
description: Installs git and/or sets up a Git server daemon
external_url: GitHub - sous-chefs/git: Development repository for the git cookbook
latest_version:
http://cookbooks.opscode.com/api/v1/cookbooks/git/versions/2_8_4
maintainer: opscode
name: git
updated_at: 2013-12-12T02:14:46Z

2013/12/12 Sean OMeara someara@opscode.com:

for which cookbook(s)?
-s

On Thu, Dec 12, 2013 at 11:53 AM, Jorge Bianquetti
jbianquetti@gmail.com
wrote:

knife cookbook site show still shows affected versions.

Thanks!

2013/12/12 Sean OMeara someara@opscode.com:

Sorry about that hitch.... I updated everything to include '< 3.0' to
satisfy the x.y format

On Thu, Dec 12, 2013 at 3:45 AM, Jorge Bianquetti
jbianquetti@gmail.com
wrote:

I get this error when I try to use any of the cookbooks updated to
include:

depends 'yum', '<3'

   [2013-12-12T08:40:37+00:00] ERROR: '3' does not match 'x.y.z'

or
'x.y'

If I change this lines to:

depends 'yum', '<3.0'

cookbook works without issues

I'm using Chef 11.8.2-1.ubuntu.12.04, installed from Omnibus.

Nobody have same issue?

2013/12/9 Sean OMeara someara@opscode.com:

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 miketheman@gmail.com 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 miketheman@gmail.com
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
eric.wolfe@marshall.edu
wrote:

Got a branch we can review before the release?

Sean OMeara someara@opscode.com 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 Mailboxhttps://www.dropbox.com/mailbox for iPhone

17

Pretty sure I got that one too.

On Thu, Dec 12, 2013 at 12:56 PM, Jorge Bianquetti jbianquetti@gmail.comwrote:

Ups! Sorry I mean nginx

On github: 2.0.9

On community:
$ knife cookbook site show nginx
average_rating: 3.96552
category: Web Servers
created_at: 2009-10-25T23:52:41Z
description: Installs and configures nginx
external_url: GitHub - sous-chefs/nginx: Development repository for the nginx cookbook
latest_version:
http://cookbooks.opscode.com/api/v1/cookbooks/nginx/versions/2_0_8
maintainer: opscode
name: nginx
updated_at: 2013-12-12T02:16:01Z
versions:

2013/12/12 Sean OMeara someara@opscode.com:

Looks good to me: gist:944ea80667ad5ccaa005 · GitHub

On Thu, Dec 12, 2013 at 12:42 PM, Jorge Bianquetti <
jbianquetti@gmail.com>
wrote:

AFAIK, git.

On github: 2.8.5

On community :

$ knife cookbook site show git
average_rating: 5.0
category: Utilities
created_at: 2009-10-28T19:13:29Z
description: Installs git and/or sets up a Git server daemon
external_url: GitHub - sous-chefs/git: Development repository for the git cookbook
latest_version:
http://cookbooks.opscode.com/api/v1/cookbooks/git/versions/2_8_4
maintainer: opscode
name: git
updated_at: 2013-12-12T02:14:46Z

2013/12/12 Sean OMeara someara@opscode.com:

for which cookbook(s)?
-s

On Thu, Dec 12, 2013 at 11:53 AM, Jorge Bianquetti
jbianquetti@gmail.com
wrote:

knife cookbook site show still shows affected versions.

Thanks!

2013/12/12 Sean OMeara someara@opscode.com:

Sorry about that hitch.... I updated everything to include '< 3.0'
to
satisfy the x.y format

On Thu, Dec 12, 2013 at 3:45 AM, Jorge Bianquetti
jbianquetti@gmail.com
wrote:

I get this error when I try to use any of the cookbooks updated to
include:

depends 'yum', '<3'

   [2013-12-12T08:40:37+00:00] ERROR: '3' does not match

'x.y.z'

or
'x.y'

If I change this lines to:

depends 'yum', '<3.0'

cookbook works without issues

I'm using Chef 11.8.2-1.ubuntu.12.04, installed from Omnibus.

Nobody have same issue?

2013/12/9 Sean OMeara someara@opscode.com:

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 miketheman@gmail.com
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 miketheman@gmail.com
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
eric.wolfe@marshall.edu
wrote:

Got a branch we can review before the release?

Sean OMeara someara@opscode.com 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 Mailboxhttps://www.dropbox.com/mailbox for
iPhone

18

OK, now it's working.

Thanks !

2013/12/12 Sean OMeara someara@opscode.com:

Pretty sure I got that one too.
gist:76c4daf6ccfbd80ab42f · GitHub

On Thu, Dec 12, 2013 at 12:56 PM, Jorge Bianquetti jbianquetti@gmail.com
wrote:

Ups! Sorry I mean nginx

On github: 2.0.9

On community:
$ knife cookbook site show nginx
average_rating: 3.96552
category: Web Servers
created_at: 2009-10-25T23:52:41Z
description: Installs and configures nginx
external_url: GitHub - sous-chefs/nginx: Development repository for the nginx cookbook
latest_version:
http://cookbooks.opscode.com/api/v1/cookbooks/nginx/versions/2_0_8
maintainer: opscode
name: nginx
updated_at: 2013-12-12T02:16:01Z
versions:

2013/12/12 Sean OMeara someara@opscode.com:

Looks good to me: gist:944ea80667ad5ccaa005 · GitHub

On Thu, Dec 12, 2013 at 12:42 PM, Jorge Bianquetti
jbianquetti@gmail.com
wrote:

AFAIK, git.

On github: 2.8.5

On community :

$ knife cookbook site show git
average_rating: 5.0
category: Utilities
created_at: 2009-10-28T19:13:29Z
description: Installs git and/or sets up a Git server daemon
external_url: GitHub - sous-chefs/git: Development repository for the git cookbook
latest_version:
http://cookbooks.opscode.com/api/v1/cookbooks/git/versions/2_8_4
maintainer: opscode
name: git
updated_at: 2013-12-12T02:14:46Z

2013/12/12 Sean OMeara someara@opscode.com:

for which cookbook(s)?
-s

On Thu, Dec 12, 2013 at 11:53 AM, Jorge Bianquetti
jbianquetti@gmail.com
wrote:

knife cookbook site show still shows affected versions.

Thanks!

2013/12/12 Sean OMeara someara@opscode.com:

Sorry about that hitch.... I updated everything to include '< 3.0'
to
satisfy the x.y format

On Thu, Dec 12, 2013 at 3:45 AM, Jorge Bianquetti
jbianquetti@gmail.com
wrote:

I get this error when I try to use any of the cookbooks updated
to
include:

depends 'yum', '<3'

   [2013-12-12T08:40:37+00:00] ERROR: '3' does not match

'x.y.z'
or
'x.y'

If I change this lines to:

depends 'yum', '<3.0'

cookbook works without issues

I'm using Chef 11.8.2-1.ubuntu.12.04, installed from Omnibus.

Nobody have same issue?

2013/12/9 Sean OMeara someara@opscode.com:

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 miketheman@gmail.com
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 miketheman@gmail.com
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
eric.wolfe@marshall.edu
wrote:

Got a branch we can review before the release?

Sean OMeara someara@opscode.com 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 Mailboxhttps://www.dropbox.com/mailbox for
iPhone