Synnefo

server {

    listen 80;

    server_name synnefo.local;

    root /var/lib/synnefo/;

    # serving static files 

    location /static  {

        autoindex on;

        root /var/lib/synnefo/;

    }

    location / {

        # host and port to fastcgi server

        fastcgi_pass 127.0.0.1:8015;

        fastcgi_param PATH_INFO          $fastcgi_script_name;

        fastcgi_param REQUEST_METHOD     $request_method;

        fastcgi_param QUERY_STRING       $query_string;

        fastcgi_param CONTENT_TYPE       $content_type;

        fastcgi_param CONTENT_LENGTH     $content_length;

        fastcgi_param SERVER_ADDR        $server_addr;

        fastcgi_param SERVER_PORT        $server_port;

        fastcgi_param SERVER_NAME        $server_name;

        fastcgi_param  SERVER_PROTOCOL  $server_protocol;

        fastcgi_pass_header Authorization;

        fastcgi_intercept_errors off;

    }

}

-----------------------------------

**********************

*************

.. include settings reference

.. include: settings.rst

Synnefo WEBAPP node is the server that runs the web application bundled within

the synnefo package. The application provides 2 different interfaces.

Web admin

`````````

Synnefo web administration interface. Allows administrator users to manage the

synnefo application via web interface.

Web application

```````````````

Web interface which allows users to create/configure/manage their virtual

machines.

.. _dispatcher-deploy:

Dispatcher

----------

The logic dispatcher is part of the Synnefo Django project and must run

on :ref:`LOGIC <LOGIC_NODE>` nodes.

The dispatcher retrieves messages from the queue and calls the appropriate

handler function as defined in the queue configuration in `/etc/synnefo/*.conf`

files.

The default configuration should work directly without any modifications.

For the time being The dispatcher must be run by hand::

  $ synnefo-dispatcher

The dispatcher should run in at least 2 instances to ensure high

(actually, increased) availability.

.. _static-files:

Static files

************

* Choose an appropriate path (e.g. /var/lib/synnefo/static/) from which your web 

  server will serve all static files (js/css) required by Synnefo web frontend to 

  run.

* Change ``MEDIA_ROOT`` value in your settings to point to that directory.

* Run the following command which will create symlinks of static files in

  that directory::

    $ synnefo-manage link_static

**Sample nginx configuration using fcgi**

.. literalinclude:: ../_static/synnefo.nginx.conf

`download <../_static/synnefo.nginx.conf>`_

run the fcgi server::

    $ synnefo-manage runfcgi host=127.0.0.1 port=8015

10. As is.

11. The Synnefo Ganeti hook is already running on the development backend,

    sending notifications over AMQP.

12. The VNC authentication proxy is already running on the Ganeti development

    backend. You *cannot* run your own, unless you install your own Ganeti

    backend, because it needs direct access to the hypervisor's VNC port on

    GANETI-NODEs.

    Note: You still need to install the vncauthproxy package to satisfy

    the dependency of the API on the vncauthproxy client. See Synnefo #807

    for more details.

13. The development Ganeti backend already has a number of OS Images available.

14. The development Ganeti backend already has a number of pre-provisioned

    bridges available, per each BACKEND_PREFIX_ID.

    To setup simple NAT-based networking on a Ganeti backend on your own,

    please see the provided patches under contrib/patches/.

    You will need minor patches to the sample KVM ifup hook, kvm-vif-bridge,

    and a small patch to NFDHCPD to enable it to work with bridged tap+

    interfaces. To support bridged tap interfaces you also need to patch the

    python-nfqueue package, patches against python-nfqueue-0.3 [part of Debian

    Sid] are also provided under contrib/patches/.

15. As is.

16. As is.

17. [OPTIONAL] Create settings.d/99-local.conf and insert local overrides for

    settings.d/\*.  This will allow pulling new files without needing to reapply

    local any local modifications.

Initial Migration

*****************

executed::

    $ synnefo-manage syncdb       # Create / update the database with the south tables

    $ synnefo-manage migrate db   # Perform migration in the database

For example::

    $ synnefo-manage migrate db 0001 --fake

To be sure that all migrations are applied type::

    $ synnefo-manage migrate db --list

Schema migrations

*****************

(WARNING: always perform this with extreme care)::

    $ synnefo-manage schemamigration db --auto

database::

    $ synnefo-manage migrate db

Consider this example (adding a field to the SynnefoUser model)::

You can now apply this migration with::

default value. If not, South will propably fail, after indicating the error::

Data migrations

***************

1. Introduce the changes in the code and fixtures (initial data).

2. Execute::

    For example::

        $ ./bin/python manage.py datamigration db rename_credit_wallet

        Created 0003_rename_credit_wallet.py.

3. We edit the generated script. It contains two methods: forwards and

   backwards.

   For database operations (column additions, alter tables etc) we use the

   South database API (http://south.aeracode.org/docs/databaseapi.html).

   To access the data, we use the database reference (orm) provided as

   parameter in forwards, backwards method declarations in the migration

   script. For example::

        .. code-block:: python

            class Migration(DataMigration):

            def forwards(self, orm):

                orm.SynnefoUser.objects.all()

    4. To migrate the database to the latest version, we execute::

        $ synnefo-manage migrate db

    To see which migrations are applied::

          $ synnefo-manage migrate db --list

          db

            (*) 0001_initial

            (*) 0002_auto__add_field_synnefouser_new_south_test_field

            (*) 0003_rename_credit_wallet

.. seealso::

    More information and more thorough examples can be found in the South web site.

    http://south.aeracode.org/

In order to get code coverage reports you need to install django-test-coverage::

Then edit your settings.py and configure the test runner::

this command will create a ``tar.gz`` python source package inside ``dist`` directory.

.. include:: ci.rst

      ('el', u'Greek'),

      ('en', u'English'),)

.. seealso::

    http://docs.djangoproject.com/en/dev/topics/i18n/internationalization/