Chef Client 12.1.0 Released


#1

Hi Chefs,
We’ve just released Chef 12.1.0. You can read more about it at
https://www.chef.io/blog/2015/03/03/chef-12-1-0-released/.

Thanks,
Jay


#2

This probably an oversight.

If this setting is changed to ‘false’ then it will adopt “Chef-13” style ?

On Tue, Mar 3, 2015 at 1:43 PM, Jay Mundrawala jdm@getchef.com wrote:

Hi Chefs,
We’ve just released Chef 12.1.0. You can read more about it at
https://www.chef.io/blog/2015/03/03/chef-12-1-0-released/.

Thanks,
Jay


#3

I think that the blog interpreting underscores as italics is a bit wonky
when so many chef things are blah_blah2. I’m not sure if it just needs to
be edited to syntax-highlight/format those keywords, or if you’re better
off disabling that auto-italic feature, but the text as stands is
definitely confusing visually, even if I can intuit what is meant.


~~ StormeRider ~~

“Every world needs its heroes […] They inspire us to be better than we
are. And they protect from the darkness that’s just around the corner.”

(from Smallville Season 6x1: “Zod”)

On why I hate the phrase “that’s so lame”… http://bit.ly/Ps3uSS

On Tue, Mar 3, 2015 at 10:43 AM, Jay Mundrawala jdm@getchef.com wrote:

Hi Chefs,
We’ve just released Chef 12.1.0. You can read more about it at
https://www.chef.io/blog/2015/03/03/chef-12-1-0-released/.

Thanks,
Jay


#4

A potential solution might be to wrap those sorts of things in backticks, to avoid triggering the italicizing behavior (which I suspect is Markdown of some sort), and preserve these programmy things.


Jeff Byrnes
@thejeffbyrnes
Lead DevOps Engineer
EverTrue
704.516.4628

On March 3, 2015 at 2:57:03 PM, Morgan Blackthorne (stormerider@gmail.com) wrote:

I think that the blog interpreting underscores as italics is a bit wonky when so many chef things are blah_blah2. I’m not sure if it just needs to be edited to syntax-highlight/format those keywords, or if you’re better off disabling that auto-italic feature, but the text as stands is definitely confusing visually, even if I can intuit what is meant.


~~ StormeRider ~~

“Every world needs its heroes […] They inspire us to be better than we are. And they protect from the darkness that’s just around the corner.”

(from Smallville Season 6x1: “Zod”)

On why I hate the phrase “that’s so lame”… http://bit.ly/Ps3uSS

On Tue, Mar 3, 2015 at 10:43 AM, Jay Mundrawala jdm@getchef.com wrote:
Hi Chefs,
We’ve just released Chef 12.1.0. You can read more about it at https://www.chef.io/blog/2015/03/03/chef-12-1-0-released/.

Thanks,
Jay


#5

requiring gems in recipe code was bad practice

is there any background reading on this? i find we use chef_gem for
chef-rewind and require 'chef/rewind' quite often, but this would seem to
indicate there’s a better practice. if so, i’d love to hear more about it
as this is the first time it’s crossed my radar.

On Tue, Mar 3, 2015 at 1:43 PM, Jeff Byrnes jeff@evertrue.com wrote:

A potential solution might be to wrap those sorts of things in backticks,
to avoid triggering the italicizing behavior (which I suspect is Markdown
of some sort), and preserve these programmy things.


Jeff Byrnes
@thejeffbyrnes http://twitter.com/thejeffbyrnes
Lead DevOps Engineer
EverTrue http://www.evertrue.com/
704.516.4628

On March 3, 2015 at 2:57:03 PM, Morgan Blackthorne (stormerider@gmail.com)
wrote:

I think that the blog interpreting underscores as italics is a bit wonky
when so many chef things are blah_blah2. I’m not sure if it just needs to
be edited to syntax-highlight/format those keywords, or if you’re better
off disabling that auto-italic feature, but the text as stands is
definitely confusing visually, even if I can intuit what is meant.


~~ StormeRider ~~

“Every world needs its heroes […] They inspire us to be better than we
are. And they protect from the darkness that’s just around the corner.”

(from Smallville Season 6x1: “Zod”)

On why I hate the phrase “that’s so lame”… http://bit.ly/Ps3uSS

On Tue, Mar 3, 2015 at 10:43 AM, Jay Mundrawala jdm@getchef.com wrote:

Hi Chefs,
We’ve just released Chef 12.1.0. You can read more about it at
https://www.chef.io/blog/2015/03/03/chef-12-1-0-released/.

Thanks,
Jay


#6

I think that chef-rewind is a bit of a corner case, and there are certainly
some people that think it’s an anti-pattern, and others who use it
liberally.


~~ StormeRider ~~

“Every world needs its heroes […] They inspire us to be better than we
are. And they protect from the darkness that’s just around the corner.”

(from Smallville Season 6x1: “Zod”)

On why I hate the phrase “that’s so lame”… http://bit.ly/Ps3uSS

On Tue, Mar 3, 2015 at 3:24 PM, Nathan Williams nath.e.will@gmail.com
wrote:

requiring gems in recipe code was bad practice

is there any background reading on this? i find we use chef_gem for
chef-rewind and require 'chef/rewind' quite often, but this would seem to
indicate there’s a better practice. if so, i’d love to hear more about it
as this is the first time it’s crossed my radar.

On Tue, Mar 3, 2015 at 1:43 PM, Jeff Byrnes jeff@evertrue.com wrote:

A potential solution might be to wrap those sorts of things in backticks,
to avoid triggering the italicizing behavior (which I suspect is Markdown
of some sort), and preserve these programmy things.


Jeff Byrnes
@thejeffbyrnes http://twitter.com/thejeffbyrnes
Lead DevOps Engineer
EverTrue http://www.evertrue.com/
704.516.4628

On March 3, 2015 at 2:57:03 PM, Morgan Blackthorne (stormerider@gmail.com)
wrote:

I think that the blog interpreting underscores as italics is a bit wonky
when so many chef things are blah_blah2. I’m not sure if it just needs to
be edited to syntax-highlight/format those keywords, or if you’re better
off disabling that auto-italic feature, but the text as stands is
definitely confusing visually, even if I can intuit what is meant.


~~ StormeRider ~~

“Every world needs its heroes […] They inspire us to be better than we
are. And they protect from the darkness that’s just around the corner.”

(from Smallville Season 6x1: “Zod”)

On why I hate the phrase “that’s so lame”… http://bit.ly/Ps3uSS

On Tue, Mar 3, 2015 at 10:43 AM, Jay Mundrawala jdm@getchef.com wrote:

Hi Chefs,
We’ve just released Chef 12.1.0. You can read more about it at
https://www.chef.io/blog/2015/03/03/chef-12-1-0-released/.

Thanks,
Jay


#7

in recipe if you require the library which you are installing as part of
the chef run, you are forced to install them at compile time, which causes
pain (same reason why chef_gem compile_time true as default is deprecated).
This also mean those recipes or any recipe that depends on them will fail
as well during why_run.

A safer way of doing this will be to add the require statement in provider
action method. Chef why_run module provider resource requirements based
based checks, they are also useful to get fine grained information (like if
you can load this library then only you can conclusively say whether the
resource will be updated or not … etc)

regards
ranjib

On Tue, Mar 3, 2015 at 3:24 PM, Nathan Williams nath.e.will@gmail.com
wrote:

requiring gems in recipe code was bad practice

is there any background reading on this? i find we use chef_gem for
chef-rewind and require 'chef/rewind' quite often, but this would seem to
indicate there’s a better practice. if so, i’d love to hear more about it
as this is the first time it’s crossed my radar.

On Tue, Mar 3, 2015 at 1:43 PM, Jeff Byrnes jeff@evertrue.com wrote:

A potential solution might be to wrap those sorts of things in backticks,
to avoid triggering the italicizing behavior (which I suspect is Markdown
of some sort), and preserve these programmy things.


Jeff Byrnes
@thejeffbyrnes http://twitter.com/thejeffbyrnes
Lead DevOps Engineer
EverTrue http://www.evertrue.com/
704.516.4628

On March 3, 2015 at 2:57:03 PM, Morgan Blackthorne (stormerider@gmail.com)
wrote:

I think that the blog interpreting underscores as italics is a bit wonky
when so many chef things are blah_blah2. I’m not sure if it just needs to
be edited to syntax-highlight/format those keywords, or if you’re better
off disabling that auto-italic feature, but the text as stands is
definitely confusing visually, even if I can intuit what is meant.


~~ StormeRider ~~

“Every world needs its heroes […] They inspire us to be better than we
are. And they protect from the darkness that’s just around the corner.”

(from Smallville Season 6x1: “Zod”)

On why I hate the phrase “that’s so lame”… http://bit.ly/Ps3uSS

On Tue, Mar 3, 2015 at 10:43 AM, Jay Mundrawala jdm@getchef.com wrote:

Hi Chefs,
We’ve just released Chef 12.1.0. You can read more about it at
https://www.chef.io/blog/2015/03/03/chef-12-1-0-released/.

Thanks,
Jay


#8

Yeah, since you want to use the gem at compile time in recipe code by
design its one use case where forcing compile time is actually what you
want. At the same time its trivial to do chef-rewind without the
chef-rewind gem which can avoid that problem entirely:

override the redis.conf template from the redis cookbook with my

wrapper cookbook
resources(template:
"#{node[‘redis’][‘conf_dir’]}/redis.conf").cookbook(cookbook_name)

You can also drop the chef-rewind code into a cookbook library file and
include it that way and avoid the gem require, which is a much better
pattern for distributing library code to be used in chef recipes.

On 3/3/15 3:28 PM, Morgan Blackthorne wrote:

I think that chef-rewind is a bit of a corner case, and there are
certainly some people that think it’s an anti-pattern, and others who
use it liberally.


~~ StormeRider ~~

“Every world needs its heroes […] They inspire us to be better than
we are. And they protect from the darkness that’s just around the corner.”

(from Smallville Season 6x1: “Zod”)

On why I hate the phrase “that’s so lame”… http://bit.ly/Ps3uSS

On Tue, Mar 3, 2015 at 3:24 PM, Nathan Williams <nath.e.will@gmail.com
mailto:nath.e.will@gmail.com> wrote:

> requiring gems in recipe code was bad practice

is there any background reading on this? i find we use chef_gem
for chef-rewind and `require 'chef/rewind'` quite often, but this
would seem to indicate there's a better practice. if so, i'd love
to hear more about it as this is the first time it's crossed my radar.

On Tue, Mar 3, 2015 at 1:43 PM, Jeff Byrnes <jeff@evertrue.com
<mailto:jeff@evertrue.com>> wrote:

    A potential solution might be to wrap those sorts of things in
    backticks, to avoid triggering the italicizing behavior (which
    I suspect is Markdown of some sort), and preserve these
    programmy things.

    -- 
    Jeff Byrnes
    @thejeffbyrnes <http://twitter.com/thejeffbyrnes>
    Lead DevOps Engineer
    EverTrue <http://www.evertrue.com/>
    704.516.4628 <tel:704.516.4628>

    On March 3, 2015 at 2:57:03 PM, Morgan Blackthorne
    (stormerider@gmail.com <mailto:stormerider@gmail.com>) wrote:
    I think that the blog interpreting underscores as italics is
    a bit wonky when so many chef things are blah_blah2. I'm not
    sure if it just needs to be edited to syntax-highlight/format
    those keywords, or if you're better off disabling that
    auto-italic feature, but the text as stands is definitely
    confusing visually, even if I can intuit what is meant.

    -- 
    ~*~ StormeRider ~*~

    "Every world needs its heroes [...] They inspire us to be
    better than we are. And they protect from the darkness that's
    just around the corner."

    (from Smallville Season 6x1: "Zod")

    On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

    On Tue, Mar 3, 2015 at 10:43 AM, Jay Mundrawala
    <jdm@getchef.com <mailto:jdm@getchef.com>> wrote:

        Hi Chefs,
        We've just released Chef 12.1.0. You can read more about
        it at
        https://www.chef.io/blog/2015/03/03/chef-12-1-0-released/.

        Thanks,
        Jay

#9

Why is depending upon a cookbook preferable to compile-time chef_gem
installation?

I completely understand that we don’t want a build-essentials race
occurring before our Chef run can even get off the ground, but isolating
useful code into Cookbooks instead of the larger Ruby ecosystem doesn’t
seem to the way forward either.

On Tue, Mar 3, 2015 at 7:10 PM, Lamont Granquist lamont@chef.io wrote:

Yeah, since you want to use the gem at compile time in recipe code by
design its one use case where forcing compile time is actually what you
want. At the same time its trivial to do chef-rewind without the
chef-rewind gem which can avoid that problem entirely:

override the redis.conf template from the redis cookbook with my wrapper

cookbook
resources(template:
"#{node[‘redis’][‘conf_dir’]}/redis.conf").cookbook(cookbook_name)

You can also drop the chef-rewind code into a cookbook library file and
include it that way and avoid the gem require, which is a much better
pattern for distributing library code to be used in chef recipes.

On 3/3/15 3:28 PM, Morgan Blackthorne wrote:

I think that chef-rewind is a bit of a corner case, and there are
certainly some people that think it’s an anti-pattern, and others who use
it liberally.


~~ StormeRider ~~

“Every world needs its heroes […] They inspire us to be better than we
are. And they protect from the darkness that’s just around the corner.”

(from Smallville Season 6x1: “Zod”)

On why I hate the phrase “that’s so lame”… http://bit.ly/Ps3uSS

On Tue, Mar 3, 2015 at 3:24 PM, Nathan Williams nath.e.will@gmail.com
wrote:

requiring gems in recipe code was bad practice

is there any background reading on this? i find we use chef_gem for
chef-rewind and require 'chef/rewind' quite often, but this would seem to
indicate there’s a better practice. if so, i’d love to hear more about it
as this is the first time it’s crossed my radar.

On Tue, Mar 3, 2015 at 1:43 PM, Jeff Byrnes jeff@evertrue.com wrote:

A potential solution might be to wrap those sorts of things in
backticks, to avoid triggering the italicizing behavior (which I suspect is
Markdown of some sort), and preserve these programmy things.


Jeff Byrnes
@thejeffbyrnes http://twitter.com/thejeffbyrnes
Lead DevOps Engineer
EverTrue http://www.evertrue.com/
704.516.4628

On March 3, 2015 at 2:57:03 PM, Morgan Blackthorne (
stormerider@gmail.com) wrote:

I think that the blog interpreting underscores as italics is a bit
wonky when so many chef things are blah_blah2. I’m not sure if it just
needs to be edited to syntax-highlight/format those keywords, or if you’re
better off disabling that auto-italic feature, but the text as stands is
definitely confusing visually, even if I can intuit what is meant.


