RFC: all new CloudLaunch

[afgane]

The process of launching Galaxy cloud instances has gone through several iterations over the past few years, starting with the manual process via the cloud’s web dashboard to the current CloudLaunch web app. This evolution was largely driven by the goal of making the launch process easier and quicker. Going forward, we have several improvements in mind that are summarized here in hope they get assessed and evaluated by a larger community with possibly new improvements suggested.

• Unify launch options: combine the Docker offering with the cloud offering and further enhance it with the Flavor Generator. We should allow users to launch Galaxy instances on a range of infrastructures, using different technologies from a single location/app. Namely, it should be possible to launch a cloud cluster on any one of a range of cloud providers as well as a Docker instance on a cloud container service or a cluster that supports container scheduling. Further, allow users to optionally build their own flavors using the app’s UI. Given the launcher app can already provision various resources, add support to automatically supply the infrastructure required to build a flavor. The user will then have an option to store, launch, and share their flavors.
• Implement a REST API: follow modern web app design and create a full-featured API that any UI can then leverage. Most likely, implement this using the Django REST framework.
• Allow user login: this will allow users to see all of their deployments regardless of when they were launched. For the cloud cluster case, it will also be possible to delete the clusters without needing to launch them first. Optionally, we can add the ability for users to store their cloud creds (at least the access key).
• Start with a fresh codebase: the current CloudLaunch app has been around for a while and has gone through a name change that has not been consistently updated in the codebase. Django v1.3 is still used (v1.9 is expected any day now). With the availability of Cloudbridge, much of the cloud-related code will need to be changed. It seems that starting with a blank slate and reusing code snippets (e.g., the model) will be easier, quicker, and lead to better code structure than going through the code migration process. Along these lines, develop this using Python 3.5 and drop support for Heroku.

Anyone, please feel free to comment on this topic but explicitly pinging @bgruening @nuwang @dannon @wookoouk.