Allow podmins to specify fog provider name

[RomanHargrave]

As diaspora uses fog to provide S3/object storage support, it should be relatively straightforward to support any of fog's built-in providers. Enabling this would be useful to podmins that want to run diaspora entirely using services from a provider such as DigitalOcean or Linode - both of whom offer S3 compatible object storage services, both of which are available as fog-X provider gems.

In order to do this, the following code maintenance tasks would need to be completed (as far as I can tell)

• Add a provider option to the config under environment.s3 (with the example being set to AWS)
• Pass the provider option to fog wherever fog parameters are specific (asset_sync and CarrierWave init)
• Update the migrations:upload_photos_to_s3 rake task to use fog instead of the AWS SDK

Additionally, a note should be added to the configuration file and possibly the pertinent diaspora wiki page to inform users that they will need to manually install the provider gem for their host of choice (for Linode, this would be fog-linode).

[jhass]

So, my biggest concern with this is, as you correctly noticed, this either requires us to install all the fog providers and bloat the dependencies immensely, or have the podmins modify their Gemfile, which is something we'd really like to avoid because we've seen it go wrong oh so many times. A third option would be to add optional bundler groups for each fog provider, like we do for MySQL and PostgreSQL support, but that seems like a nightmare to maintain.

Lastly, I wonder, are the configuration options for the different fog providers even that uniform that we could reasonably map them out into our configuration?

Given all of this, I wonder if we shouldn't leave this to people that are savvy enough to patch the code to use the provider they want, which would also intersect with the group of people I trust to touch the Gemfile without messing it up.

[RomanHargrave]

@jhass I think that as long as administrators install the gem, they won't have to add it to the Gemfile (it just needs to be in the require path). As for the configuration options, that - to me - is more concerning.

Rather than implement logic to handle figuring out the configuration parameters for a given provider, perhaps simply passing the environment.s3 section wholesale to fog would work well, allowing the more savvy podmins to pass the parameters required by a provider without patching. Compatibility with the old configuration layout could be maintained by checking for the presence of the secret, and key fields beneath environment.s3 and dealing as such. While not idea this would allow for using other providers without having to maintain out-of-tree changes across updates (though this really wouldn't be terribly difficult due to git).

[jhass]

The entire point of bundler pretty much is that you cannot load gems that don't appear in Gemfile.lock, or even other versions of them :) It actively prohibits that by disabling the normal loading mechanisms rubygems provides.

[RomanHargrave]

@jhass true