Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

yum_package version property needs to be stricter about requiring the epoch #8883

Open
Wing924 opened this issue Sep 13, 2019 · 5 comments

Comments

@Wing924
Copy link

commented Sep 13, 2019

Description

yum_package don't keep idempotency if set version on Chef 15

Chef Version

Chef Client 15.3.14

Platform Version

CentOS 7

Replication Case

yum_package 'java-11-openjdk' do
  version '11.0.3.7-0.el7_6'
end

Client Output

Starting Chef Infra Client, version 15.3.14
       Creating a new client identity for test-centos-7-chef15 using the validator key.
       resolving cookbooks for run list: ["test::_test"]
       Synchronizing Cookbooks:
       Installing Cookbook Gems:
       Compiling Cookbooks...
       Converging 1 resources
       Recipe: test::_test
         * yum_package[java-11-openjdk] action install
           - install version 11.0.3.7-0.el7_6 of package java-11-openjdk

       Running handlers:
       Running handlers complete
       Chef Infra Client finished, 1/1 resources updated in 50 seconds
       Starting Chef Infra Client, version 15.3.14
       resolving cookbooks for run list: ["test::_test"]
       Synchronizing Cookbooks:
       Installing Cookbook Gems:
       Compiling Cookbooks...
       Converging 1 resources
       Recipe: test::_test
         * yum_package[java-11-openjdk] action install
           - install version 11.0.3.7-0.el7_6 of package java-11-openjdk

       Running handlers:
       First chef run should have reached a converged state.
       Resources updated in a second chef-client run:
       - yum_package[java-11-openjdk]
       bash: line 6: 14963 Killed                  sh -c '
       TEST_KITCHEN="1"; export TEST_KITCHEN
       sudo -E /opt/chef/bin/chef-client --local-mode --config /var/tmp/kitchen/client_no_updated_resources.rb --log_level auto --force-formatter --no-color --json-attributes /var/tmp/kitchen/dna.json --chef-zero-port 8889
       '

Stacktrace

@lamont-granquist

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2019

You need to include the epoch:

#!/usr/bin/env chef-apply

yum_package 'java-11-openjdk' do
  version '1:11.0.3.7-0.el7_6'
end

results in:

# ./apply.rb
Recipe: (chef-apply cookbook)::(chef-apply recipe)
  * yum_package[java-11-openjdk] action install (up to date)

alternatively it works when including the version in the name:

#!/usr/bin/env chef-apply

yum_package 'java-11-openjdk-11.0.3.7-0.el7_6'

results in:

# ./apply.rb
Recipe: (chef-apply cookbook)::(chef-apply recipe)
  * yum_package[java-11-openjdk-11.0.3.7-0.el7_6] action install (up to date)

using the version in the name with yum_package is encouraged over using the version as the property, particularly around handling epochs.

@lamont-granquist

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2019

[2019-09-13T17:39:26+00:00] TRACE: Resources for generic yum_package resource enabled on node include: [Chef::Resource::YumPackage]
[2019-09-13T17:39:26+00:00] TRACE: Resource for yum_package is Chef::Resource::YumPackage
Recipe: (chef-apply cookbook)::(chef-apply recipe)
  * yum_package[java-11-openjdk] action install[2019-09-13T17:39:26+00:00] INFO: Processing yum_package[java-11-openjdk] action install ((chef-apply cookbook)::(chef-apply recipe) line 3)
[2019-09-13T17:39:26+00:00] TRACE: Providers for generic yum_package resource enabled on node include: [Chef::Provider::Package::Yum]
[2019-09-13T17:39:26+00:00] TRACE: Provider for action install on resource yum_package[java-11-openjdk] is Chef::Provider::Package::Yum
[2019-09-13T17:39:27+00:00] TRACE: sending '{"action":"whatinstalled","provides":"java-11-openjdk"}' to python helper
[2019-09-13T17:39:27+00:00] TRACE: got 'java-11-openjdk 1:11.0.3.7-0.el7_6 x86_64' from python helper
[2019-09-13T17:39:27+00:00] TRACE: parsed java-11-openjdk-1:11.0.3.7-0.el7_6.x86_64 from python helper
[2019-09-13T17:39:27+00:00] TRACE: sending '{"action":"versioncompare","versions":["1:11.0.3.7-0.el7_6.x86_64","11.0.3.7-0.el7_6"]}' to python helper
[2019-09-13T17:39:27+00:00] TRACE: got '1' from python helper
[2019-09-13T17:39:27+00:00] TRACE: sending '{"action":"whatavailable","provides":"java-11-openjdk","version":"11.0.3.7","release":"0.el7_6"}' to python helper
[2019-09-13T17:39:27+00:00] TRACE: got 'java-11-openjdk 1:11.0.3.7-0.el7_6 x86_64' from python helper
[2019-09-13T17:39:27+00:00] TRACE: parsed java-11-openjdk-1:11.0.3.7-0.el7_6.x86_64 from python helper
[2019-09-13T17:39:27+00:00] TRACE: sending '{"action":"versioncompare","versions":["1:11.0.3.7-0.el7_6.x86_64","11.0.3.7-0.el7_6"]}' to python helper
[2019-09-13T17:39:27+00:00] TRACE: got '1' from python helper
[2019-09-13T17:39:27+00:00] TRACE: yum_package[java-11-openjdk] java-11-openjdk 1:11.0.3.7-0.el7_6.x86_64 needs updating to 11.0.3.7-0.el7_6
[2019-09-13T17:39:27+00:00] TRACE: sending '{"action":"whatinstalled","provides":"java-11-openjdk.x86_64"}' to python helper
[2019-09-13T17:39:27+00:00] TRACE: got 'java-11-openjdk 1:11.0.3.7-0.el7_6 x86_64' from python helper
[2019-09-13T17:39:27+00:00] TRACE: parsed java-11-openjdk-1:11.0.3.7-0.el7_6.x86_64 from python helper
[2019-09-13T17:39:27+00:00] TRACE: sending '{"action":"versioncompare","versions":["1:11.0.3.7-0.el7_6.x86_64","1:11.0.3.7-0.el7_6.x86_64"]}' to python helper
[2019-09-13T17:39:27+00:00] TRACE: got '0' from python helper

Although it looks like there's some kind of wonky bug here since with that last line it looks like we've correctly done a versioncompare against the installed and available versions of the package and determined equality and its not at all clear why it then goes and decides to install the package (which is an "install" not and "upgrade" so why if we have anything that satsifies the "whatinstalled" check are we doing anything?

I'm guessing something went wrong with patching the superclass.

@lamont-granquist

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2019

yeah when it works we get a match:

  * yum_package[java-11-openjdk] action install[2019-09-13T17:53:25+00:00] INFO: Processing yum_package[java-11-openjdk] action install ((chef-apply cookbook)::(chef-apply recipe) line 3)
[2019-09-13T17:53:25+00:00] TRACE: Providers for generic yum_package resource enabled on node include: [Chef::Provider::Package::Yum]
[2019-09-13T17:53:25+00:00] TRACE: Provider for action install on resource yum_package[java-11-openjdk] is Chef::Provider::Package::Yum
[2019-09-13T17:53:25+00:00] TRACE: sending '{"action":"whatinstalled","provides":"java-11-openjdk"}' to python helper
[2019-09-13T17:53:25+00:00] TRACE: got 'java-11-openjdk 1:11.0.3.7-0.el7_6 x86_64' from python helper
[2019-09-13T17:53:25+00:00] TRACE: parsed java-11-openjdk-1:11.0.3.7-0.el7_6.x86_64 from python helper
[2019-09-13T17:53:25+00:00] TRACE: sending '{"action":"versioncompare","versions":["1:11.0.3.7-0.el7_6.x86_64","1:11.0.3.7-0.el7_6"]}' to python helper
[2019-09-13T17:53:25+00:00] TRACE: got '0' from python helper
[2019-09-13T17:53:25+00:00] TRACE: sending '{"action":"versioncompare","versions":["1:11.0.3.7-0.el7_6.x86_64","1:11.0.3.7-0.el7_6"]}' to python helper
[2019-09-13T17:53:25+00:00] TRACE: got '0' from python helper
[2019-09-13T17:53:25+00:00] TRACE: yum_package[java-11-openjdk] java-11-openjdk 1:11.0.3.7-0.el7_6.x86_64 satisifies 1:11.0.3.7-0.el7_6 requirement
[2019-09-13T17:53:25+00:00] TRACE: yum_package[java-11-openjdk] is already installed - nothing to do
 (up to date)
[2019-09-13T17:53:25+00:00] DEBUG: Exiting

something is up with that versioncompare, not even sure what that is necessary when we're doing :install.

@lamont-granquist

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2019

Ah I see.

When you specify it in the name with no version check then chef does not do any management of the version since it doesn't parse the version out of the name, that's just a label shipped to the underlying python, so there's no need to check the version.

When you specify the version in the version property you are telling chef what version to install. The version comparison against the installed package is correct, it does not match since the epoch does not match. We can't actually hack that up to do fuzzy matching.

We may need to make the version property stricter to always match epochs, and then provide better error messaging around the version property to force people to match epochs if the available package requires an epoch (although literally trying to do that will probably produce awful code, so we need a solution a bit more elegant than the design in my head right now).

@lamont-granquist

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2019

TL;DR: This is more improper use of Chef than bugginess in Chef. Users need to include epochs in version if the package has an epoch. Chef should probably be stricter about enforcing the use of epochs and should probably error out rather than installing packages that have non-zero epochs. When it errors out it should give a more useful error message that the user may have omitted an epoch and steer them better towards including an epoch in the version. The need to include the epoch in the version is not itself a bug, that is the correct fix for users.

@lamont-granquist lamont-granquist changed the title yum_package don't keep idempotency if set version on Chef 15 yum_package version property needs to be stricter about requiring the epoch Sep 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.