SlapOS Home SlapOS

    OSTV HowTo Create Software Release

    TRACK - Lectures explaining how to use an NMS system.
    • Last Update:2019-05-21
    • Version:002
    • Language:en

    How To Create Software Release

    This document will guide through the steps of creating a new software release - a set of files which allow to build and instantiate a software on SlapOS. The key components of a software release are the software profile (software.cfg) used to build and install the software and the instance profile (instance.cfg.in) used for instantiation.

    Both installations and instantiations are done using a software called Buildout, which utilizes the templating language Jinja2. This howto expects familiarity with both. It will introduce the different sections of a profile and show how they are put together using the Amarisoft LTE software release (gitlab repository - see $your_repo_location/tree/master/slapos/software/lte for the corresponding file).

    Please note that this howto does not cover adding a software release to the catalogue of the NMS master or upgrading an existing software release. It also does not cover installing a software on a node.

    Table of Content

    • Amarisoft LTE Software Release

    Amarisoft LTE Software Release

    While there are many simple software releases consisting only of a software and instance profile, there are just as many more complex ones with a multitude of different templates and configuration files. This section will explain the Amarisoft LTE Software Release and the files it consists of to give an idea of how to write a new release or extend this existing release.

    The SlapOS repository is usually contains the following three directories (among others):

    • /component - pieces to include in a software profile (eg dcron, bycrpt)
    • /slapos/software - software profiles utilizing components (eg LTE or SimcardDB)
    • /stack - software build from multiple softwares & components (eg Amarisoft, LAMP)

    LTE Release

    Gitlab Interface - Amarisoft LTE Software Release Overview

    The /slapos/software/lte/ repository consists of the following files:

    Software Profile

    Gitlab Interface - LTE Software Profile

    The software.cfg file is used for installation of the LTE software on a node. You can see that it mostly defines required versions of included software in the [versions] section.

    Besides this, the templates are listed that will later provide the different software-types during instantiation. Each section:

    [template-lte-ims]
    recipe = slapos.recipe.build:download
    url = ${:_profile_base_location_}/instance-ims.jinja2.cfg
    filename = instance-ims.cfg
    mode = 0644

    defines the recipe to use (in this case the download recipe), the location of the template file to use for instantiation as well as the name of the instantiation output file and its permissions.

    If a section defines a context, like [ue_db.py.in], it exposes parameters to the instance profile (instance.cfg) so that they can be used there. The [parts] section denotes the recipes to be excuted when Buildout runs the sofware profile, in this case the template and sdr-driver sections/recipes whereas the [buildout] section extends the default buildout configuration by the file containing the MD5 sums as well as Amarisoft's stack.

    Software Profile (json)

    Gitlab Interface - LTE Software Profile (JSON)

    The JSON software profile is used to create forms for a software release. By convention the entry point file is found by including .json to the url of the software release, so software.cfg.json. The file is used to list the available software-types and forms (Schemas) that a user can choose during instantiation. A template for a form looks similar to this:

    {
        "name": "NAME OF Software",
        "description": "The description",
        "serialisation": "xml",
        "software-type": {
            "default": {
                "title": "Default",
                "software-type": "default", 
                "description": "description of default",
                "request": "instance-NAME-input-schema.json",
                "response": "instance-NAME-output-schema.json",
                "index": 0
            },
            "default-slave": {
                "title": "Slave",
                "description": "Description for the slave",
                "software-type": "default",
                "request": "instance-NAME-slave-input-schema.json",
                "response": "instance-NAME-output-schema.json",
                "shared": true,
                "index": 1
            },
            ...
        }
    }

    The most important fields are:

    • "title" - name of the software-type displayed to the user
    • "software-type" - defines the type of software
    • "shared" - defines whether the instance is a slave of another instance (eg (slave-)tokens issued by a registry)
    • "request" - the (relative) link to the file containing the json schema used to render the form

    Form Input Schema

    Gitlab Interface - Form Input Schema JSON

    The JSON input schema allows to define form fields of a software-type to display to the user. They will be rendered live by fetching the respective urls. For example:

    {
      "$schema": "http://json-schema.org/draft-04/schema#",
      "properties": {
        "somevalue": {
          "title": "Input a String",
          "description": "This is an example of string parameter",
          "type": "string"
        },
        "sonumber": {
          "title": "Input a Number",
          "description": "This is an example of number parameter",
          "type": "number"
        }
      }
    }

    It is adviced to use a flat approach (one level, don't create unneccessary depth/complexity) and a simple structure. Keep in mind:

    • keep it short, the larger the amount of parameters, the longer and complex is the form.
    • omit entries which are set automatically or by convention (port number, etc).
    • omit values that depend on other instances if value can be taken automatically.
    • use prefixes for different software on same hosting subscription.
    • use meaningful title and description.

    Instance Profile

    Gitlab Interface - Instance Profile

    The instance profile will be used to instantiate whichever software-type the user selected using the parameters the user provided filling out the template-form.

    In the LTE profile you can see that [parts] being run are dynamic-template-lte-default and switch-softwaretype aside from the mandatory [instance] and [jinja2-template-base] sections. The dynamic-template-lte-default provides instantiation instructions for the default "lab" version of LTE, which is also one of the available software-types the user can choose from. All software types are then listed in the switch-softwaretype section.

    Each software-type section defines extra content, listing the parameters and values to be exposed to the Jinja2 template:

    [dynamic-template-lte-ims]
    < = jinja2-template-base
    template = ${template-lte-ims:target}
    filename = instance-lte-ims.cfg
    extensions = jinja2.ext.do
    extra-context =
        raw monitor_template ${monitor2-template:rendered}
        ...

    With the above information it should possible to re-create the LTE software release, extend or rewrite it altogether.

    Thank You

    Image Nexedi Office
    • Nexedi SA
    • 147 Rue du Ballon
    • 59110 La Madeleine
    • France