Bring Your Own Packages #62

[thenoid]

Provides the ability to "Bring Your Own Packages" for companies where direct connections to the internet are not possible - as referenced in #62

• Setting node['chef-ingredient']['byop'] == true skips the recipe inclusion of apt-chef/yum-chef and any configuration that occurs.

[thenoid]

Hmmm that rubocop failure is from a line I didn't modify ={

[sersut]

@thenoid rather than introducing a new flag, does package_source attribute work for you? If you can get a package on the node, you can use this attribute to install it locally and repo stuff is not going to be invoked when using this attribute.

[chilicheech]

since this is used in multiple places a helper function could be used instead, called byop? maybe..

[thenoid]

Hmm, I think worrying about copying RPMS to a host locally defeats what i'm going for with this PR, which is primarily that chef-ingredient shouldn't assume that a host is directly connected to the internet.

It's should either have a flag, such as byop, or relegate configuration of yum/apt to outside the cookbook. People know how there systems are/should be configured.

I just wasn't sure how people would feel if i submitted a PR that stripped all the yum/apt stuff out....call me a nervous pull-requester ;)

[chilicheech]

i have to agree with @thenoid that copying RPMs over defeats the purpose of this PR. i created pr #69 to allow you to define attributes for the yum-chef cookbook to point to your internal yum repo as an alternative.

[thenoid]

Chef-ingredient should focus installing ingredients
Yum-chef should focus on setting up the external repo

and if a soup-to-nuts solution that should wrap the two together.

[chilicheech]

chef-ingredient allows you to specify what channel to install from, either stable or current. pr #69 allows you to install from a custom channel. you would then set the appropriate node attributes for the yum-chef cookbook to create that yum repo file.

yum-chef does exactly as you described. just need chef-ingredient to support the custom channel.

with that in mind, i also like the idea of skipping the yum-chef cookbook entirely, giving you the option of setting up the yum repo file yourself beforehand.

[thenoid]

I like that idea too [of disabling entirely] !

cause #69 doesn't address my concern fully. I don't want/need to specify a custom URL, we use spacewalk/satellite/katello/satellite6 (and there are other products out there) for all our RPMS. So the moment this code

include_recipe "yum-chef::#{recipe_name}"

is run without condition my heart fills with sadness!

This is the second large enterprise i've worked ( first being healthcare, second being security) where hosts aren't allowed direct access to the internet. So for a cookbook that is included as part of core component installers, push-jobs for example, that forcefully configures yum, which intern breaks yum, which intern breaks chef is no es bueno.

I do get the want/need to have a magic cookbook that uses chef to configure chef so you can chef the chef - yo dawg memes for days - but perhaps that should be part of something larger and chef-ingredient should do one thing well?

[sersut]

Thanks for thinking about this problem @thenoid & @chilicheech.

I think the right solution for this will be to have a new attribute for this cookbooks called custom_repo_setup_recipe. When set chef-ingredient will behave as such:

if node['chef-ingredient']['custom_repo_setup_recipe']
  include_recipe node['chef-ingredient']['custom_repo_setup_recipe']
else
  # Enable the required apt-repository.
  include_recipe "apt-chef::#{new_resource.channel}"

  # Pin it so that product can only be installed from its own channel
  apt_preference ingredient_package_name do
    pin "release o=https://packagecloud.io/chef/#{new_resource.channel}"
    pin_priority '900'
  end
end

We need to keep in mind that "custom" means different things to different people. So we can not assume a shape or form of repo setup when we are in custom repo setup mode.

We also need to make another minor change to the usage of new_resource.options in the package resource that installs the products. We need to make it so that if you have specified this property we should not add any repo locking logic to it. But if it is not set we should use the required repo locking options. This way the default will work if you are connected to internet and if you are setting up a custom thing you will be able to configure all the aspects of it.

Let me know what you guys think about this.

[chilicheech]

@sersut seems like that will work for my use case. There may also be a use case for skipping setting up the yum repo altogether because it's already set up.

As for the repo locking, it is necessary for my use cases, but what you outlined will work because then I can set the locking in the options property.

Maybe a new property called lock_repo that optionally takes in the ID/name of the repo to lock to would be more user friendly versus passing it all via options. --> If you're using a custom repo setup and lock_repo is set/not nil then prepend the options with locking.. or something in those lines.

Thanks for looking into this.

[sersut]

In the default case we do not want to make locking the repos optional. Because that would be problematic if one is installing some products (e.g. chef-server) from stable channel and some products (e.g. chef-manage) form current channel.

Also we would like the keep the API of chef-ingredient as basic as possible. Since custom locking functionality would be achievable via options property I do not think we should introduce another way of doing it 😄

Thanks to you for looking into this 😄

[sersut]

Replaced by #74