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

Need to support mixlib-install #40

Closed
lamont-granquist opened this issue Sep 9, 2015 · 1 comment
Closed

Need to support mixlib-install #40

lamont-granquist opened this issue Sep 9, 2015 · 1 comment

Comments

@lamont-granquist
Copy link

This needs to support mixlib-install and omnitruck for non-ubuntu/non-centos installs of the client. The way this should be implemented should not require any knowledge on the part of the user to override the provider based on the platform they are on. In other words, requiring the user to pass a provider argument with a ruby class would be failure.

The difficulty here is that this is written as a single resource where the type of thing to be managed is in the name argument of the resource. If this was implemented as chef_client_ingredient we could use the provider resolver to trivially switch that label between chef_client_ingredient_packagecloud and chef_client_ingredient_omnitruck resources+providers.

What we probably needs to happen is that the chef_ingredient provider needs to select a handler for either packagecloud or omnitruck based on the name it is passed and the platform_family of the box it is running on. Then it needs to delegate its actions to that handler class (the handler class should likely not inherit from Chef::Provider, it should use composition correctly).

There's other ways to do this, using a base class and inheritance, but the service provider in core chef shows how bad of a road that is to follow.

Technically the provider resolver also passes the resource in through the #supports? method call so you could switch on the name of the resource there and only pick the client installs in the omnitruck install provider, but that is going to be way messy into the internals of the provider resolver. I wouldn't recommend it.

Sketch of how the provider code should look:

class Chef::Provider::ChefIngredient < Chef::Provider
  extend Forwardable
  def_delegators @handler, :action_install, :action_upgrade, :action_uninstall, :action_remove
  def initialize(new_resource, run_context)
    if new_resource.name == "client" && !%w{debian, rhel}.includes?(node[:platform_family])
      @handler = ChefIngredient::Handler::MixlibInstall.new(new_resource)
    else
      @handler = ChefIngredient::Handler::PackageCloud.new(new_resource)
    end
  end
end

Something like that.

@sersut
Copy link
Contributor

sersut commented Dec 9, 2015

This is mostly done with #73.

@sersut sersut closed this as completed Dec 9, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants