SLES: Chef-server no longer installs with version 2.1.0

[vinyar]

Cookbook version

2.1.0

Chef-client version

12.19.36

Platform Details

AME="SLES"
VERSION="12-SP2"
VERSION_ID="12.2"
PRETTY_NAME="SUSE Linux Enterprise Server 12 SP2"
ID="sles"

Scenario:

Install chef-server using chef-ingredient wrapper on Suse.
This was working last night with ingredients version 2.0.5

Steps to Reproduce:

take dependency of latest chef-ingredient cookbook: 2.1.0
define the following resource:

chef_server node['chef_server']['fqdn'] do
  version :latest
  config <<-EOS
api_fqdn '#{node['chef_server']['fqdn']}'
oc_id['applications'] = {
  "supermarket"=>{"redirect_uri"=>"https://supermarket.services.com/auth/chef_oauth2/callback"}
}
postgresql['username'] = 'chefpsql'
postgresql['db_superuser'] = 'chefpsql'
EOS
  platform 'el'
  platform_version '6'
  addons manage: { version: '2.4.3', config: '', platform: 'el', platform_version: '6' },
         :"push-jobs-server" => { version: '2.1.0', config: '', platform: 'el', platform_version: '6' }
  accept_license true
  #data_collector_url 'https://automate.services.com/data-collector/v0/' if search(:node, 'name:automate-centos-68', filter_result: { 'name' => ['name'] }) # ~FC003
end

Expected Result:

success

Actual Result:

https://gist.github.com/vinyar/3e4bdaa8ce0ee7850ebb473fcbbca887

[wrightp]

@vinyar Try removing the platform and platform_version properties from the resource definition. A change was made to allow SUSE and SLES to properly resolve their respective packages.

There is a bug still because I would not have expected the platform name to be sles in this case since el was set. I'll look into this.

@shain when you get a chance please look at this too.

[vinyar]

@wrightp @scotthain tried commenting out the two params. Same issue
I updated the gist with new output.
lmk if you need stacktraces or other info.

[wrightp]

The second output from gist https://gist.github.com/vinyar/3e4bdaa8ce0ee7850ebb473fcbbca887#file-no-specifications-rb looks like an even older version of chef-ingredient...

[wrightp]

@vinyar Could you humor me and clear your cookbook cache and run it?

[vinyar]

@wrightp https://gist.github.com/vinyar/3e4bdaa8ce0ee7850ebb473fcbbca887#gistcomment-2099777

updated gist with 3rd file. It got further this time. I had a dependency on both chef-stack and chef-ingredient, which likely caused issued.. I removed chef-stack. This time converge broke on manage with the same 'cant find package' issue.

[wrightp]

@vinyar That same error would be expected for addons. The addons use the same underlying chef_ingredient logic. The platform and platform_version detection for SLES/SUSE is the fix that was released as part of 2.1. The correct thing to do is to allow chef-ingredient to auto-detected the platform.

This should have been seemless for anyone still setting el if not for the bug you reported. I'll get a patch release out once I determine why the platform was being remapped when it shouldn't have.

[vinyar]

Durrr that makes sense. Nuked the params, but still hitting the snag on mixlib
Same snag when i just do chef-server-ctl install chef-manage

        chef_ingredient("manage") do
               action [:upgrade]
               retries 0
               retry_delay 2
               default_guard_interpreter :default
               declared_type :chef_ingredient
               cookbook_name "ford_pipeline_build"
               channel :stable
               version :latest
               config ""
               accept_license true
               product_name "manage"
               platform_version "12.2"
               platform "suse"
               architecture "x86_64"
             end
----
 Mixlib::Install::Backend::ArtifactsNotFound
           -------------------------------------------
           chef_ingredient[manage] (/tmp/cookbooks/chef-ingredient/resources/server.rb line 60) had an error: Mixlib::Install::Backend::ArtifactsNotFound: No artifacts found matching criteria.
             product name: manage
             channel: stable
             version: latest
             platform: sles
             platform version: 12
             architecture: x86_64
             compatibility mode: false

[wrightp]

It looks like the addons may not be honoring the set platform options, but rather the chef_server resource platform settings. That would also be a bug. It's that the case, I will write up a new issue and assign it to a member of the chef-ingredient team.

[wrightp]

Note: there is no SLES chef-manage package. So technically, el would have to be set. Again, looks like a bug there.

[wrightp]

Here is the offending code.

https://github.com/chef-cookbooks/chef-ingredient/blob/master/libraries/helpers.rb#L331-L332

chef-manage does not have a sles package, so the new code will force sles when in fact we need to override chef-manage to use el.

@schisamo @scotthain
Couple things.
a) this is case where I don't like defaulting property values. We obviously need to mutate the values in certain cases, but we should honor overridden values. For example,
On a SUSE platform...

• if user sets platform to el it should pass through as el (technically packages should still work)
• if user sets platform to rhel it should fix up as el (technically packages should still work)
• if user does not set platform it should use Ohai detection logic which will set suse and will be fixed up as sles (desired behavior)
• if user sets platform to ubuntu it should pass through as ubuntu (this will fail)

b) Expectations are misaligned:

• what should happen in terms of suse platforms?
• should the expectation be that all products have sles platform packages?
• Should we only force remap for certain products?

Note, I will ask the author to look into the addons platform issue which is unrelated...

[wrightp]

We've reverted the omnibus logic and reinstated the previous functionality in 2.1.1