Reevaluate use of Fog

[sethboyles]

Impetus

As part of our efforts to upgrade to Ruby 3 and to upgrade the fog-aws gem to enable IMDSv2, we discovered a lot of inter-compatibility issues between the various fog gems.

For example, here are a few contributions we had to make or are in the process of making to ensure fog is working for our purposes:

• Don't escape safe characters in keys fog/fog-local#25
• Update Compute to use provider::service syntax fog/fog-aliyun#155
• Upgrade mime-types to 3.0 fog/fog-azure-rm#439

And we will likely have to contribute to fog/fog-google#422 if it does not move forward.

Not to mention the CF-specific branch of fog-azure-rm that we have been maintaining for years.

The particular gems are not being very actively maintained and there is not much effort to maintain inter-compatibility between them by maintainers.

In addition, we primarily (only?) use Fog to interface with S3 compatible blobstores, while the gems are designed to interface with other services like compute, dns, etc. If we find ourself needing to help maintain these gems, we are taking on the burden maintenance for services we do not use.

Alternative solutions

Since we primarily interface with blobstores, could we have a limited custom solution that only implements the actions we need.

Could we utilize individual gems that are actually created by providers:

https://github.com/Azure/azure-storage-ruby
https://github.com/googleapis/google-cloud-ruby/tree/main/google-cloud-storage
https://github.com/aws/aws-sdk-ruby

Could we somehow utilize ActiveStorage? It seems like it's baked into ActiveRecord, which is unfortunate, but maybe we can extract some of the abstractions they use around file uploads and other actions.

Reasons not to do

Could be a lot of work

[sethboyles]

cc @tjvman

[geemus]

Hey, sorry to hear it has come to that. I try to still support some of the central gems, but many were built and supported by others and not services that I had any context or usage of myself. I can certainly try to help address individual issues, but I may lack the context to solve the whole problem and it seems as though some of those that were originally more engaged have moved on (I had left it to them, perhaps overly optimistically, to take care of).

[ezr-ondrej]

Hi, just my 2c, but we are in exactly the same situation with @theforeman project (just using only the compute portion of the fog libraries). I believe this is quite a common issue for projects that really try to use fog for the goal it originally set for itself. Being the unifying library for all the cloud providers is just not accomplished.

I don't mean to criticise, the goal is a huge one and I believe that the decline is also caused by Rails loosing its popularity and thus there is not enough maintainers generated for the fog libraries. But unless someone refreshes the idea of fog and manages to refresh the libraries, it will just die. Tho if someone opens up a topic about it somewhere, we will gladly join the discussion and we could throw a bit of resources in the pool. Tho we'd need to see that there is a hope, but seeing we are not the only one, there might be others in similar situation and it might be possible to get the provider libraries in shape if someone
manages to coordinate the efforts.

[geemus]

Yeah, I realized the goal was a bit on the large side, especially for me to do by myself. I can certainly offer some help in the coordination side of things, but I think others who are more actively using it are going to have a better/easier time on the specifics. I think, for instance, narrowing down the set of providers that are still actively used (and perhaps deprecating or otherwise clearing out some of the others) might be helpful for us. I've also been thinking that finishing splitting out the providers from fog/fog would be good to make it easier to sunset some and maintain others (based on which services are still around and have enough of a critical mass of interest to keep them going). Right now between foreman and cloudfoundry, for instance, I don't know for sure how many total providers we are talking about and how similar the lists are. So figuring that out as a starting point might help us at least calibrate what the scope/scale of the problem we are talking about would be. Unifying 5-8 providers in a meaningful way is, after all, a lot more tenable than unifying every provider there was or might be.

[Gerg]

These are the fog gems that cloud_controller_ng currently uses:

cloud_controller_ng/Gemfile

Lines 58 to 64 in 58eaf84

	gem 'fog-aliyun'
	gem 'fog-aws'
	gem 'fog-azure-rm', git: 'https://github.com/fog/fog-azure-rm.git', branch: 'fog-arm-cf'
	gem 'fog-google', '~> 1.7.1'
	gem 'fog-local'
	gem 'fog-openstack'
	gem 'fog-core', '~> 2.1.2'

[sethboyles]

Thanks for chiming in @geemus and @ezr-ondrej!

Right now we are certainly in favor of finding a way for Fog to work for us long term rather than recreate a lot of the functionality Fog provides. And if we can work out a plan that seems like will provide long term stability for the fog gems, we are willing to contribute some resources towards making that happen.

I think narrowing the scope of supported providers is a great idea. One idea I had was adding a test/GithubAction or something that checked that the limited scope of providers can be bundled together.

Another thought I had was potentially splitting out compute/storage/etc for each provider into different gems. So you would have fog-google-storage and fog-google-compute, for example. On one hand it might exacerbate some inter-compatibility issues, but for us it would alleviate some concerns we have about having the burden of updating the provider gems falling to us in the future. We would be more comfortable knowing that if we ran into issues in the future, we would only have to update the storage portions. Of course, this sounds like more work up-front.

[ezr-ondrej]

Well I think that we should find a way to gain a bit more friction for this. Would a fog-core issue be a good place for such a discourse? Or do we have a better place for such discussion?

[sethboyles]

That makes sense to me.

[geemus]

Yeah, a github action or something similar makes sense, though I'm not sure about where it should live. We could make a distinct repo potentially, since it doesn't quite fit in other places yet.

Narrowing the scope a bit to at least focus things sounds good. I was also thinking about how it would be good to review some and kind of move them into different tiers or something to indicate their level of activity/maintenance/etc. I think there may be some that point to services that no longer exist too, so probably some deprecation possibilities. I just haven't had the bandwidth to chase them all down (and in many cases they weren't necessarilly/obviously causing problems, so it was easy to let them be).

Breaking out gems is interesting. Continuing/concluding breaking out everything from fog/fog in particular would probably be good. I worry that breaking out storage/compute would cause even more problems (at least from the maintenance side), though I certainly empathize with the pain the current setup is causing on the consumption side.

I also wondered if we could centralize where some of the core dependencies come from to help with this, though maybe that would lead to other problems.

I'm fine with a fog-core issue to continue this discussion. It would likely have a bit better visibility there and perhaps some of the other maintainers or interested parties may have further ideas and opinions.

[sethboyles]

Ok, we can continue the discussion here: fog/fog-core#276

[geemus]

Sounds good, thanks!