~~ StormeRider ~~

“Every world needs its heroes […] They inspire us to be better than we
are. And they protect from the darkness that’s just around the corner.”

(from Smallville Season 6x1: “Zod”)

On why I hate the phrase “that’s so lame”… http://bit.ly/Ps3uSS

On Tue, Mar 3, 2015 at 10:43 AM, Jay Mundrawala jdm@getchef.com wrote:

Hi Chefs,
We’ve just released Chef 12.1.0. You can read more about it at
https://www.chef.io/blog/2015/03/03/chef-12-1-0-released/.

Thanks,
Jay

Peter Burkholder — Customer Success Engineer

Unavailability: Travel March 2-3; Vacation March 16-20; ChefConf March
30-April 3

301-204-5767 – pburkholder@chef.io – *my: *Linkedin
http://www.linkedin.com/in/pburkholder Twitter
http://www.twitter.com/pburkholder Cal
https://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEK
endar

CHEF

CHEF.IO http://www.chef.io/

TM

chef.io http://www.chef.io/ Blog http://www.chef.io/blog/ Facebook
https://www.facebook.com/getchefdotcom Twitter
https://twitter.com/chef Youtube https://www.youtube.com/getchef


#10

For a chef specific piece of code like that which is only designed to
mangle the chef resource collection, there’s zero benefit to rubygems
because there’s no utility outside of chef, so distribution via
libraries in cookbooks is a much better solution (using the tool for the
job). For gems like nokogiri it obviously makes sense to have those as
gems, but in those use cases you’re much more likely to be able to wrap
the use of that gem in a provider.

On 3/3/15 6:45 PM, Peter Burkholder wrote:

Why is depending upon a cookbook preferable to compile-time chef_gem
installation?

I completely understand that we don’t want a build-essentials race
occurring before our Chef run can even get off the ground, but
isolating useful code into Cookbooks instead of the larger Ruby
ecosystem doesn’t seem to the way forward either.

On Tue, Mar 3, 2015 at 7:10 PM, Lamont Granquist <lamont@chef.io
mailto:lamont@chef.io> wrote:

Yeah, since you want to use the gem at compile time in recipe code
by design its one use case where forcing compile time is actually
what you want.  At the same time its trivial to do chef-rewind
without the chef-rewind gem which can avoid that problem entirely:

# override the redis.conf template from the redis cookbook with my
wrapper cookbook
resources(template:
"#{node['redis']['conf_dir']}/redis.conf").cookbook(cookbook_name)

You can also drop the chef-rewind code into a cookbook library
file and include it that way and avoid the gem require, which is a
much better pattern for distributing library code to be used in
chef recipes.


On 3/3/15 3:28 PM, Morgan Blackthorne wrote:
I think that chef-rewind is a bit of a corner case, and there are
certainly some people that think it's an anti-pattern, and others
who use it liberally.

-- 
~*~ StormeRider ~*~

"Every world needs its heroes [...] They inspire us to be better
than we are. And they protect from the darkness that's just
around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

On Tue, Mar 3, 2015 at 3:24 PM, Nathan Williams
<nath.e.will@gmail.com <mailto:nath.e.will@gmail.com>> wrote:

    > requiring gems in recipe code was bad practice

    is there any background reading on this? i find we use
    chef_gem for chef-rewind and `require 'chef/rewind'` quite
    often, but this would seem to indicate there's a better
    practice. if so, i'd love to hear more about it as this is
    the first time it's crossed my radar.

    On Tue, Mar 3, 2015 at 1:43 PM, Jeff Byrnes
    <jeff@evertrue.com <mailto:jeff@evertrue.com>> wrote:

        A potential solution might be to wrap those sorts of
        things in backticks, to avoid triggering the italicizing
        behavior (which I suspect is Markdown of some sort), and
        preserve these programmy things.

        -- 
        Jeff Byrnes
        @thejeffbyrnes <http://twitter.com/thejeffbyrnes>
        Lead DevOps Engineer
        EverTrue <http://www.evertrue.com/>
        704.516.4628 <tel:704.516.4628>

        On March 3, 2015 at 2:57:03 PM, Morgan Blackthorne
        (stormerider@gmail.com <mailto:stormerider@gmail.com>) wrote:
        I think that the blog interpreting underscores as
        italics is a bit wonky when so many chef things are
        blah_blah2. I'm not sure if it just needs to be edited
        to syntax-highlight/format those keywords, or if you're
        better off disabling that auto-italic feature, but the
        text as stands is definitely confusing visually, even if
        I can intuit what is meant.

        -- 
        ~*~ StormeRider ~*~

        "Every world needs its heroes [...] They inspire us to
        be better than we are. And they protect from the
        darkness that's just around the corner."

        (from Smallville Season 6x1: "Zod")

        On why I hate the phrase "that's so lame"...
        http://bit.ly/Ps3uSS

        On Tue, Mar 3, 2015 at 10:43 AM, Jay Mundrawala
        <jdm@getchef.com <mailto:jdm@getchef.com>> wrote:

            Hi Chefs,
            We've just released Chef 12.1.0. You can read more
            about it at
            https://www.chef.io/blog/2015/03/03/chef-12-1-0-released/.

            Thanks,
            Jay

Peter Burkholder — Customer Success Engineer

Unavailability: Travel March 2-3; Vacation March 16-20; ChefConf March
30-April 3

301-204-5767 – pburkholder@chef.io mailto:pburkholder@chef.io – *my:
*Linkedin http://www.linkedin.com/in/pburkholder Twitter
http://www.twitter.com/pburkholder Cal
https://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEKendar

CHEF

CHEF.IO http://www.chef.io/

TM

chef.io http://www.chef.io/Blog http://www.chef.io/blog/
Facebook https://www.facebook.com/getchefdotcom Twitter
https://twitter.com/chef Youtube https://www.youtube.com/getchef


#11

I did some background reading on the list support to the package provider.

While I’m very pleased that you can now do package installations much
faster, I’m concerned about the syntax. In particular, my concern is the
way names and versions are mapped using a pair of Arrays instead of a more
logical Hash map. I’d expect something like:

packages “group” do
list { “foo” => “1.0.0”, “bar”, => “2.1.7” }
end

Instead we got something like this:

package [“foo”, “bar”] do
version [“1.0.0”, “2.1.7”]
end

For reasonably short lists, this is fine, but once you get past 5 or so,
having to iterate the lists by hand to match the name and version will
become extremely difficult and error prone. If the above couldn’t be done
using the package provider, I’d suggest that a new resource should have
been created instead so that the semantics could be better defined.

Best regards,

–Michael

On Tue, Mar 3, 2015 at 10:43 AM, Jay Mundrawala jdm@getchef.com wrote:

Hi Chefs,
We’ve just released Chef 12.1.0. You can read more about it at
https://www.chef.io/blog/2015/03/03/chef-12-1-0-released/.

Thanks,
Jay


#12

+1 on this, having people manually keep array indices in sync isn’t safe.

I’ve created https://github.com/chef/chef/issues/3040 to track this.

–Charles

On March 4, 2015 at 10:58:49 AM, Michael Fischer (mfischer@zendesk.com) wrote:

I did some background reading on the list support to the package provider.

While I’m very pleased that you can now do package installations much faster, I’m concerned about the syntax. In particular, my concern is the way names and versions are mapped using a pair of Arrays instead of a more logical Hash map. I’d expect something like:

packages “group” do
list { “foo” => “1.0.0”, “bar”, => “2.1.7” }
end

Instead we got something like this:

package [“foo”, “bar”] do
version [“1.0.0”, “2.1.7”]
end

For reasonably short lists, this is fine, but once you get past 5 or so, having to iterate the lists by hand to match the name and version will become extremely difficult and error prone. If the above couldn’t be done using the package provider, I’d suggest that a new resource should have been created instead so that the semantics could be better defined.

Best regards,

–Michael

On Tue, Mar 3, 2015 at 10:43 AM, Jay Mundrawala jdm@getchef.com wrote:
Hi Chefs,
We’ve just released Chef 12.1.0. You can read more about it at https://www.chef.io/blog/2015/03/03/chef-12-1-0-released/.

Thanks,
Jay


#13

Regarding the multi-package support, what benefits does it bring to the
table over something like this?:

{“php-pecl-imagick” => “3.1.2-2.el6”, “ImageMagick-last-libs” =>
“6.8.7.4-1.el6”, “other-package” => nil}
.each do |package, version|
package package do
version version
end
end

I agree with the others that having to keep track of indices is a poor
approach.

Also, most (all?) resources currently apply to a single target (a user
account, a directory, a file, etc.). Will the package resource be the
special exception, or will other resources follow suit with the array
format? e.g., will we be seeing things like directory ["/dir1", "/dir2"]
down the road?

On Fri, Mar 6, 2015 at 1:37 PM, Charles Johnson charles@chef.io wrote:

+1 on this, having people manually keep array indices in sync isn’t safe.

I’ve created https://github.com/chef/chef/issues/3040 to track this.

–Charles

On March 4, 2015 at 10:58:49 AM, Michael Fischer (mfischer@zendesk.com)
wrote:

I did some background reading on the list support to the package provider.

While I’m very pleased that you can now do package installations much
faster, I’m concerned about the syntax. In particular, my concern is the
way names and versions are mapped using a pair of Arrays instead of a more
logical Hash map. I’d expect something like:

packages “group” do
list { “foo” => “1.0.0”, “bar”, => “2.1.7” }
end

Instead we got something like this:

package [“foo”, “bar”] do
version [“1.0.0”, “2.1.7”]
end

For reasonably short lists, this is fine, but once you get past 5 or so,
having to iterate the lists by hand to match the name and version will
become extremely difficult and error prone. If the above couldn’t be done
using the package provider, I’d suggest that a new resource should have
been created instead so that the semantics could be better defined.

Best regards,

–Michael

On Tue, Mar 3, 2015 at 10:43 AM, Jay Mundrawala jdm@getchef.com wrote:

Hi Chefs,
We’ve just released Chef 12.1.0. You can read more about it at
https://www.chef.io/blog/2015/03/03/chef-12-1-0-released/.

Thanks,
Jay


#14

its a single invocation, so it will speed up chef run a lot. Unlike user or
directory, generally package installation involves multiple network calls,
hence its makes more sense to do this for packages. Also user provider
(useradd/usermod etc) does not allow multiple user modification, while
package provider (like apt, yum) all supports multiple package installation.

cheers
ranjib

On Sat, Mar 7, 2015 at 4:43 AM, Ameir Abdeldayem ameirh@gmail.com wrote:

Regarding the multi-package support, what benefits does it bring to the
table over something like this?:

{“php-pecl-imagick” => “3.1.2-2.el6”, “ImageMagick-last-libs” =>
“6.8.7.4-1.el6”, “other-package” => nil}
.each do |package, version|
package package do
version version
end
end

I agree with the others that having to keep track of indices is a poor
approach.

Also, most (all?) resources currently apply to a single target (a user
account, a directory, a file, etc.). Will the package resource be the
special exception, or will other resources follow suit with the array
format? e.g., will we be seeing things like directory ["/dir1", "/dir2"]
down the road?

On Fri, Mar 6, 2015 at 1:37 PM, Charles Johnson charles@chef.io wrote:

+1 on this, having people manually keep array indices in sync isn’t safe.

I’ve created https://github.com/chef/chef/issues/3040 to track this.

–Charles

On March 4, 2015 at 10:58:49 AM, Michael Fischer (mfischer@zendesk.com)
wrote:

I did some background reading on the list support to the package
provider.

While I’m very pleased that you can now do package installations much
faster, I’m concerned about the syntax. In particular, my concern is the
way names and versions are mapped using a pair of Arrays instead of a more
logical Hash map. I’d expect something like:

packages “group” do
list { “foo” => “1.0.0”, “bar”, => “2.1.7” }
end

Instead we got something like this:

package [“foo”, “bar”] do
version [“1.0.0”, “2.1.7”]
end

For reasonably short lists, this is fine, but once you get past 5 or so,
having to iterate the lists by hand to match the name and version will
become extremely difficult and error prone. If the above couldn’t be done
using the package provider, I’d suggest that a new resource should have
been created instead so that the semantics could be better defined.

Best regards,

–Michael

On Tue, Mar 3, 2015 at 10:43 AM, Jay Mundrawala jdm@getchef.com wrote:

Hi Chefs,
We’ve just released Chef 12.1.0. You can read more about it at
https://www.chef.io/blog/2015/03/03/chef-12-1-0-released/.

Thanks,
Jay


#15

Speed. One resource and one command issued and one transaction, vs. many:

time ./apply-new.rb

Recipe: (chef-apply cookbook)::(chef-apply recipe)

  • apt_package[bc, zsh, vim, curl, strace, lsof, systemtap, telnet,
    mtr, subversion, nmap, gdb, traceroute, tcpdump, htop, iptraf, tmux,
    nuttcp, s3cmd, source-highlight, sysbench] action install
    • install version 1.06.95-8ubuntu1 of package bc
    • install version 7.35.0-1ubuntu2.3 of package curl
    • install version 4.8-1ubuntu5 of package strace
    • install version 2.3-1ubuntu1 of package systemtap
    • install version 0.17-36build2 of package telnet
    • install version 0.85-2 of package mtr
    • install version 1.8.8-1ubuntu3.1 of package subversion
    • install version 6.40-0.2ubuntu1 of package nmap
    • install version 1:2.0.20-0ubuntu0.1 of package traceroute
    • install version 4.5.1-2ubuntu1.1 of package tcpdump
    • install version 1.0.2-3 of package htop
    • install version 3.0.0-8.1 of package iptraf
    • install version 1.8-5 of package tmux
    • install version 6.1.2-4 of package nuttcp
    • install version 1.1.0~beta3-2 of package s3cmd
    • install version 0.4.12-1.1 of package sysbench
      ./apply-new.rb 4.01s user 5.63s system 68% cpu 14.007 total

time ./apply-old.rb

Recipe: (chef-apply cookbook)::(chef-apply recipe)

  • apt_package[bc] action install
    • install version 1.06.95-8ubuntu1 of package bc
  • apt_package[zsh] action install (up to date)
  • apt_package[vim] action install (up to date)
  • apt_package[curl] action install
    • install version 7.35.0-1ubuntu2.3 of package curl
  • apt_package[strace] action install
    • install version 4.8-1ubuntu5 of package strace
  • apt_package[lsof] action install (up to date)
  • apt_package[systemtap] action install
    • install version 2.3-1ubuntu1 of package systemtap
  • apt_package[telnet] action install
    • install version 0.17-36build2 of package telnet
  • apt_package[mtr] action install
    • install version 0.85-2 of package mtr
  • apt_package[subversion] action install
    • install version 1.8.8-1ubuntu3.1 of package subversion
  • apt_package[nmap] action install
    • install version 6.40-0.2ubuntu1 of package nmap
  • apt_package[gdb] action install (up to date)
  • apt_package[traceroute] action install
    • install version 1:2.0.20-0ubuntu0.1 of package traceroute
  • apt_package[tcpdump] action install
    • install version 4.5.1-2ubuntu1.1 of package tcpdump
  • apt_package[htop] action install
    • install version 1.0.2-3 of package htop
  • apt_package[iptraf] action install
    • install version 3.0.0-8.1 of package iptraf
  • apt_package[tmux] action install
    • install version 1.8-5 of package tmux
  • apt_package[nuttcp] action install
    • install version 6.1.2-4 of package nuttcp
  • apt_package[s3cmd] action install
    • install version 1.1.0~beta3-2 of package s3cmd
  • apt_package[source-highlight] action install (up to date)
  • apt_package[sysbench] action install
    • install version 0.4.12-1.1 of package sysbench
      ./apply-old.rb 18.95s user 16.84s system 78% cpu 45.515 total

4 seconds vs 19 seconds to install those packages – and yum_package is
even slower per-install than apt_package and the gains are larger there.

On 3/7/15 4:43 AM, Ameir Abdeldayem wrote:

Regarding the multi-package support, what benefits does it bring to
the table over something like this?:

{“php-pecl-imagick” => “3.1.2-2.el6”, “ImageMagick-last-libs” =>
“6.8.7.4-1.el6”, “other-package” => nil}
.each do |package, version|
package package do
version version
end
end

I agree with the others that having to keep track of indices is a poor
approach.

Also, most (all?) resources currently apply to a single target (a user
account, a directory, a file, etc.). Will the package resource be the
special exception, or will other resources follow suit with the array
format? e.g., will we be seeing things like directory ["/dir1", "/dir2"] down the road?

On Fri, Mar 6, 2015 at 1:37 PM, Charles Johnson <charles@chef.io
mailto:charles@chef.io> wrote:

+1 on this, having people manually keep array indices in sync
isn't safe.

I've created https://github.com/chef/chef/issues/3040 to track this.


--Charles

On March 4, 2015 at 10:58:49 AM, Michael Fischer
(mfischer@zendesk.com <mailto:mfischer@zendesk.com>) wrote:
I did some background reading on the list support to the package
provider.

While I'm very pleased that you can now do package installations
much faster, I'm concerned about the syntax.  In particular, my
concern is the way names and versions are mapped using a pair of
Arrays instead of a more logical Hash map. I'd expect something like:

packages "group" do
  list { "foo" => "1.0.0", "bar", => "2.1.7" }
end

Instead we got something like this:

package ["foo", "bar"] do
  version ["1.0.0", "2.1.7"]
end

For reasonably short lists, this is fine, but once you get past 5
or so, having to iterate the lists by hand to match the name and
version will become extremely difficult and error prone. If the
above couldn't be done using the package provider, I'd suggest
that a new resource should have been created instead so that the
semantics could be better defined.

Best regards,

--Michael

On Tue, Mar 3, 2015 at 10:43 AM, Jay Mundrawala <jdm@getchef.com
<mailto:jdm@getchef.com>> wrote:

    Hi Chefs,
    We've just released Chef 12.1.0. You can read more about it
    at https://www.chef.io/blog/2015/03/03/chef-12-1-0-released/.

    Thanks,
    Jay

#16

Also, in some cases its impossible to install software outside of
installing two RPMs at the same time:

These two commands may both error out (even if you swap the order)
because they have mutual dependencies on each other:

yum install foo-part1
yum install foo-part2

While this may succeed because yum treats it as one transaction and can
see that they both satisfy each other dependencies:

yum install foo-part1 foo-part2

Prior to Chef 12.1.0 there was no way of having Chef install packages
like this other than writing your own shell_out or arguing with the
package author that their packaging is shitty (arguably true, but if the
author is not responsive that is not something that is likely to make
you happy about your job).

On 3/7/15 9:43 AM, Lamont Granquist wrote:

Speed. One resource and one command issued and one transaction, vs. many:

time ./apply-new.rb

Recipe: (chef-apply cookbook)::(chef-apply recipe)

  • apt_package[bc, zsh, vim, curl, strace, lsof, systemtap, telnet,
    mtr, subversion, nmap, gdb, traceroute, tcpdump, htop, iptraf, tmux,
    nuttcp, s3cmd, source-highlight, sysbench] action install
    • install version 1.06.95-8ubuntu1 of package bc
    • install version 7.35.0-1ubuntu2.3 of package curl
    • install version 4.8-1ubuntu5 of package strace
    • install version 2.3-1ubuntu1 of package systemtap
    • install version 0.17-36build2 of package telnet
    • install version 0.85-2 of package mtr
    • install version 1.8.8-1ubuntu3.1 of package subversion
    • install version 6.40-0.2ubuntu1 of package nmap
    • install version 1:2.0.20-0ubuntu0.1 of package traceroute
    • install version 4.5.1-2ubuntu1.1 of package tcpdump
    • install version 1.0.2-3 of package htop
    • install version 3.0.0-8.1 of package iptraf
    • install version 1.8-5 of package tmux
    • install version 6.1.2-4 of package nuttcp
    • install version 1.1.0~beta3-2 of package s3cmd
    • install version 0.4.12-1.1 of package sysbench
      ./apply-new.rb 4.01s user 5.63s system 68% cpu 14.007 total

time ./apply-old.rb

Recipe: (chef-apply cookbook)::(chef-apply recipe)

  • apt_package[bc] action install
    • install version 1.06.95-8ubuntu1 of package bc
  • apt_package[zsh] action install (up to date)
  • apt_package[vim] action install (up to date)
  • apt_package[curl] action install
    • install version 7.35.0-1ubuntu2.3 of package curl
  • apt_package[strace] action install
    • install version 4.8-1ubuntu5 of package strace
  • apt_package[lsof] action install (up to date)
  • apt_package[systemtap] action install
    • install version 2.3-1ubuntu1 of package systemtap
  • apt_package[telnet] action install
    • install version 0.17-36build2 of package telnet
  • apt_package[mtr] action install
    • install version 0.85-2 of package mtr
  • apt_package[subversion] action install
    • install version 1.8.8-1ubuntu3.1 of package subversion
  • apt_package[nmap] action install
    • install version 6.40-0.2ubuntu1 of package nmap
  • apt_package[gdb] action install (up to date)
  • apt_package[traceroute] action install
    • install version 1:2.0.20-0ubuntu0.1 of package traceroute
  • apt_package[tcpdump] action install
    • install version 4.5.1-2ubuntu1.1 of package tcpdump
  • apt_package[htop] action install
    • install version 1.0.2-3 of package htop
  • apt_package[iptraf] action install
    • install version 3.0.0-8.1 of package iptraf
  • apt_package[tmux] action install
    • install version 1.8-5 of package tmux
  • apt_package[nuttcp] action install
    • install version 6.1.2-4 of package nuttcp
  • apt_package[s3cmd] action install
    • install version 1.1.0~beta3-2 of package s3cmd
  • apt_package[source-highlight] action install (up to date)
  • apt_package[sysbench] action install
    • install version 0.4.12-1.1 of package sysbench
      ./apply-old.rb 18.95s user 16.84s system 78% cpu 45.515 total

4 seconds vs 19 seconds to install those packages – and yum_package
is even slower per-install than apt_package and the gains are larger
there.

On 3/7/15 4:43 AM, Ameir Abdeldayem wrote:

Regarding the multi-package support, what benefits does it bring to
the table over something like this?:

{“php-pecl-imagick” => “3.1.2-2.el6”, “ImageMagick-last-libs” =>
“6.8.7.4-1.el6”, “other-package” => nil}
.each do |package, version|
package package do
version version
end
end

I agree with the others that having to keep track of indices is a
poor approach.

Also, most (all?) resources currently apply to a single target (a
user account, a directory, a file, etc.). Will the package resource
be the special exception, or will other resources follow suit with
the array format? e.g., will we be seeing things like directory ["/dir1", "/dir2"] down the road?

On Fri, Mar 6, 2015 at 1:37 PM, Charles Johnson <charles@chef.io
mailto:charles@chef.io> wrote:

+1 on this, having people manually keep array indices in sync
isn't safe.

I've created https://github.com/chef/chef/issues/3040 to track this.


--Charles

On March 4, 2015 at 10:58:49 AM, Michael Fischer
(mfischer@zendesk.com <mailto:mfischer@zendesk.com>) wrote:
I did some background reading on the list support to the package
provider.

While I'm very pleased that you can now do package installations
much faster, I'm concerned about the syntax. In particular, my
concern is the way names and versions are mapped using a pair of
Arrays instead of a more logical Hash map.  I'd expect something
like:

packages "group" do
  list { "foo" => "1.0.0", "bar", => "2.1.7" }
end

Instead we got something like this:

package ["foo", "bar"] do
  version ["1.0.0", "2.1.7"]
end

For reasonably short lists, this is fine, but once you get past
5 or so, having to iterate the lists by hand to match the name
and version will become extremely difficult and error prone.  If
the above couldn't be done using the package provider, I'd
suggest that a new resource should have been created instead so
that the semantics could be better defined.

Best regards,

--Michael

On Tue, Mar 3, 2015 at 10:43 AM, Jay Mundrawala <jdm@getchef.com
<mailto:jdm@getchef.com>> wrote:

    Hi Chefs,
    We've just released Chef 12.1.0. You can read more about it
    at https://www.chef.io/blog/2015/03/03/chef-12-1-0-released/.

    Thanks,
    Jay