GSoC 2019: Episode 1 — Introduction & Implementing Support for The ‘backend’ Property
Hi folks,
It’s been a while since I published my last Medium article about the epilogue of My GSoC 2018 project. Today, I’m writing my first medium article about my GSoC 2019 project. First, let me start with an introduction to the project.
Gemstash
Basically, Gemstash is a cache for remote servers such as https://rubygems.org. Gemstash can also be used as a private gem source.
So what’s the problem…?
Presently, Gemstash is only able to store private gems directly on disk. That’s fine for relatively small setups but becomes a problem when users want to run multiple web servers for redundancy, or need to store more gems than easily fit on a small server’s hard disk.
My project is to…
Extend Gemstash to support storing gems in other places. At a minimum, that would mean building a system for multiple backends and implementing the existing local disk storage as one of those backends. Ideally, it would also include implementing a backend for storing private gems in S3, to demonstrate that the backends system works for different kinds of backends.
Enough with the introduction…
Now l’ll walk you through the implementation of the very first task. All the changes I do during the GSoC period can be found on my fork of the Gemstash project at https://github.com/gayashanbc/gemstash. :)
Step 1: Introducing a ‘backend’ property to the configuration file
The goal of introducing a‘backend’ property is to keep track of which backend (i.e. local disk, AWS S3, and etc.) is currently being used, since eventually Gemstash will have support for multiple backends.
Step 2: Giving the user the ability to change the ‘backend’ property dynamically
With the ‘backend’ property being introduced, it’s vital to provide a mechanism to Gemstash which allows the user to select the backend to be used when caching gems. This can be facilitated through the the following command.
gemstash setup [ — redo]
So far, I have managed to implement the above two steps. I have opened a pull request containing these changes, which can be found at https://github.com/rubygems/gemstash/pull/242
So, what’s next..?
The next step would be to implement an action which gets triggered once the backend property is changed. For an example, once the backend is changed to AWS S3, Gemstash should ask for the S3 bucket to be used from the user, as well as request/check authorization to use the specified S3 bucket. Before implementing this task, all the methods (e.g. programmatic access, AWS CLI, and etc.) that are available to authorize access to AWS have to be critically evaluated.
So that’s a wrap for today. Let’s meet again with the next episode of my GSoC 2019 project.
