Closed petems closed 9 years ago
It's unlikely that we would merge this without finding an external maintainer, since we currently have no plans for internal use of DO. We do not want to include code that we do not have means of testing.
Are you willing to be maintainer if you get this working?
I'm ok with that, however I had an idea:
I actually had another plan that I was thinking about posting on puppet-dev: this and #512 and other non-Pupptlabs directly related stuff maintained in a separate codebase as extensions that are maintained by the community.
Saves PL having to maintain stuff you don't actually use and decreases the feedback loop to get external features done.
Which sounds better?
I think that that could be a reasonable route, though we don't currently have the best solution for adding pluggable content to beaker (you can use a --helper to add libraries at runtime). It would mean that we would not be helping you with style, review or testing - but that is appropriate if we don't have anything to test it on. :)
For myself, I created another hypervisor for managing F5 devices. I put the provider in spec/fixtures/lib/beaker/hypervisors/f5.rb
and added this to my spec/spec_helper_acceptance.rb
:
# Add the fixtures lib dir to RUBYLIB
$:.unshift File.join(File.dirname(__FILE__), 'fixtures', 'lib')
require 'beaker-rspec'
require 'beaker/hypervisor/f5' #from spec/fixtures/lib
The f5 hypervisor inherits Beaker::Hypervisor::AwsSdk
and overrides the bits that don't work on it.
Not super portable, but extension modules (say, beaker-digitalocean
and beaker-freebsd
) could totally be made.
@hunner Awesome! I'll see if I can get a proof of concept going :+1:
Any progress here?
I did some basic spiking over the weekend but nothing solid.
Ok, I've got two implementations:
One uses Fog in it's own hypervisor, works fine, I'm fixing up the commits now.
However, after I was done I realised that a generic Fog handler would be wayyyyyyy better and extendable. As Fog has support for a lot of cloud providers, it means we could just use one provider rather than having to create a new hypervisor each time someone has a new VPS they want to add.
From an internal discussion we will not be supporting additional hypervisors that we do not use internally. We are willing to looking at the vagrant-fog work as a means to easier use of additional virtualization options for others. Closing, wontfix.
Ended up being implemented in: https://github.com/petems/beaker-fog
Will write up a Wiki guide on how to do it in the future, will probably mean we can close up a lot of the PR's to add in new Hypervisors that Puppetlabs is not going to use :+1:
DO instances are fairly cheap and easy to setup, would make a good hypervisor for Beaker tests.
Probably using API hooks from https://github.com/boats/barge
I'll give it a go and see how much I can pull in from the other hypervisor code :+1: