Difference between revisions of "Talk/Pootle maintenance plan"

Revision as of 20:42, 22 December 2012

Pootle server maintenance proposal

The pootle server is currently running version 2.1.6, in a not very well documented configuration (svn contains information about the vm, but not the pootle setup). The database has not been optimized/tuned for a very long period of time.

The performance is today in a state, where it is very hard to do serious work on the server. The version is no longer maintained by the pootle project (current beta version is 2.5).

The hooks and setup have changes considerably from 2.1 to 2.5, and therefore is developing extensions not a real option.

The AOO project is currently developing a new set of l10n tools to replace the current highly manual workflow. The goal of the new tools are to translation easier, guarantee a better quality and reduce the number of manual intervention needed (meaning that time between a translation is made and until a build can be made is highly reduced). These tools will interface with the pootle server, and the changed workflow will require configuration changes.

As a consequence it is needed to upgrade the pootle server, and get all configuration changes documented.

The upgrade will NOT have any influence on the data (po files) in the system, but will enable projects like AOO to add much needed extensions.

Furthermore there is a open issue INFRA-4964, that should be solved at the same time.

Pootle Server usage

The pootle server is not only used by AOO, but also by other projects, and in general open to all apache projects.

As a consequence upgrades and other changes must be coordinated with the projects actively using the service.

Goal

The goal is to:

• Upgrade Pootle server to version 2.5 and make it easier maintainable.
• Tune/optimize DB using pootle project guidelines to get a better performance
• Tune apache and VM to enhance the performance
• Start a regular maintenance of the DB, to ensure constant performance

for AOO (all changes done in cooperation with pootle project):

• Enable/Extend the Pootle server to deal directly with SVN (avoid manual copy steps)
• Extend Pootle server to provide extra review controls, like those already present in po2oo.
• Extend Pootle server to allow bulk download/upload (e.g. 1 zip for one language).

Plan

1. Research the current setup
2. Backup the current setup (combination of backup/svn)
3. Get consensus from AOO-PM, jMeter-PM and Infra
4. Install/Configure the new pootle server on a local PC (offline)
5. For testing the new version there are 3 possibilities:
   1. Test the new pootle server publicly on 1 VM, with 2 pootle servers
      1. Add a new DNS target: translate_test.apache.org, so it easier to test new versions
      2. configure trafficserver, apache and pootle to accept 2 versions on same server
   2. Test the new pootle server publicly on 2 VM, one with prod. and one with test
      1. Add new VM and DNS target: translate_test.apache.org, so it easier to test new versions
      2. standard configure trafficserver, apache and pootle
   3. Upgrade the prod. pootle server without public test
      1. No special work is needed

The first version is recommended.

for test system:

1. Install new version on test, while documenting all changes
2. Copy a partial database for test purpose
3. Let all projects test the new version
4. Vote across projects for a move to production
5. Move version 2.5 to production

for direct upgrade:

1. backup database
2. Install new version on top of old version (new directory), while documenting all changes
3. upgrade database
4. Let all projects test the new version
5. Vote across projects for a move to production
6. Move version 2.5 to production

maintenance:

1. Do database tuning on production
2. Enhance interface to SVN (in cooperation with pootle project) (first test, then prod)
3. Enhance download interface (solely test, then pootle project and wait for new release)

People

jani will do the work except 3), with gmcdonald doing review of the work.

the DNS work is done by infra through a JIRA.

After the initial installation, jani will do regular maintenance.

This plan will be sent to all the PMCs of all involved projects for comments, and the server will NOT be changed until positive feed back is received.

This page will be kept updated with the progress.

Jan I.