CHEF-4579: should package action install also upgrade?

Chef Infra (archive)
1

‘yum install foo’ and ‘apt-get install foo’ will both install package
foo if it is not installed, and upgrade foo to a later version if
there is one available.

In Chef, the package install action will only install the package.
We’re presuming here if you have chef-client running all the time you
don’t want it constantly updating your systems behind your back.

Should this be different?

https://tickets.opscode.com/browse/CHEF-4579

–
Bryan McLellan | opscode | technical program manager, open source
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org

2

No. I strongly object to this.

action :upgrade exists and is sufficient.

If action :install performed upgrades, it would absolutely destroy things,
for example running MongoDB using the 10gen repos and having a 2.2 database
upgrade to 2.4 behind your back, etc.

Brian

On Wed, Oct 2, 2013 at 3:23 PM, Bryan McLellan btm@opscode.com wrote:

'yum install foo' and 'apt-get install foo' will both install package
foo if it is not installed, and upgrade foo to a later version if
there is one available.

In Chef, the package install action will only install the package.
We're presuming here if you have chef-client running all the time you
don't want it constantly updating your systems behind your back.

Should this be different?

https://tickets.opscode.com/browse/CHEF-4579

--
Bryan McLellan | opscode | technical program manager, open source
(c) 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org

3

Thumbs down, vehemently.

"install", despite being what the underlying commands do, seems analogous
to "create_if_missing" semantics for the file resource.

This then provides a distinct different between install and upgrade, while
also allowing a specification of :version for those that pin to a specific
one (a la ETSY007 1).

The hope of using an abstraction layer such as Chef to control the actions
of the underlying commands in a more sensible and user-friendly manner,
which if we adopt the "this command behaves this way all the time"
approach, this may do us more harm than good.

-M

On Wed, Oct 2, 2013 at 3:33 PM, Brian Hatfield bmhatfield@gmail.com wrote:

No. I strongly object to this.

action :upgrade exists and is sufficient.

If action :install performed upgrades, it would absolutely destroy things,
for example running MongoDB using the 10gen repos and having a 2.2 database
upgrade to 2.4 behind your back, etc.

Brian

On Wed, Oct 2, 2013 at 3:23 PM, Bryan McLellan btm@opscode.com wrote:

'yum install foo' and 'apt-get install foo' will both install package
foo if it is not installed, and upgrade foo to a later version if
there is one available.

In Chef, the package install action will only install the package.
We're presuming here if you have chef-client running all the time you
don't want it constantly updating your systems behind your back.

Should this be different?

https://tickets.opscode.com/browse/CHEF-4579

--
Bryan McLellan | opscode | technical program manager, open source
(c) 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org

4

On Wed, Oct 2, 2013 at 3:33 PM, Brian Hatfield bmhatfield@gmail.com wrote:

No. I strongly object to this.

action :upgrade exists and is sufficient.

If action :install performed upgrades, it would absolutely destroy things,
for example running MongoDB using the 10gen repos and having a 2.2 database
upgrade to 2.4 behind your back, etc.

The question is a bit higher level than that surrounding the entire
semantics of package, not simply should install also upgrade.

You could have attributes to control it.

installs but doesn't upgrade

package "mongodb" do
action :install
upgrade false
end

installs and upgrades

package "mongodb" do
action :install
end

only upgrade, won't install

package "mongodb" do
action :upgrade
end

Bryan

5

On Wednesday, October 2, 2013 at 12:33 PM, Brian Hatfield wrote:

No. I strongly object to this.

action :upgrade exists and is sufficient.

The question isn't whether action :install and action :upgrade should exist or have different behavior, but rather one of what default is most desirable given the tradeoffs of each. By comparison, the default action on a file is "create" which really means "create_or_update"; you can use action :create_if_missing if you want to avoid updating the files.

If action :install performed upgrades, it would absolutely destroy things, for example running MongoDB using the 10gen repos and having a 2.2 database upgrade to 2.4 behind your back, etc.
The reason we bring this up is the flip side of this coin. If the package in your repo gets updated, then a new machine you bring up with the same recipes will create a different system than your machines you provisioned before the repo update. This seems surprising, no?

So the question is one of

  • user expectations: What should package "tmux" do when there's a newer version available?

  • consistency: Is it weird/confusing that files get updated by default, but packages do not? Is it confusing that this default behavior means you can build a box with the exact same recipes and get a different result?

  • pragmatic reason to be inconsistent: the risk of upgrading packages by default is so great that it's better if everyone using Chef learns that this is inconsistent, and why, and how to deal with it.

Thoughts?

Brian

--
Daniel DeLeo

6

From a pragmatic point of view, I think it's generally consider an upstream
(distro) problem to worry about consistency in packages and Chef already
allows versions to be specified if that's the desired effect. In my
opinion the install action shouldn't upgrade a package and it's the
semantics of apt/yum that seem counter-intuitive. We should also keep in
mind that Chef is an automation tool, apt-get install foo updating foo is
more of a "do what I mean, not what I say" dynamic where the user is
generally watching output to say yes or no to the implications of an
upgrade. In terms of Chef we don't have the convenience of waiting for the
user to approve the upgrade so a more conservative approach of not
upgrading on an install action makes much more sense.

On Wed, Oct 2, 2013 at 12:56 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, October 2, 2013 at 12:33 PM, Brian Hatfield wrote:

No. I strongly object to this.

action :upgrade exists and is sufficient.

The question isn't whether action :install and action :upgrade should
exist or have different behavior, but rather one of what default is most
desirable given the tradeoffs of each. By comparison, the default action on
a file is "create" which really means "create_or_update"; you can use
action :create_if_missing if you want to avoid updating the files.

If action :install performed upgrades, it would absolutely destroy things,
for example running MongoDB using the 10gen repos and having a 2.2 database
upgrade to 2.4 behind your back, etc.

The reason we bring this up is the flip side of this coin. If the package
in your repo gets updated, then a new machine you bring up with the same
recipes will create a different system than your machines you provisioned
before the repo update. This seems surprising, no?

So the question is one of

  • user expectations: What should package "tmux" do when there's a newer
    version available?

  • consistency: Is it weird/confusing that files get updated by default,
    but packages do not? Is it confusing that this default behavior means you
    can build a box with the exact same recipes and get a different result?

  • pragmatic reason to be inconsistent: the risk of upgrading packages by
    default is so great that it's better if everyone using Chef learns that
    this is inconsistent, and why, and how to deal with it.

Thoughts?

Brian

--
Daniel DeLeo

--
Paul Mooring
Operations Engineer
Opscode, Inc.

7

If you put it that way, that sounds a bit more appealing. Though i think
semantics is very important (especially to new comers) I still think action
:install should do exactly what it implies, install a package and that's
that.

A co-worker of mine mentioned maybe we can move forward with action
:install to also upgrade packages but set the upgrade attribute to false by
default, that way those that want it to mimic OS actions can and those of
us shaking at the thought can be put at ease.

On Wed, Oct 2, 2013 at 3:59 PM, Bryan McLellan btm@loftninjas.org wrote:

On Wed, Oct 2, 2013 at 3:33 PM, Brian Hatfield bmhatfield@gmail.com
wrote:

No. I strongly object to this.

action :upgrade exists and is sufficient.

If action :install performed upgrades, it would absolutely destroy
things,
for example running MongoDB using the 10gen repos and having a 2.2
database
upgrade to 2.4 behind your back, etc.

The question is a bit higher level than that surrounding the entire
semantics of package, not simply should install also upgrade.

You could have attributes to control it.

installs but doesn't upgrade

package "mongodb" do
action :install
upgrade false
end

installs and upgrades

package "mongodb" do
action :install
end

only upgrade, won't install

package "mongodb" do
action :upgrade
end

Bryan

--
Elvin Abordo
Mobile: (845) 475-8744

8

My belief is that the "pragmatic reason to be inconsistent" is strong
enough to override other lines of reasoning. In addition to the stated
reasoning, I think changing this now would imply inverse behavior silently
in any cookbook not refactored for this, as well as necessitate making sure
every Chef developer is aware of the new behavior.

And unfortunately, I think that no matter how well publicized and how much
of a push is put behind it, many admins will be surprised by a package they
did not want upgraded being upgraded during a chef run. Many admins run
Chef on a recurring daemon schedule, and don't control the repositories
they use. Furthermore, while distro repos tend to be reliable, third party
repos may not have such strong maintenance policies.

My opinion that this change is not worth the risk nor effort to publicize.

Brian

On Wed, Oct 2, 2013 at 3:56 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, October 2, 2013 at 12:33 PM, Brian Hatfield wrote:

No. I strongly object to this.

action :upgrade exists and is sufficient.

The question isn't whether action :install and action :upgrade should
exist or have different behavior, but rather one of what default is most
desirable given the tradeoffs of each. By comparison, the default action on
a file is "create" which really means "create_or_update"; you can use
action :create_if_missing if you want to avoid updating the files.

If action :install performed upgrades, it would absolutely destroy things,
for example running MongoDB using the 10gen repos and having a 2.2 database
upgrade to 2.4 behind your back, etc.

The reason we bring this up is the flip side of this coin. If the package
in your repo gets updated, then a new machine you bring up with the same
recipes will create a different system than your machines you provisioned
before the repo update. This seems surprising, no?

So the question is one of

  • user expectations: What should package "tmux" do when there's a newer
    version available?

  • consistency: Is it weird/confusing that files get updated by default,
    but packages do not? Is it confusing that this default behavior means you
    can build a box with the exact same recipes and get a different result?

  • pragmatic reason to be inconsistent: the risk of upgrading packages by
    default is so great that it's better if everyone using Chef learns that
    this is inconsistent, and why, and how to deal with it.

Thoughts?

Brian

--
Daniel DeLeo

9

Dan,
The behavior difference makes sense to me.

package 'tmux', when not installed, should install the latest available
package, similar to the file resource - populate with the latest available
content.

Adding modifiers to constrain the behavior, such as version and
create_if_missing, extend the behavior to a subset/specific set of rules.

Etsy had blogged about using package resources with upgrade taking down a
significant set of their code, not using the base install method, and
devised some foodcritic rules to help them prevent hitting that problem
again - by ensuring not using the upgrade action, and requiring use of a
version variable to prevent version mismatch.

I think the current behavior works, possibly needs some better
documentation for newcomers, but other than that I believe it to be simple
and concise.

-M

On Wed, Oct 2, 2013 at 3:56 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, October 2, 2013 at 12:33 PM, Brian Hatfield wrote:

No. I strongly object to this.

action :upgrade exists and is sufficient.

The question isn't whether action :install and action :upgrade should
exist or have different behavior, but rather one of what default is most
desirable given the tradeoffs of each. By comparison, the default action on
a file is "create" which really means "create_or_update"; you can use
action :create_if_missing if you want to avoid updating the files.

If action :install performed upgrades, it would absolutely destroy things,
for example running MongoDB using the 10gen repos and having a 2.2 database
upgrade to 2.4 behind your back, etc.

The reason we bring this up is the flip side of this coin. If the package
in your repo gets updated, then a new machine you bring up with the same
recipes will create a different system than your machines you provisioned
before the repo update. This seems surprising, no?

So the question is one of

  • user expectations: What should package "tmux" do when there's a newer
    version available?

  • consistency: Is it weird/confusing that files get updated by default,
    but packages do not? Is it confusing that this default behavior means you
    can build a box with the exact same recipes and get a different result?

  • pragmatic reason to be inconsistent: the risk of upgrading packages by
    default is so great that it's better if everyone using Chef learns that
    this is inconsistent, and why, and how to deal with it.

Thoughts?

Brian

--
Daniel DeLeo