Infrastructure Transition Plan
This is a reduced form of the Translation Plan available at https://board.osgeo.org/servlets/GetAttachment?list=board&msgId=22236&attachId=2.
Hosting Provider
The proposed hosting solution is to use OSL for hosting most of the components listed in the Tool Requirements section below: web site, code repository, wiki, mailing lists, bug tracker. The additional items could be moved there as well, but some movement has already been made to host them on Telascience services which seems like a good use of those resources and fits with the goals of Telascience as a group. It is proposed to use Telascience hardware as the primary North American mirror for offsite backups of OSL hosted services.
There are several benefits to going with OSL: they have staff available to aid in hosting administration, they support many other open source projects, they are flexible, have good communication infrastructure and are interested in helping provide a solution for us.
We would purchase a server through them, for hosting in their data center. It is proposed that we hire a systems administrator for a few months to aid in setting up our services and help migrate content over to this new service. This will help address the tight timelines that we have for migrating by the end of the calendar year. Afterward, we would have an administrator on retainer (e.g. ¼ time) to help maintain our system over time. It will be critical to maintain a Service Level Agreement (SLA) with OSL to guarantee access to engineering resources and the resolution of issues in a timely manner. Much of the day-to-day work would be maintained by volunteers through WebCom and SAC.
Proposed Tools
The following appear in their approximate order of priority and implementation.
- DNS Management - tool undecided - location undecided - Outsource DNS services to third party, set up temp DNS name to work on during migration (e.g. osgeo.net)
- Mailing Lists - Mailman - OSL - Need to ensure migration of archives. Use of forums needs to be assessed.
- Security and Authentication - OpenLDAP - OSL - Note we also need to get the SSL certificate for osgeo.org (and perhaps osgeo.net). osgeo.org is currently held by CN.
- Source Code Control - SVN - OSL - Need to ensure migration of history.
- Web Pages - Drupal CMS - OSL - WebCom supports movement to this CMS and has experience maintaining it. Serves as a powerful base for other web reporting and membership management needs.
- Wiki - mediaWiki - OSL - Move from Terrestris.de to OSL. Some types of content could be migrated into the CMS for more official management. Not high priority is working well. We will also likely want some project specific wiki instances (eg. for GDAL).
- Bug / Issue Tracking - Trac - OSL - Trac is proposed as the bug/issue tracking tool. It has several methods for tying intoother parts of the infrastructure, e.g. SVN and other features. Unclear how easy to extract from current CN tracker.
- Download Server (source, binary, data files) - TBD - OSL & Telascience - Code on OSL. Data on Telascience. Will need to compute our required bandwith needs.
- Automated build and smoke test - Cruise Control and BuildBot - Various processes currently in use, unclear on amount of work to migrate.
- Demo site - n/a - Telascience - Build demonstration apps to run.
- IRC - n/a - freenode.net - Become an official Freenode project and make donation for use of services. Move logging of IRC from QGIS host to OSL.
- Language Translation Tools - TBD - TBD
- Communication servers - TBD - TBD
Integration
One question about these services is how tightly we will be able to draw them together. For example, it will be ideal to bring together CMS, project issue tracking and mailing lists. We will also want to have them all be searchable and feeding into each other easily. Initially this will be done through the CMS as much as possible. However, in the longer term a management framework such as Gforge may need to be considered. Having multi-project management tools through one common set of services is an ideal end goal, providing an infrastructure that makes code easier to track, documentation easier to contribute, people easier to communicate with, and software easier to repackage.
The other side to the migration is that of bringing more of the OSGeo projects under one roof; to provide a common presence that will enhance "branding" and co-distribution. To date, most projects have chosen to stay with their current (external) infrastructure because of effort required or comfort with their stack of tools. It is hoped that the proposed ideas can be somewhat debated and a happy medium for all projects can be found. It is critical for other projects (that will come on board later) to have the option of moving to a well supported infrastructure as in the proposal. The collective volunteer effort in maintaining their project's systems could be reduced by introducing further cross-project efficiencies.
Persistence of previous services (URLs, protocols, etc.) is an important feature to aim for, particularly for documentation, list archives and distribution facilities - anything that is indexed by a search engine. A mapping between projects' existing services and new ones needs to be maintained wherever possible. Having a thoughtful plan for this will help to make migration into or out of OSGeo hosted infrastructure less painful.