You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
Something like that.
The text was updated successfully, but these errors were encountered: