Available Fabric commands¶

New in version 2.5: Starting in this release, Pootle includes Fabric deployment scripts.

Introduction¶

The sample Fabric scripts provide several commands that you can use to easily deploy your Pootle site.

Note

Most of the examples in this section will use the production environment, but remember that other environments can be used as well.

Please read first the How to run Fabric commands section in order to know how this commands can be run. Reading the Typical Usage Example section might be helpful as well.

Available commands¶

bootstrap¶

This command:

Creates the required directories, asking to remove them first if they already exist
Creates a virtual environment (virtualenv) and activates it
Clones the Pootle repository from GitHub
Checks out the specified branch, using master if no branch is specified
Installs the deployment requirements as listed in requirements/, including the base requirements as well

Note

While running it may ask for the remote server root password, or more likely the sudo password, which is the standard password for the remote user configured in the environment.

Note

Changed in version 2.5.1: Added support for bootstrapping from a given branch on Pootle repository.

Examples:

$ fab production bootstrap  # Call that will use the default 'master' branch
$ fab production:branch=stable/2.5.0 bootstrap  # Call which provides a branch

compile_translations¶

This command:

Compiles the MO files for Pootle translations

Examples:

$ fab production compile_translations

create_db¶

New in version 2.5.1.

This command:

Creates a new blank database using the settings provided to Fabric in the chosen environment

Note

While running it may ask for the remote server root password or the sudo password (standard password for the remote user configured in the environment) as well as the specified db_user and/or database root password. See the mysql_conf command for a way to eliminate the need for database password prompting.

Note

This command will try to create a database on MySQL, which will fail if MySQL is not installed or the settings don’t provide configuration data for creating the database.

Examples:

$ fab production create_db

deploy¶

This command:

Calls the update_code command
Calls the syncdb command
Calls the migratedb command
Calls the deploy_static command
Calls the install_site command

Note

While running it may ask for the remote server root password or the sudo password (standard password for the remote user configured in the environment).

Note

Changed in version 2.5.1: Added support for deploying from a given branch on Pootle repository.

Examples:

$ fab production deploy  # Call that will use the default 'master' branch
$ fab production:branch=stable/2.5.0 deploy  # Call which provides a branch

deploy_static¶

This command:

Creates pootle/assets/ directory if it does not exist
Runs collectstatic –noinput –clear to collect the static files
Runs assets build to create the assets

Examples:

$ fab production deploy_static

disable_site¶

This command:

Disables the Pootle site on Apache using the Apache a2dissite command

Note

While running it may ask for the remote server root password or the sudo password (standard password for the remote user configured in the environment).

Examples:

$ fab production disable_site

drop_db¶

New in version 2.5.1.

This command:

Drops a database (losing all data!) using the settings provided to Fabric in the chosen environment

Note

Examples:

$ fab production drop_db

dump_db¶

New in version 2.5.1.

This command:

Dumps the database to the provided filename using the mysqldump command
Downloads the dumpfile to the local computer

Note

This commands can be used to perform periodic backups, that can be imported later using the load_db command.

Available arguments:

dumpfile

The local filename for the file where the database will be dumped.

Default: pootle_DB_backup.sql.

Examples:

$ fab production dump_db  # Call that will use the default filename
$ fab production dump_db:dumpfile=backup_mysql.sql  # Call which provides a filename

enable_site¶

This command:

Enables the Pootle site on Apache using the Apache a2ensite command

Note

While running it may ask for the remote server root password or the sudo password (standard password for the remote user configured in the environment).

Examples:

$ fab production enable_site

initdb¶

New in version 2.5.1.

This command:

Runs initdb to initialize the database

Examples:

$ fab production initdb

install_site¶

This command:

Calls the update_config command
Calls the enable_site command

Note

While running it may ask for the remote server root password or the sudo password (standard password for the remote user configured in the environment).

Examples:

$ fab production install_site

load_db¶

New in version 2.5.1.

This command:

Uploads the given SQL dump file to the remote server
Imports it to the database specified on Fabric settings using the mysql command

Note

You must first create the database you will import (e.g. using the create_db command) before calling this command,

Available arguments:

dumpfile: The local SQL dump filename that will be uploaded to the remote server and imported into an existing database on the remote server. This file can be created using the dump_db command.

Note

This is a required argument.

Examples:

$ fab production create_db  # Remember to create the DB first
$ fab production load_db:dumpfile=backup_mysql.sql

migratedb¶

New in version 2.5.1.

This command:

Runs migrate to update the 2.5 or later database schema to the latest version

Examples:

$ fab production migratedb

mysql_conf¶

New in version 2.5.1.

This command creates a .my.cnf MySQL options file on the remote system with the password(s) for database access stored in them (the passwords are taken from the fabric.py settings file). Once you have done this, you can un-comment the alternate db_password_opt and db_root_password_opt settings in fabric.py, which will eliminate the need for password prompting on all MySQL operations.

Examples:

$ fab production mysql_conf

production¶

This command:

Sets up the configuration for the production environment in Fabric settings

Note

This command is useless unless it is called before another command or commands.

Note

This command allows changing the settings. To do so just pass it any of its arguments when calling it.

Note that some commands might require passing any or all of these arguments to this command in order to overwrite the default settings before calling those commands. For example the command stage_feature requires passing branch, repo and feature.

Note

Changed in version 2.5.1: Added support for altering the settings based on the passed arguments.

Available arguments:

branch

A specific branch to check out in the repository.

repo

A repository URL to clone from.

This allows to checkout from a fork repository (not necessarily on GitHub) and try new features developed on that repository. It must be an URL that the git clone command is able to clone.

feature

Allows specifying if the deployment is for a feature-staging server. Such servers are used by Pootle developers in order to allow quick test of new features using a live Pootle server.

Examples:

$ fab production bootstrap

In the previous example production is called to set up the environment for calling bootstrap afterwards.

$ fab production:branch=feature/extension-actions bootstrap

In the previous example production is called to set up the environment for calling bootstrap afterwards.

The branch argument overwrites the default branch in the settings, which are then used for all the subsequent commands (just bootstrap in this example).

$ fab production:branch=feature/extension-actions,repo=git://github.com/unho/pootle.git bootstrap

In the previous example production is called to set up the environment for calling bootstrap afterwards.

The branch and repo arguments overwrite the default settings, which are then used for all the subsequent commands (just bootstrap in this example).

$ fab production:branch=feature/extension-actions,repo=git://github.com/unho/pootle.git,feature=yes stage_feature

This example is like the previous one, with the addition of the feature argument that triggers the altering of several settings. That altering is necessary for working with feature-staging servers.

setup¶

New in version 2.5.1.

This command:

Runs setup to create or upgrade the database as required

Examples:

$ fab production setup

setup_db¶

New in version 2.5.1.

This command:

Runs syncdb –noinput to create the database schema
Runs initdb to populate the standard schema objects
Runs migrate to bring the database schema up to the latest version

Examples:

$ fab production setup_db

stage_feature¶

New in version 2.5.1.

This command:

Calls the bootstrap command
Calls the create_db command
Copies the data in the specified source DB into the DB that will be used for the deployed Pootle
Calls the update_db command
Calls the deploy_static command
Calls the install_site command

Note

While running it may ask for the remote server root password and the specified db_user password.

Note

This command is intended primarily for deploying ad-hoc Pootle servers for easing the test of feature branches during Pootle development.

Warning

This command might require changing the source_db field in the deploy/ENVIRONMENT/fabric.py file. Note that the database specified on this field must exist.

Warning

This command requires using the staging environment passing to it the feature argument, the desired branch and optionally a repository URL.

Examples:

$ fab staging:branch=feature/extension-actions,feature=yes stage_feature
$ fab staging:branch=feature/extension-actions,repo=git://github.com/unho/pootle.git,feature=yes stage_feature

staging¶

This command:

Sets up the configuration for the staging environment in Fabric settings

Note

This command is useless unless it is called before another command or commands.

Note

This command allows changing the settings. To do so just pass it any of its arguments when calling it.

Note

Changed in version 2.5.1: Added support for altering the settings based on the passed arguments.

Available arguments:

branch

A specific branch to check out in the repository.

repo

A repository URL to clone from.

This allows to checkout from a fork repository (not necessarily on GitHub) and try new features developed on that repository. It must be an URL that the git clone command is able to clone.

feature

Allows specifying if the deployment is for a feature-staging server. Such servers are used by Pootle developers in order to allow quick test of new features using a live Pootle server.

Examples:

$ fab staging bootstrap

In the previous example staging is called to set up the environment for calling bootstrap afterwards.

$ fab staging:branch=feature/extension-actions bootstrap

In the previous example staging is called to set up the environment for calling bootstrap afterwards.

The branch argument overwrites the default branch in the settings, which are then used for all the subsequent commands (just bootstrap in this example).

$ fab staging:branch=feature/extension-actions,repo=git://github.com/unho/pootle.git bootstrap

In the previous example staging is called to set up the environment for calling bootstrap afterwards.

The branch and repo arguments overwrite the default settings, which are then used for all the subsequent commands (just bootstrap in this example).

$ fab staging:branch=feature/extension-actions,repo=git://github.com/unho/pootle.git,feature=yes stage_feature

This example is like the previous one, with the addition of the feature argument that triggers the altering of several settings. That altering is necessary for working with feature-staging servers.

syncdb¶

New in version 2.5.1.

This command:

Runs syncdb –noinput to create the database schema

Examples:

$ fab production syncdb

touch¶

This command:

Reloads daemon processes by touching the WSGI file

Examples:

$ fab production touch

unstage_feature¶

New in version 2.5.1.

This command:

Calls the disable_site command
Calls the drop_db command
Removes the configuration files created by the update_config command
Removes the directories created during the deployment, including the ones holding the translation files and the repositories for those translation files

Note

While running it may ask for the remote server root password and the specified db_user password.

Note

This command is intended for removing Pootle deployments performed using the stage_feature command.

Warning

This command requires using the staging environment passing to it the feature argument and the desired branch.

Examples:

$ fab staging:branch=feature/extension-actions,feature=yes unstage_feature

update_code¶

This command:

Updates the Pootle repository from GitHub
Checks out the specified branch, using master if no branch is specified
Updates the deployment requirements as listed in requirements/, including the base requirements as well

Note

Changed in version 2.5.1: Added support for updating code from a given branch on Pootle repository.

Examples:

$ fab production update_code  # Call that will use the default 'master' branch
$ fab production:branch=stable/2.5.0 update_code  # Call which provides a branch

update_config¶

This command:

Will upload the configuration files included in the chosen environment to the remote server:
- Configure VirtualHost using the provided virtualhost.conf
- Configure WSGI application using the provided pootle.wsgi
- Configure and install custom settings for Pootle using the provided settings.conf

Note

While running it may ask for the remote server root password or the sudo password (standard password for the remote user configured in the environment).

Examples:

$ fab production update_config

update_db¶

This command:

Runs updatedb and migrate to update the database schema to the latest version

Examples:

$ fab production update_db

upgrade¶

New in version 2.5.1.

This command:

Runs upgrade to apply any special post-schema-upgrade actions (including changes needed for updated Translate Toolkit version). This would typically be performed after running the update_code command. If you haven’t just upgraded Pootle or the Translate Toolkit to a new release, this isn’t generally required, so there is no need to run it unless release notes or other instructions direct you to do so.

Examples:

$ fab production upgrade