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

add support for "source" attributes to chef-ingredient #152

Open
qubitrenegade opened this issue Jan 3, 2018 · 2 comments
Open

add support for "source" attributes to chef-ingredient #152

qubitrenegade opened this issue Jan 3, 2018 · 2 comments
Labels
Status: Good First Issue An issue ready for a new contributor. Status: Help Wanted An issue that needs help from a contributor.

Comments

@qubitrenegade
Copy link

qubitrenegade commented Jan 3, 2018

Cookbook version

5.5.1

Chef-client version

any (we support 12 and 13 internally)

Platform Details

CentOS (any)

Scenario:

We need to be able to specify the location that the Chef RPMs come from. Supplying a "repo" cookbook is not sufficient as we are not installing from repos.

Steps to Reproduce:

I was able to solve my issue by using edit_resource!, however, this feels like it's prone to failure... and could make debugging hard:

{
  'chef-server' => 'https://some.internal.address/chef-server.rpm',
  'chef-manage' => 'https://some.internal.address/chef-manage.rpm'
}.each do |pkg, src|
  edit_resource!(:chef_ingredient, pkg) do
    package_source source
  end
end

Expected Result:

What I would like to see is a method of passing the source RPM to the appropriate blocks. For instance, I was thinking instead of passing a hash of package => version you could pass a package => config_hash such that:

default['chef-server']['addons'] = {'chef-manage' => '2.5.0', reporting: nil}

Becomes:

default['chef-server']['addons'] = {
  'chef-manage': {
    version: '2.5.0',
    source: 'https://foo.bar/chef-manage.rpm'
  },
  push-jobs: {
    version: '1.2.3',
  },
  reporting: nil
}

Then this could be consumed by updating recipes/addons.rb to

node['chef-server']['addons'].each do |addon, cfg|
 chef_ingredient addon do
   accept_license node['chef-server']['accept_license'] unless node['chef-server']['accept_license'].nil?
   notifies :reconfigure, "chef_ingredient[#{addon}]"
   version cfg['ver'] unless cfg['ver'].nil?
   package_source cfg['src'] unless cfg['src'].nil?
 end
end

I think this approach provides the most obvious method of configuration, however, it comes at a cost of backwards incompatibility...

The other solution I was thinking was we could add some logic to recipes/addons.rb

node['chef-server']['addons'].each do |addon, cfg|
 chef_ingredient addon do
   accept_license node['chef-server']['accept_license'] unless node['chef-server']['accept_license'].nil?
   notifies :reconfigure, "chef_ingredient[#{addon}]"
   if cfg.is_a?(Hash)
     version cfg['ver'] unless cfg['ver'].nil?
     package_source cfg['src'] unless cfg['src'].nil?
    elsif cfg =~ /^(http|https|file):\/\//
      package_source cfg
    elsif cfg =~ /^\d+\.\d+\.\d+/
      version cfg
    end
 end
end

This would be less clean, but would be backwards compatible... I also question if there are other sources, i.e. if you could feed package_source just /path/to/chef-manage.rpm instead of file://path/to/chef-manage.rpm (which would make my regex invalid...)

Actual Result:

I'm more than happy to write the patch and open a pull reuqest, but wanted some feedback from the Chef folks as to which approach would be the more appropriate/most likely to get pulled.

Thanks!
-Q

@tas50
Copy link
Contributor

tas50 commented Jan 16, 2019

I'd certainly be open to a PR that would add just this if you or someone else reading this is interested in this feature.

@qubitrenegade
Copy link
Author

qubitrenegade commented Jan 16, 2019 via email

@tas50 tas50 added Status: Good First Issue An issue ready for a new contributor. Status: Help Wanted An issue that needs help from a contributor. and removed Help: Good First Issue labels Jan 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Good First Issue An issue ready for a new contributor. Status: Help Wanted An issue that needs help from a contributor.
Projects
None yet
Development

No branches or pull requests

2 participants