Metadata-Version: 2.4
Name: slapos.cookbook
Version: 1.0.415
Summary: SlapOS recipes.
Home-page: https://lab.nexedi.com/nexedi/slapos
Maintainer: Nexedi
Maintainer-email: info@nexedi.com
License: GPLv3
Keywords: slapos recipe
Classifier: Framework :: Buildout :: Recipe
Classifier: Programming Language :: Python
Requires-Dist: jsonschema
Requires-Dist: netaddr
Requires-Dist: setuptools
Requires-Dist: inotify_simple
Requires-Dist: lock_file
Requires-Dist: slapos.core
Requires-Dist: zc.buildout
Requires-Dist: zc.recipe.egg
Requires-Dist: pytz
Requires-Dist: passlib
Provides-Extra: test
Requires-Dist: bcrypt; extra == "test"
Requires-Dist: jsonschema; extra == "test"
Requires-Dist: mock; extra == "test"
Requires-Dist: psycopg2; extra == "test"
Requires-Dist: testfixtures; extra == "test"
Requires-Dist: requests; extra == "test"
Dynamic: classifier
Dynamic: description
Dynamic: home-page
Dynamic: keywords
Dynamic: license
Dynamic: maintainer
Dynamic: maintainer-email
Dynamic: provides-extra
Dynamic: requires-dist
Dynamic: summary

slapos.cookbook
===============

Cookbook of SlapOS recipes.


testing
=======

Unit tests for recipes can be found under ``slapos/test/recipe``. To run the
tests use provided unittest.defaultTestLoader inside ``slapos/test/test_recipe``
by invoking 

    python setup.py test --test-suite slapos.test.test_recipe.additional_tests


generic_cloudooo
================

The generic_cloudooo recipe helps you to deploy cloudooo services with their configuration files.


How to use generic_cloudooo?
----------------------------

Here is an example of a section to add in your software.cfg :

.. code-block:: ini

  [cloudooo-configuration]
  recipe = slapos.cookbook:generic_cloudooo
  configuration-file = ${directory:etc}/cloudooo.cfg
  wrapper = ${directory:services}/cloudooo
  data-directory = ${directory:srv}/cloudooo
  ip = 0.0.0.0
  port = 1234
  ooo-paster = ${directory:bin}/cloudooo_paster
  mimetype_entry_addition =
    text/html application/pdf wkhtmltopdf
  openoffice-port = 1235
  ooo-binary-path = ${directory:libreoffice-bin}/program
  environment =
    FONTCONFIG_FILE = $${fontconfig-conf:output}
    PATH = ${binary-link:target-directory}
  ooo-uno-path = ${directory:libreoffice-bin}/basis-link/program


Where :

- `configuration-file` is the path where the put the configuration file;
- `wrapper` is the path where the put the final executable file;
- `data-directory` is the folder where cloudooo would put it's temporary files;
- `ip` and `port` is where cloudooo will listen to;
- `ooo-paster` is the path of the program that will load cloudooo configuration
  and start the application;
- `mimetype_entry_addition` is additional entries to give to the default
  mimetype registry. (see section below.) The mimetype entry list is sorted in
  order to make the global mimetype at the bottom of the list.
  (i.e. `* * ooo` > `text/* * ooo`)

    .. code-block:: ini

        mimetype_entry_addition =
          <input_format> <output_format> <handler>

- `openoffice-port` is the port where the internal OpenOffice.org service will
  listen to;
- `ooo-binary-path` is the path of the openoffice service executable file;
- `environment` are environment vars to use with the openoffice binary;
- `ooo-uno-path` is the path where UNO library is installed.


Default mimetype registry
-------------------------

.. code-block:: ini

  application/vnd.oasis.opendocument* * ooo
  application/vnd.sun.xml* * ooo
  application/pdf text/* pdf
  application/pdf * ooo
  video/* * ffmpeg
  audio/* * ffmpeg
  application/x-shockwave-flash * ffmpeg
  application/ogg * ffmpeg
  application/ogv * ffmpeg
  image/png image/jpeg imagemagick
  image/png * ooo
  image/* image/* imagemagick
  text/* * ooo
  application/zip * ooo
  application/msword * ooo
  application/vnd* * ooo
  application/x-vnd* * ooo
  application/postscript * ooo
  application/wmf * ooo
  application/csv * ooo
  application/x-openoffice-gdimetafile * ooo
  application/x-emf * ooo
  application/emf * ooo
  application/octet* * ooo
  * application/vnd.oasis.opendocument* ooo


librecipe
=========

Thanks to using slapos.cookbook:librecipe it is easier to create zc.buildout recipes in SlapOS environment.

How to use?
-----------

In setup.py of recipe add only one install requires to slap.lib.recipe.

In code itself subclass from slap.lib.recipe.BaseSlapRecipe.BaseSlapRecipe.

Use _install hook:

::

  from slap.lib.recipe.BaseSlapRecipe import BaseSlapRecipe

  class Recipe(BaseSlapRecipe):
    ...
    def _install(self):
      # refer below for list of available objects
      specific code
      of recipe

Available variables self.:

 * name and options passed by zc.buildout during init
 * work_directory -- buildout's directory
 * bin_directory -- places for generated binaries
 * running_wrapper_location -- filename of wrapper to create
 * data_root_directory -- directory container for data -- inside this
   directory it is advised to create named directories for provided servers
   which needs data
 * backup_directory -- directory container for backups -- inside this
   directory it is advised o created named directories for backups, with same
   structure as in data_root_directory
 * var_directory -- container for various, unix following things:

   * log_directory -- container for logs
   * run_directory -- container for pidfiles and sockets

 * etc_directory -- place to put named files and directories of configuration
   for provided servers
 * computer_id -- id of computer
 * computer_partition_id -- if of computer partition
 * server_url - url of Vifib server
 * software_release_url -- url of software release being instantiated
 * slap -- initialised connection to Vifib server
 * computer_partition -- initialised connection to computer partition
 * request -- shortcut to computer partition request method

By default all directories are created before calling _install hook.

_install method shall return list of paths which are safe to be removed by
buildout during part uninstallation.

Important assumptions
---------------------

Because in SlapOS environment zc.buildout does not know when data are changed,
recipes shall be always uninstalled/installed. This is done during constructing
recipe instance which subclasses from BaseSlapRecipe.


mkdirectory
===========

mkdirectory loops on its options and create the directory joined

.. Note::

   Use a slash ``/`` as directory separator. Don't use system dependent separator.
   The slash will be parsed and replace by the operating system right separator.

   Only use relative directory to the buildout root directory.

The created directory won't be added to path list.


These recipes provide the ability to save some buildout parameters and their value in a custom file, inside the instance folder.

In both recipes, you HAVE TO give a filename, which will be stored at the root of the instance folder


WriteRecipe : 
-------------

* Is used to create a section (named according to the buildout section_name).
* You can give then as much parameters you wish, with their default values.
* Whenever you run buildout, if the parameter has yet been saved in the config file, it will do nothing.
* If the parameter's value has changed in the config file, it won't be overwritten
* /!\ If you decide to change the default value of one parameter, ALL other parameters will be reseted in the config file, even if you changed it manually. Explanation : The default values aren't expected to change, except while development purposes.

ReadRecipe :

* It fills its own section with all the options in all the sections of the config file.

