-
Notifications
You must be signed in to change notification settings - Fork 74
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
Split drivers into individual classes #25
Conversation
Will look at this really soon, I'm super crazy thrilled :) |
I should've added a bit more rspec, this isn't correct right now. Rethinking a little... |
shift to loading providers on demand, and maintain a registry of providers
@jkeiser I'm gonna stop now; this works for rackspace at least. Looking forward to your comments! |
|
||
def self.new(driver_url, config) | ||
provider = driver_url.split(':')[1] | ||
require "chef_metal_fog/providers/#{provider.downcase}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're going to follow the pattern of the driver_init, we should probably follow the naming too, for predictability's sake--can you rename providers
to provider_init
?
This is interesting, as it allows someone to make a chef-metal-fog-blah driver. I like :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To avoid duplication of the _init, it's probably worth adding a provider_class_for(provider) method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re provider_init
rather than providers
- I thought about that, but I'm not sure it actually reflects what's going on; the driver_init stuff is just sticking the class name into the list of available classes, whereas the providers are actually doing the work too. Separating the initialization from the provider didn't seem valuable either, I think
and ensure digital ocean returns an empty string
so that drivers can add additional bootstrapping options
@jkeiser I've made all the changes besides the provider_init one… |
Thanks! I got interrupted halfway through, will find my way through the rest shortly. Your point about provider_init makes sense. |
Other than the last comment, this looks really good :) |
I think I like this approach a bit more :) |
Split drivers into individual classes
Update README.md to show how to add per-machine provisioner options
By way of a point of discussion, I've broken out individual drivers into their own classes. This cleans up a lot of pretty epic switches, but I've mostly done it so I can eventually add ohai hints into the correct classes automatically.
This commit also adds a very tiny amount of rspec.