Difference between revisions of "Infrastructure Transition Plan"
(add some status notes.) |
|||
| Line 3: | Line 3: | ||
= Hosting Provider = | = Hosting Provider = | ||
| − | + | Because OSUOSL needs to retain their non-commercial status, we are unable to obtain an SLA through them, so we will be looking at other hosting options. See grid at bottom of page. | |
| − | + | The proposed hosting solution is to use our selected provider 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 our other hosted services. | |
| − | + | 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. | 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. | ||
Revision as of 08:45, 19 October 2006
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
Because OSUOSL needs to retain their non-commercial status, we are unable to obtain an SLA through them, so we will be looking at other hosting options. See grid at bottom of page.
The proposed hosting solution is to use our selected provider 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 our other hosted services.
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.
Key Milestones
Timelines are highly dependent on the resources available. The table, below, is a very simple example based on using volunteers. The values are somewhat meaningless except that they show the general timelines required to meet the year-end migration deadline. At present, timelines depend ultimately on the capacity of SAC and WebCom. When the Executive Director (E.D.) begins, there will be more dedicated focus on successful implementation within these timelines.
The hiring of a dedicated systems administrator will help set up, test and migrate services more quickly. The following table outlines a rough potential timeline, assuming the help of a sysadmin and E.D.
- Approve service provider - 22-Sep-06
- Contract set up for sys. admin - 29-Sep-06
- Finetune migration plan - 29-Sep-06
- Approve migration plan - 29-Sep-06
- Server purchase and set up - 6-Oct-06
- Install tools - 13-Oct-06
- Migrate content & services complete - 30-Nov-06
Status Notes
- Board has approved overall plan, and authorized purchase of a server for OSL.
- Jason Birch leading server specification and purchase activity.
- Members of Indictrans team available now to work on Drupal Portal work, notably the Membership Application, and Service Provider Directory as well as a more general drupal front end for managing the ldap groups for users.
- Preliminary BuildBot Configuration build and smoke tests rolled out at telascience by Mateusz Loskot.